Está en la página 1de 28

Competency Area 1: Foundational Knowledge (Fundamentos del Conocimiento) Las reas de conocimiento principales que componen el rea de competencia,

conocimientos bsicos son los siguientes: 1.1 Process Definition (Definicin del Proceso) Esta rea de conocimiento esboza los conceptos fundamentales y las habilidades que permiten a los profesionales de la ingeniera 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 Medicin) Esta rea de conocimiento describe las mtricas del proceso y del producto y explica por qu es importante medir para producir trabajo de alta calidad. 1.4 Statistical Elements (Elementos de Estadstica) Esta rea de conocimiento analiza las estadsticas que proveen una base para la planificacin y el seguimiento de las metodologas utilizadas en el PSP, y que tambin proporcionan un medio objetivo de analizar y mejorar los procesos personales. Knowledge Area 1.1: Process Definition (Definicin del Proceso) El PSP es una serie de procesos definidos que permiten a los profesionales de ingeniera (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. 1.1.1 Process (Proceso) Un proceso describe la secuencia de pasos que un profesional calificado debe seguir para realizar una tarea determinada. 1.1.2 Defined process (Proceso Definido) Un proceso definido es una secuencia documentada de los pasos necesarios para hacer un trabajo especfico. 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. 1.1.3 Benefits of defining a process Un proceso definido proporciona: un marco claramente delineado para la planificacin, seguimiento y gestin del trabajo una gua 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 consecucin de metas, y para refinar el proceso en las futuras versiones Una herramienta para la planificacin y la gestin 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 comn. un mecanismo que permite a los miembros del equipo apoyarse mutuamente en el transcurso del proyecto 1.1.4 Process documentation (Documentacin del proceso) Documentar un proceso es el acto de producir una representacin escrita concreta de un proceso, los criterios de entrada y salida, las fases del proceso, y los pasos del proceso para cada fase. La documentacin del proceso no debe contener material explicativo tutorial o de otra ndole general que requieren las personas no calificadas o desinformadas sino que slo debera facilitar la informacin necesaria que requieren profesionales con experiencia para ejecutar los pasos del proceso. 1.1.5 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. 1.1.6 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. 1.1.7 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 definicin 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 precisin 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. 1.1.8 Process phases (Fases del proceso) Un proceso definido, consta de una serie de pasos, elementos o actividades que comnmente se llaman fases. Las fases de un proceso simple consisten en pasos sin mucha estructura. Los procesos ms complejos pueden tener fases que son sus propios procesos. Los pasos o actividades en cada fase se definen por un script (vase 1.2.2). Como mnimo, cualquier proceso debe tener tres fases: planificacin, desarrollo, y postmortem. 1.1.9 The PSP process phases (las fases del proceso PSP) El proceso bsico PSP tiene tres fases. 1. Planificacin: Elaborar un plan para hacer el trabajo. 2. Desarrollo: Realizar el trabajo. a. definir los requerimientos (see 4.2.2) b. disear el programa c. revisar el diseo y corregir todos los defectos d. codificar el programa e. revisar el cdigo y corregir todos los defectos

3.

f. construir o compilar y corregir todos los defectos g. probar el programa y corregir todos los defectos Post mortem: Comparar los resultados reales con el plan, los datos histricos del proceso, elaborar un informe resumido, y documentar todas las ideas para la mejora de procesos.

1.1.10 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 estn disponibles [Humphrey 05a]. Los mtodos de PSP se usan ms eficazmente con desarrollos incrementales a gran escala cuando cada incremento es de alta calidad. 1.1.11 Process tailoring (adaptacin de procesos) La adaptacin de procesos es el acto de personalizar la definicin de un proceso para soportar la adaptacin de ese proceso para un propsito particular (see 7.1). 1.1.12 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 construccin de un producto. Deben definir sus propios procesos para garantizar que los procesos se ajusten a sus necesidades lo ms 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. 1.2.1 Process elements (Elementos del Proceso) Los elementos del proceso son los componentes de un proceso. El PSP contiene cuatro elementos bsicos: scrpts(guiones), formas, measures (mtricas), y estndares. 1.2.2 Scripts (guiones) Scripts are expert-level descriptions that guide personal enactment of a process. Contienen referencias a las formas, estndares, checklists, sub-scripts, y mtricas pertinentes. Un script puede definir en un alto nivel todo un proceso o en un nivel ms detallado alguna fase de un proceso en particular. Un script de proceso documenta El propsito u objetivo del proceso Los criterios de entrada directrices generales, consideraciones de uso, o restricciones fases o etapas que deben realizarse mtricas del proceso y criterios de calidad condiciones de salida (como productos de trabajo definidos o datos requeridos del proceso) 1.2.3 Forms (formas) Las formas proporcionan un marco adecuado y coherente para la recoleccin y registro de datos, especifican los datos requeridos y donde registrarlos. Segn corresponda, las formas tambin definen los clculos necesarios y la definicin de datos. Los formularios en papel pueden ser utilizados si las herramientas automatizadas para la recopilacin y el registro no son fcilmente accesibles En PSP, los checklist son formas especiales para guiar las revisiones personales. Cada elemento del checklist verifica un aspecto de la correccin del producto o la conformidad con las normas o especificaciones. Los puntos de la lista incluyen las ocurrencias ms frecuentes de defectos que se pueden encontrar con una revisin. Todo el producto es revisado enfocndose 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 revisin. 1.2.4 Measures (mtricas) Las mtricas cuantifican el proceso y el producto, proporcionan datos de cmo est funcionando el proceso permitindole a los usuarios Desarrollar perfiles de datos de proyectos anteriores que puedan ser usados para la planeacin y mejora de procesos Analizar un proceso para determinar la manera de mejorarlo Determinar la eficacia de las modificaciones al proceso supervisar la ejecucin de sus procesos y tomar decisiones supervisar la capacidad para cumplir los compromisos y tomar acciones correctivas cuando sea necesario 1.2.5 Standards (estndares) Los estndares proporcionan definiciones precisas y consistentes que guan el trabajo, la recopilacin y el uso de datos. Los estndares (como el de codificacin, conteo de lneas, y tipos de defectos) permiten que las mtricas se apliquen uniformemente en diversos proyectos y que se usen de manera habitual. Los profesionales de PSP deberan ser capaces de reconocer las reas donde los estndares podran ser tiles y elaborarlos cuando sea necesario. Knowledge Area 1.3: Measurement Principles (Principios de medicin) Esta rea de conocimiento describe la medicin del proceso y del producto y explica por qu las mtricas son esenciales para producir trabajo de alta calidad. 1.3.1 The need for measures (la necesidad de usar mtricas) Las mtricas se utilizan en PSP de manera que los cambios al proceso pueden ser identificados, evaluados, lgicamente implementados, y considerados efectivos o inefectivos. 1.3.2 Measurement types Para que sea til para la gestin 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 caractersticas del producto, tales como el tamao del producto o de los defectos encontrados por elemento Las medidas del proceso describen o cuantifican el proceso de desarrollo o de correccin utilizado, y se clasifican como mtricas histricas o actuales.

o o

Las Mtricas histricas del proceso se utilizan despus de que el proceso se ha realizado para registrar los datos reales, tales como el tiempo de inspeccin, el tiempo de prueba, etc. Las mtricas actuales del proceso se utilizan mientras el proceso se est ejecutando el proceso se utilizan para registrar datos como la duracin de las reuniones de inspeccin, el tiempo de revisin de cdigo como porcentaje del tiempo total de codificacin, y similares.

Tanto las mtricas de artefactos como las de proceso pueden basarse en mediciones individuales o mltiples. La eleccin de mtricas nicas o mltiples depende de la naturaleza de los datos y el uso que se le dar a cada una. Cuando se toman mtricas mltiples, es necesario un procedimiento estadsticamente sensato para calcular los valores de utilizacin de estas mtricas. 1.3.3 Defined measures (mtricas definidas) Una mtrica definida es aquella que tiene un significado explcito e inequvoco. Para las mtricas de proceso, se requiere que el proceso est definido con precisin para incluir criterios de entrada y salida para todas las fases. Las propiedades que se miden en un proceso tambin deben estar completa y explcitamente definidas. 1.3.4 Precise and accurate measures (Mtricas precisas y exactas) Una mtrica precisa es la que especifica un valor a un nivel adecuado de precisin, como con un nmero determinado de dgitos despus del punto decimal. Una mtrica exacta es la que mide correctamente la propiedad que se pretende medir. Las mtricas pueden ser precisas y exactas, precisas, pero inexactas, imprecisa, pero exacta, o ambos imprecisa e inexacta. En gestin de procesos, las medidas deben ser tan precisas y exactas como sea posible. 1.3.5 Meaningful measures (Medidas significativas) Para ser significativa, las mtricas 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 caracterstica objetiva de un fenmeno real. La significancia de la mtrica aumenta con el nmero y consistencia de las mtricas que se van tomando. 1.3.6 Uses of process measures (usos de las mtricas de proceso) Las mtricas de proceso pueden ser utilizadas para evaluar las caractersticas del producto o proceso, para estimar elementos del producto o del proceso, o para predecir los resultados futuros. Tambin 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 Estadstica) La estadstica es el fundamento para la planeacin y las metodologias de seguimiento en PSP, adems proporcionan un medio objetivo de analizar y mejorar los procesos personales. (Nota: Las definiciones especficas, interpretaciones o aplicaciones de trminos estadsticos que hace PSP se mencionan en cada subseccin del rea de conocimiento que le corresponda.) 1.4.1 Distributions (distribucin) Una distribucin es un conjunto de valores numricos que son generadas por un proceso comn (tamaos reales de las partes desarrolladas o estimaciones del tamao de las partes). 1.4.2 Mean (Media) La media es el valor promedio aritmtico de una distribucin. En PSP, la media es normalmente una estimacin de la media de la distribucin, no es la media real. 1.4.3 Variance (Varianza) La varianza es una medida de la difusin o estrechez de una distribucin alrededor de la media. En PSP, la varianza es normalmente una estimacin de la varianza de la distribucin, en lugar de la varianza real. 1.4.4 Standard deviation (Desviacin estndar) La desviacin estndar es la raz cuadrada de la varianza. A menudo se utiliza para caracterizar el rango esperado de la desviacin entre una estimacin y un valor real. Por ejemplo, un mtodo en PSP utiliza la desviacin estndar para clasificar el tamao de software en tablas de tamao relativo. La desviacin estndar tambin se utiliza como parte del clculo de los intervalos de prediccin. 1.4.5 Correlation (correlacin) La correlacin mide el grado de relacin que tienen dos conjuntos de datos. En PSP, la correlacin est dada entre el tamao estimado y real, y entre el esfuerzo estimado y el real. 1.4.6 Significance of a correlation (Significancia de una correlacin) La significancia mide la probabilidad de que dos conjuntos de datos que tienen un alto grado de correlacin sea por casualidad. Las estimaciones de tamao y esfuerzo en PSP son ms fiables cuando se basan en datos histricos que tienen un alto grado de correlacin que es significativo. 1.4.7 Linear regression (Regresion Lineal) La regresin lineal determina aquella lnea que se acerca a los datos y que minimiza la varianza de los datos con respecto a dicha lnea. Por ejemplo, cuando el tamao y el esfuerzo se relacionan linealmente, la regresin lineal puede utilizarse para obtener estimaciones de esfuerzo a partir de las estimaciones del tamao. 1.4.8 Prediction interval (Intervalo de prediccin) El intervalo de prediccin provee el rango alrededor de una estimacin hecha mediante regresin lineal en el que el valor real caer con una probabilidad certera. Por ejemplo, en PSP, el 70% de intervalo de prediccin de una estimacin de tamao o de tiempo implica un 0.7 de probabilidad de que el valor real de tamao o tiempo estar dentro del rango definido por el intervalo de prediccin. 1.4.9 Multiple regression (regression multiple) La regresin mltiple se utiliza en PSP, cuando las estimaciones de tamao o tiempo dependen de ms de una variable. Por ejemplo, si las modificaciones de los programas requieren mucho ms tiempo que las adiciones, entonces -aadir y modificar se pueden separar en dos variables para el clculo de regresin. 1.4.10 Standard normal distribution (distribucin normal estndar) La distribucin normal estndar es una distribucin normal que se ha convertido a una media de cero y una desviacin estndar de uno La distribucin normal estndar se usa en PSP al construir una tabla de estimacin de tamao. 1.4.11 Log-normal distribution (Distribucin logartmica normal) Muchas de las operaciones estadsticas suponen que los valores de los datos se distribuyen normalmente, pero algunas mtricas de PSP no cumplen con este requisito. Por ejemplo, los valores de tamao no pueden ser negativos, pero pueden tener valores pequeos

que estn cerca de cero. Estas distribuciones tambin suelen tener probabilidades ms altas de tener valores grandes que una distribucin normal. Cuando una transformacin logartmica se aplica a un conjunto de datos de este tipo, la distribucin resultante puede tener una distribucin normal y, por tanto, adecuado para los anlisis estadsticos de datos que suponen una distribucin normal. Los parmetros estadsticos de la distribucin normal se pueden calcular y luego transformarse de nuevo a la distribucin original. Los datos de tamao en PSP obedecen generalmente a una distribucin logartmica normal, por lo que deben transformarse en una distribucin normal para la construccin de una tabla de estimacin de tamao. 1.4.12 Degrees of freedom (Grados de libertad) Los grados de libertad (df) miden el nmero de puntos de datos (n), en comparacin con el nmero de parmetros (p) que se utilizan para representarlos. En la regresin lineal, dos parmetros (0 y 1) describen la lnea que se utiliza para aproximar los datos. Desde al menos dos puntos son necesarios para determinar una lnea, el nmero de grados de libertad es n-2. En general, el nmero de grados de libertad es n-p. 1.4.13 The t-distribution (la distribucin T) La distribucin t permite la estimacin de la varianza de una distribucin normal, cuando los verdaderos parmetros no son conocidos, permitiendo as el clculo de los parmetros estadsticos basados en estimaciones de datos de la muestra. Como la distribucin normal, tiene forma de campana, pero vara dependiendo del nmero de puntos en la muestra. Para menos puntos, la distribucin es corta con cabos gruesos. Conforme aumenta el nmero de puntos, la distribucin se hace ms alta, con pequeos cabos y aproximaciones a la distribucin normal. En PSP, la distribucin t es importante porque ayuda a determinar la significancia de una correlacin y el intervalo de prediccin para la regresin, cada una de las cuales depende del nmero de puntos en el conjunto de datos de la muestra. Competency Area 2: Basic PSP Concepts La segunda rea de conocimiento, presenta los conceptos bsicos 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 (Recoleccin de Datos) - Esta rea de conocimiento aborda habilidades y conceptos relativos a la recoleccin y utilizacin de datos de proceso. 2.4 Data Analysis (Anlisis 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. 2.1.1 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. 2.1.2 Process fidelity and useful data (Adherencia al proceso y datos tiles) Con el fin de tener datos significativos de la aplicacin y mejora de un proceso personal, el proceso debe seguirse tal como se defini. 2.1.3 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 creacin y el uso consistente de un proceso de alta calidad se traducirn en la construccin 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. 2.1.4 Process fidelity and planning (Adherencia al proceso y planeacin) Cuando un proyecto est planeado conforme a procesos eficaces y eficientes y se hacen estimaciones basadas en datos slidos, 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. 2.1.5 Process fidelity and performance improvement (Adherencia al proceso y mejora del desempeo) Un proceso bien definido y medido que se sigue fielmente permite a las personas seleccionar los mtodos 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 desempeo. Knowledge Area 2.2: Data Collection (Recoleccin de datos) Esta rea de conocimiento aborda habilidades y conceptos relativos a la recoleccin y utilizacin de datos de proceso. 2.2.1 Collecting data (recopilacin de datos)

El PSP se basa en los datos ya que los individuos no pueden mejorar sus procesos de trabajo a menos que entiendan exactamente cmo 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 recoleccin y anlisis de los datos se incluye: el establecimiento de estndares 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 desempeo 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

2.2.2 Collecting useful data (Recoleccin de datos tiles) Para ser ms tiles, los datos deben ser recogidos de acuerdo a las siguientes directrices: El proceso de recopilacin de datos debe tener objetivos y planes especficos. Los datos reales deben ser seleccionados por su relevancia en la aplicacin de un modelo o una hiptesis. 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 informacin precisa y pertinente. El proceso de recopilacin de datos debe incluir consideraciones sobre el impacto que tiene la recopilacin de datos en la organizacin y su gente. El plan de recoleccin de datos debe contar con el apoyo de la gerencia, la propia gerencia debe considerar la recoleccin de datos como una inversin de alto valor en trminos de poder ser capaces de predecir con precisin los costos de desarrollo de productos y programas, as como proporcionar una base para mejorar la eficiencia de la organizacin y la calidad de sus productos. 2.2.3 Collecting high-quality data (recopilacin 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 mtodos adecuados para tomar medidas del proceso y registrar los datos que recojan. El uso de herramientas automatizadas para la recopilacin de datos, cuando las herramientas adecuadas estn disponibles, puede ayudar a mejorar la calidad de los datos ofreciendo a las personas un medio conveniente para la captura de informacin de los procesos inmediatamente despus de que esta se genera. 2.2.4 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 informacin en tiempo real (o cuanto antes despus de que se generan los datos). Sin embargo, los individuos deben estar seguros que los datos de su proceso personal no sern utilizados para evaluar su desempeo si la gente teme que sus datos sean utilizados para clasificarla o para castigarla, no recogern datos exactos, si es que recogen alguno. 2.2.5 Using data for planning purposes (Usar los datos para fines de planificacin) 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 histricos anlogos (vase 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 ms productos anteriores, trabajos o proyectos de la misma naturaleza. Cuanto ms similares sean los esfuerzos anteriores al que se est planeando, ms probable ser que se llegue a una estimacin exacta. Mientras ms datos histricos se utilicen al hacer una estimacin, es ms probable que la estimacin sea exacta. La estimacin de un trabajo grande o un proyecto completo como un compuesto de varios subproyectos compuesto de productos de trabajo pequeos ms precisa que la estimacin del proyecto como una gran unidad nica. Knowledge Area 2.3: Data Measures Esta rea de conocimiento se describen las cuatro mtricas bsicas de PSP. 2.3.1 Basic PSP measures (Mtricas Bsicas de PSP) Las mtricas bsicas de PSP son el tiempo, tamao, calidad (defectos), y datos de calendario. 2.3.2 Time measures (Metricas de Tiempo) El tiempo se mide en minutos y se registra mientras se est haciendo el trabajo, porque los tiempos registrados despus es ms probable que sean inexactos. Los componentes bsicos 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 medicin del tiempo para una tarea o fase del proceso. Si hay una interrupcin durante el trabajo, ese tiempo se resta de la medicin del tiempo.

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 gestin administrativa y en reuniones, asistir a cursos de formacin, lectura de correo electrnico, o cualquiera de las otras actividades esenciales que un miembro del equipo debe hacer. off-task time para una tarea determinada o perodo 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 interrupcin). Los registros de tiempo son ms exactos cuando se recopilan con una herramienta automatizada, la herramienta debe ser capaz de registrar el inicio y finalizacin as como las fechas, calcular el tiempo transcurrido, y restar el tiempo de interrupcin del tiempo transcurrido para calcular el delta time. Cada entrada en el registro de tiempos debe tambin 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.

2.3.3 Size measures (mtricas de tamao) Una mtrica de tamao se utiliza para medir qu tan grande es un producto de trabajo. Las mtricas de tamao se seleccionan de manera que sean apropiadas para el producto de trabajo, por ejemplo, la utilizacin de pginas (en vez de palabras o letras) como una medida para documentos, o tomar en cuenta las tareas de programacin y el lenguaje para los componentes de software (ver 3.1 y reas de Conocimiento 3,2). Los datos de las mtricas de tamao deben recogerse en tiempo real en la medida de lo posible porque los datos recogidos despus de los hechos es ms probable que sean inexactos. La medicin de tamao se aplica no slo a los componentes del producto final, sino tambin a los componentes y versiones provisionales de los productos. Los datos de tamao son ms exactos cuando se recopilan utilizando una herramienta automtica en la que se registran tanto el tamao planeado como el real de los componentes de productos diferentes, usando las categoras de las mtricas estadsticas de tamao descritas en el 3.1.6. La herramienta debe calcular los totales de los datos para cada categora de tamao o de otra manera, garantizar la propia consistencia de los datos que obtiene. 2.3.4 Quality measures (defect data) medidas de calidad, datos de defectos En la PSP, la calidad del producto se mide en trminos de defectos. Un defecto es cualquier cosa en algn componente de software o del producto que debe ser cambiado para que sea correctamente diseado, desarrollado, mantenido, fortalecido, o usado. Los defectos pueden estar en el cdigo, diseo, requerimientos, especificaciones, u otra documentacin. 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 correccin. El tiempo de correccin 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: nmero de identificacin 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 descripcin. 2.3.5 Defect type standard (estandar de tipos de defectos) El estndar define las categoras dentro de las cuales pueden ser colocados defectos similares. La asignacin coherente de los defectos similares a la misma categora de tipo de defecto es fundamental para el anlisis del proceso. 2.3.6 Schedule measures (mtricas de fechas) Las mtricas 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 ms 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 cuestin, 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 informacin de las fechas de terminacin 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 relacin con el calendario previsto (ver 4.5).

2.3.7 Derived measures (mtricas deribadas) PSP ofrece un conjunto de mtricas de rendimiento y calidad para ayudar a las personas a aplicar y mejorar sus procesos personales. Las mtricas derivadas especficas se revisan en las reas de conocimiento posterior. Knowledge Area 2.4: Data Analysis (anlisis 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. 2.4.1 Measurement framework and data analysis (framework de medicin y anlisis de datos)

Todas las medidas en PSP estn relacionadas. Las personas deben entender cmo cada mtrica se relaciona con las dems y cmo pueden ser utilizados para obtener las medidas que proporcionan informacin sobre la eficacia del proceso. 2.4.2 Postmortem Un anlisis postmortem sobre el trabajo realizado en una fase o proyecto proporciona informacin valiosa Los datos del proyecto actualizado a la fecha, tamao, defectos, calendario (real, hasta la fecha, y porcentaje(%) a la fecha) los clculos actualizados de calidad y rendimiento una revisin del desempeo contra lo planeado banco de datos histricos actualizado para el tamao 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 diseo de las listas de inspeccin de cdigo indicados por los defectos que se escaparon de alguna fase, etc.) 2.4.3 Performance measures (mtricas de desempeo) Las medidas clave del desempeo del proceso personal son capacidad para cumplir los compromisos de calendario en el desarrollo de los componentes prometidos calidad de los elementos entregados mtricas de proyecto especificas

2.4.4 Performance baselines (lneas base del rendimiento) Antes de que las personas puedan mejorar su desempeo, primero tienen que comprender el nivel de su desempeo actual. Despus de recoger los suficientes datos del proyecto que nos proporcionen una cantidad significativa de informacin para el anlisis, las personas deben realizar un anlisis de base de su desempeo hasta la fecha y formular cambios adecuados en los procesos para mejorar su desempeo en las reas problemticas. 2.4.5 Combined measures (mtricas combinadas) Las mtricas 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 grfico que muestra las tendencias en el tamao estimado frente a tamao real para proporcionar datos para las futuras estimaciones de tamao. 2.4.6 Analyzing historical data (anlisis de datos histricos) Los datos deben ser examinados para determinar si son adecuados para el anlisis. Por ejemplo, los datos de los proyectos basados en el lenguaje C# no pueden proporcionar una correlacin adecuada para el anlisis de proyectos basados en el lenguaje C ++. Los datos histricos tambin deben ser examinados para determinar si la correlacin es adecuada y significativa como base para los procesos de medicin y anlisis del proyecto. 2.4.7 Analyzing size-estimating accuracy (Anlisis de la precisin de la estimacin del tamao) Los datos Histricos del tamao estimado frente a tamao 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 prediccin? Hay una tendencia a omitir partes en el diseo conceptual? Qu podra hacerse para mejorar las estimaciones? Estn las estimaciones de tamao sesgadas de alguna manera? Existe una tendencia a juzgar mal los tamaos relativos de las partes? Las estimaciones de tamao mejoran con el tiempo?

2.4.8 Analyzing effort-estimating accuracy Los datos histricos 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 prediccin? Los errores de estimacin de tamao se correlacionan con los errores de estimacin del esfuerzo? subestimar los proyectos correlaciona con un mayor porcentaje de retrabajo? Estn mejorando las estimaciones de esfuerzo? Qu podra hacerse para mejorar la exactitud de la estimacin?

2.4.9 Analyzing size and time relationships (analisis entre la relacion de tamao y tiempo) Los datos histricos del proceso personal pueden ser analizados para determinar cualquier relacin entre tamao 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, Cmo se podran explicar estas diferencias cuantitativas?

2.4.10 Analyzing phase yields (analizando los yields de las fases)

Los datos histricos del yield por fase del proceso personal pueden ser analizados para identificar los problemas y generar PIPs para posibles mejoras. Considere las siguientes preguntas Existe una relacin entre el yield y la tasa de revisin (tamao revisado por hora) para las revisiones de diseo cdigo? Son encuentran suficientes defectos en las fases adecuadas? Las revisiones se estn llevando a cabo de manera efectiva? Cul es el aprovechamiento, son los defectos personales eliminados provechosamente? Cul es el aprovechamiento personal de retiro de defectos para las diversas combinaciones de la fase de la valoracin/del incidente? 2.4.11 Analyzing defects injected per phase (analizando los defectos injectados por phase) Un anlisis de Paretto de los tipos de defectos es una herramienta til para analizar el proceso histrico de los datos personales de los defectos inyectada por fase. Considere las siguientes cuestiones. Determinar qu tipos de defectos se presentan con ms frecuencia. Determinar qu tipos de defectos tardan ms en encontrarse y corregirse. Analizar por fase y las tendencias generales de los defectos inyectado por unidad de tamao. Analizar por fase y las tendencias generales de los defectos inyectados por hora.

2.4.12 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 anlisis. Determinar el porcentaje de tiempo del proyecto PSP que toma hacer una prueba libre de defectos. Determinar cunto tiempo toman las pruebas para los proyectos de PSP. Determinar qu tipos de defectos son los ms costosos para encontrar y corregir en trminos de tiempo (por fase y por proyecto). Determinar los tipos de defectos ms comnmente encontrados en la compilacin y las pruebas personales. Determinar los tipos de defectos ms comnmente encontrados en las pruebas de producto y en el producto entregado. Generar un anlisis 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. 2.5.1 Rationale for process improvement (Justificacin de la mejora de procesos) Las razones para la implementacin 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. 2.5.2 Scope for process improvement (mbito de aplicacin del proceso de mejora) Muchos tipos de procesos pueden y deben ser utilizados, incluidos los personales, de equipo, y los procesos de la organizacin. Aunque las personas implicadas en la mejora del proceso vara en funcin del tipo de proceso, los principios y mtodos son idnticos 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 estn 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 pequeos cambios pueden hacerse cada vez que un proceso se utiliza.

2.5.3 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 ms proyectos que impliquen un trabajo similar. Establecer convenios de evaluacin comparativa con los individuos que hagan un trabajo similar. Al hacerlo, hay que considerar o o o o o la similitud del trabajo oportunidades para los equipos de interactuar y compartir datos relevantes material confidencial disposicin a la divulgacin gestin de las revisiones y la supervisin

Seleccionar los puntos de referencia de la mejor clase de entre los proyectos de colaboracin. Peridicamente establecer y actualizar los objetivos de referencia para el costo, fechas, y el rendimiento de calidad.

2.5.4 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 histricos del proceso para determinar las causas originales de los ltimos problemas de rendimiento. La ejecucin de un anlisis a fondo en las lneas base del rendimiento debe ayudar a los individuos a determinar las partes ms importantes para la mejora. Una vez que se han identificado los

cambios potenciales, es importante fijar metas apreciables de la mejora del funcionamiento (e.g., reducir el costo del retrabajo en 20%) para saber cundo se ha alcanzado la mejora deseada. 2.5.5 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. 2.5.6 Implement highest payoff improvements first (implementar primero las mejoras de mas alto valor) El anlisis de datos personales genera muchas PIPs. Los auditores deben decidir la aplicacin de la PIP que ofrecen el mayor potencial de mejora en comparacin con el esfuerzo requerido para hacer los cambios. 2.5. 7 Measure process changes (Mtricas 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 tambin ser conscientes del impacto que los cambios pueden tener en la aplicabilidad de sus datos histricos para el trabajo futuro que se realizar con el proceso modificado. 2.5.8 Monitor performance results (Monitor de resultados de desempeo) Para determinar si las mejoras de proceso ejecutadas han sido eficaces, Los profesionales de PSP peridicamente debe repetir los pasos para la lnea 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 opinin 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 estn bajo presin o cuando un buen resultado es especialmente crtico, negando as el desempeo 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. 2.5.9 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 problemticas y ser conscientes de las ideas para la mejora continua. Competency Area 3: Size Measuring and Estimating (mtricas de tamao y estimacin) Esta rea de competencia se describe la medicin de tamao y la estimacin de los conceptos en que se basa PSP. Los elementos esenciales de la medicin y estimacin de tamao son la capacidad de definir las medidas de tamao adecuado y utilizar mtodos disciplinados y datos histricos para calcular el tamao. Las reas de conocimiento principales que componen esta rea de competencia son las siguientes: 3.1 Size Measures (mtricas de tamao) Esta rea de conocimiento se exponen los objetivos para medir el tamao, los criterios para la seleccin de una medida de tamao, y el sistema de conteo de tamao de PSP. 3.2 Size Data (datos de tamao) Esta rea de conocimiento describe las principales formas en que los datos de tamao se utilizan en PSP. 3.3 Size Estimating Principles (principios de estimacin de tamao) En esta rea de conocimiento se revisan los principios sobre los cuales se basa el proceso de estimacin de tamao de PSP. El PSP apoya la estimacin de tamao de muchos mtodos, pero todos los mtodos deben adherirse a estos principios. 3.4 Proxies Esta rea de conocimiento se describe la seleccin y organizacin de los datos de proxy. 3.5 The PROBE Estimating Method (el mtodo de estimacin PROBE) PSP utiliza un proceso de estimacin definido llamado basado en proxies (PROBE). Este mtodo se utiliza para estimar tanto el tamao como el esfuerzo. Esta rea de conocimiento define cmo las estimaciones del tamao se realizan mediante el mtodo PROBE. 3.6 Combining Estimates (combinacin de estimaciones) Esta rea de conocimiento describe las distintas maneras en que las estimaciones pueden ser combinadas 3.7 Size Estimation Guidelines (guias de estimacin de tamao) Esta rea de conocimiento se explican las limitaciones de la estimacin de tamao. Knowledge Area 3.1: Size Measures (mtricas de tamao) Esta rea de conocimiento se exponen los objetivos para medir el tamao, los criterios para la seleccin de una medida de tamao, y el sistema de conteo de tamao de PSP. 3.1.1 Rationale for using size measures (Justificacin para el uso de medidas de tamao) Entre los objetivos para utilizar mtricas de tamao se incluyen lograr la coherencia en la descripcin de tamao

normalizar los datos de tiempo y defectos lograr mejores estimaciones de tamao y planes

3.1.2 Types of measures (tipos de mtricas) Las mtricas pueden clasificarse como: Absolutas o relativas Explicitas o derivadas objetivas o subjetivas dinmicas o estticas predictivas or explicativas

3.1.3 Criteria for size measures (Criterios para las mtricas de tamao) Las buenas mtricas de tamao deben ser relacionadas con el esfuerzo de desarrollo o o el tamao del producto correlaciona estadsticamente con el esfuerzo de desarrollo? El tiempo invertido en el desarrollo de las partes medidas del producto representan una parte significativa del trabajo del proyecto? definidas con precisin directamente contables adecuados para la planificacin temprana

3.1.4 Counting standards (estndares de conteo) Los estndares de conteo proveen una gua que es precisa sobre lo que debe contar especfica para el lenguaje y el tipo de aplicacin invariable, que de el mismo resultado cada vez que el estndar se aplica

3.1.5 Physical and logical size (tamao fsico y lgico) Una medida de tamao fsico proporciona informacin acerca del tamao de una entidad fsica (el nmero real de ocurrencias de un elemento en algn producto). Una medida de tamao lgico tambin proporciona informacin sobre el tamao, pero se basa en el recuento de las agrupaciones de entidades fsicas que, se pueden agrupar lgicamente. La medida lgica del tamao de una entidad fsica no corresponde necesariamente a la medida fsica del tamao de esa misma entidad, dependiendo del estndar de conteo definido para la medida lgica. 3.1.6 Size accounting (conteo de tamao) Los mtodos de conteo de tamao de PSP para el tamao planeado, actual, y a la fecha define mtricas para base (B): la parte no modificada del programa a la que se aaden mejoras posteriores added (A): cdigo que se agrega a la base modified (M): la parte de la base de cdigo que se cambia deleted (D): la parte de la base de cdigo 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 cdigo aadido y modificado new reusable (NR): una parte o elemento que se desarrolla con la intencin de volverlo a utilizar despus total (T): el tamao complete del programa

3.1.7 Using the size measure selection procedure Los pasos para la seleccin de medidas de tamao son las siguientes. 1. 2. 3. 4. Recopilar datos sobre el desarrollo de productos (recursos necesarios, las medidas de las caractersticas del producto, las condiciones especiales de desarrollo, etc.) Ordenar los productos con base en los recursos necesarios. Identificar las caractersticas que distinguen a los productos que requrieron el mayor esfuerzo de los que requirieron el menor esfuerzo. Seleccione una mtrica o mtricas de tamao. Para las mtricas de tamao viables determinar la correlacin entre el tamao y los recursos necesarios. Si no hay una correlacin, repita los pasos 3 y 4 para las otras mtricas de tamao viables. Algunas mtricas tpicas de tamao incluyen elementos de base de datos: un recuento de los campos, consultas, o de otros elementos de uso comn en un producto de lneas de cdigo (LOC): un recuento de las lneas lgicas de cdigo en un producto. elementos de la pantalla: un recuento de los elementos de una interfaz de usuario o GUI del producto. Tamao del documento: un conteo de las paginas, lneas, palabras o caracteres del documento. Tamao del diseo: un conteo de las clases, definiciones de datos, especificaciones de interface, o caractersticas definidas Tamao de los requerimientos: un conteo de pginas de requerimientos, narrativas o puntos de funcin. base de datos.

de interfaz grafica de usuario.

Knowledge Area 3.2: Size Data (datos de tamao) Esta rea de conocimiento describe las principales formas en que los datos de tamao se utilizan en PSP. 3.2.1 Size data help to make better plans (los datos ayudan a hacer mejores planes) El tamao y el tiempo a menudo se relacionan, y cuando eso ocurre, las estimaciones de tamao se pueden utilizar para estimar el esfuerzo. Los planes pueden ser creados con base en las estimaciones de tamao y esfuerzo. 3.2.2 Size data are useful for tracking development effort (los datos de tamao son tiles para el seguimiento del esfuerzo de desarrollo) Tamao y el tiempo a menudo se relacionan, y cuando lo son, las estimaciones de tamao se puede utilizar para dar seguimiento al esfuerzo. 3.2.3 Size data help in assessing program quality (los datos de tamao ayudan a evaluar la calidad del programa) La normalizacin de los datos de los defectos basndose en el tamao 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 estimacin de tamao) En esta rea de conocimiento se revisan los principios sobre los cuales se basa el proceso de estimacin de tamao de PSP. El PSP apoya la estimacin de tamao de muchos mtodos, pero todos los mtodos deben adherirse a estos principios. 3.3.1 Estimating is uncertain (la estimacin es incierta) Nadie sabe cun grande ser el producto, y mientras mas pronto en el proceso se hace la estimacin, menos se sabe. Las estimaciones pueden estar sesgadas por las necesidades comerciales y otras presiones. 3.3.2 Estimating is a learning process (la estimacin es un proceso de aprendizaje) La estimacin de mejora con la experiencia y con los datos. 3.3.3 Estimating is a skill (Estimar es una habilidad) Algunas personas pueden ser mejores estimando que otras. La mayora de las personas mejoran en la estimacin mediante la prctica. 3.3.4 Strive for consistency (Luchar por la coherencia) El objetivo del proceso de estimacin del tamao es que que constantemente se generen estimaciones objetivas hechas de la misma manera. Hacerlo, equilibrar las sobreestimaciones y las subestimaciones. 3.3.5 Use defined methods for making estimates(Uso de metodos definidos para hacer estimaciones) Utilizar un proceso definido de estimacin de tamao facilita el aprendizaje, proporciona una estructura para el uso de datos histricos, establece una lnea de referencia contra la cual se puede medir la mejora, y ayuda a eliminar el sesgo en el proceso. 3.3.6 Estimates are subject to error (Las estimaciones estn sujetas a error) La exactitud de estimaciones fluctuar alrededor de una media. Las estimaciones pueden tambin tener cierto sesgo 3.3.7 Estimate in detail (Estimacin 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 estimacin de detalle tambin ayuda a asegurar que la estimacin est completa. 3.3.8 Use historical data to make estimates (utilizar datos historicos para hacer estimaciones) Al hacer las estimaciones de tamao, encontrar una manera de utilizar cualquier dato histrico disponible. Knowledge Area 3.4: Proxies (Proxies) Esta rea de conocimiento se describe la seleccin y organizacin de los datos de los proxies. 3.4.1 Using proxies instead of a size measure (Usando proxies en lugar de una mtrica de tamao) La mayora de las medidas de tamao que cumplen los criterios necesarios no estn disponibles durante la planeacin. Un proxy es una medida sustituta que relaciona el tamao del producto con la funcionalidad planeada y proporciona un promedio en la fase de planeacin para juzgar (y por lo tanto, estimar) la probabilidad del tamao de un producto. 3.4.2 Criteria for choosing a proxy (criterios para elegir un proxy) Los criterios de un buen proxy son los siguientes. El tamao de la mtrica 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.

El proxy debe ser fcil 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 implementacin que afectan el costo o el esfuerzo.

3.4.3 Using relative size tables (usando tablas de tamaos relativos) Las tablas de tamao relativo se utilizan para organizar los datos de los proxies para que los datos histricos puedan ser utilizados para estimar el tamao de partes nuevas semejantes. 3.4.4 Building a relative size table (construyendo tablas de tamao relativo) PSP establece dos procedimientos para la creacin de una tabla de datos histricos de tamaos relativos: el mtodo de clasificacin y el mtodo de la desviacin estndar. Otros mtodos pueden ser utilizados, pero deben cumplir con los principios de estimacin de tamao. 3.4.5 Building a relative size table with the sort procedure Cuando se utiliza el procedimiento de clasificacin para la construccin de una tabla del tamao relativo, las partes estn separadas en categoras funcionales, tales como el clculo, texto, datos, etc. La tabla se llena completando los pasos siguientes para cada categora: 1. Ordenar los datos de tamao. 2. Elija el valor ms pequeo como muy pequeo (VS). 3. Elija el valor ms grande como muy grande (VL). 4. Escoja el valor de la mediana como medio (M). 5. Para grande (L) y pequeo (S), elegir el punto medio entre M y VL, y M y VS, respectivamente. 3.4.6 Building a relative size table with the standard deviation procedure (La construccin de una tabla de tamao relativo con el procedimiento de la desviacin estndar) Cuando se utiliza el procedimiento de la desviacin estndar para la creacin de una tabla de tamao relativo, las partes se han separado en categoras funcionales, tales como el clculo, texto, datos, etc La tabla se llena completando los pasos siguientes para cada categora: 1. Si los datos son una distribucin logartmica normal (como es usualmente el caso de los datos de tamao de programa), transformar los datos en una distribucin normal mediante el clculo del logaritmo natural de cada dato, de no ser as saltarse este paso. 2. Calcular la media (avg) y la desviacin estndar (s) del conjunto de datos. 3. Calcular la mediana de los tamaos a travez de VS = avg2S; S = avgS; M = avg; L = avg+s; VL = avg+2s. 4. Si los datos originales fueron una distribucin logartmica normal, aplicar la transformacin inversa mediante el clculo 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 mtodo de estimacin PROBE) PSP utiliza un proceso de estimacin definido llamado basado en proxies (PROBE). Este mtodo se utiliza para estimar tanto el tamao como el esfuerzo. Esta rea de conocimiento define cmo las estimaciones del tamao se realizan mediante el mtodo PROBE. 3.5.1 What is PROBE? (Qu es PROBE?) PROBE es un procedimiento para estimar el tamao y el esfuerzo. El procedimiento general es el siguiente. 1. Desarrollar el diseo conceptual (vase 3.5.2). 2. Identificar y clasificar los proxies. 3. Estimar los otros elementos. 4. Estimar el tamao del programa. (Seleccione el mtodo PROBE apropiado, como se describe en 3.3.5.) 5. Calcular los intervalos de prediccin (para los mtodos A y B solamente) (vase 3.5.8). 3.5.2 Conceptual design (diseo conceptual) El diseo conceptual es una representacin de alto nivel de los elementos del producto y de sus funciones. El diseo conceptual divide un producto deseado en sus partes principales. El diseo conceptual se utiliza nicamente como una base para construir la estimacin de tamao y esfuerzo (ver 4.2.4) y no necesariamente refleja cmo el producto real ser diseado y construido. 3.5.3 Formulate size estimates for proxies (Formular las estimaciones del tamao de los proxies) Compare el tamao de las piezas nuevas en el diseo conceptual contra las partes similares en la base de datos histrica de acuerdo al tipo y tamao relativo. Utilice el nmero de elementos por parte y los datos histricos de tamao por parte para estimar el tamao de proxy. 3.5.4 Formulate estimates for various types of program elements (Formular las estimaciones para los distintos tipos de elementos de programa) Conteo de tamao base (B). Modificaciones Estimadas (M). Eliminaciones Estimadas (D). Adiciones a la base Estimadas (BA). Partes Aaadidas Estimadas (PA). Reuso Estimado (R). Estimacion de nuevo reuso planeado (NR).

3.5.5 Select the appropriate PROBE method

1.

Compruebe si el mtodo A puede ser utilizado para asegurar que los datos cumplen los criterios de abajo, y la correlacin de la evaluacin, 0, y 1. o o o o Usted tiene tres o ms puntos de datos (estimados E y reales A&M) que correlacionan. El valor absoluto de 0 es inferior al 25% del tamao esperado del nuevo programa. 1 se sita entre 0,5 y 2. Si el mtodo PROBE se puede utilizar, entonces, calcular el tamao proyectado como y = 0 + 1(E), donde o y = tamao proyectado de modificaciones y aadiduras E = tamao estimado del proxy

0 y 1 se calculan utilizando el tamao de proxy estimado y el tamao real de aadiduras y modificaciones

2.

Si el mtodo A no puede ser usado, revise para ver si el mtodo B se puede utilizar. o o o o Usted tiene tres o ms puntos de datos (A&M planeadas y A&M reales) que correlacionan. El valor absoluto de 0 es inferior al 25% del tamao esperado del nuevo programa. 1 se sita entre 0,5 y 2. Si el mtodo PROBE B se puede utilizar, entonces, calcular el tamao proyectado como y = 0 + 1(E), donde o y = tamao proyectado de modificaciones y aadiduras E = tamao estimado del proxy

0 y 1 se calculan utilizando el tamao pleaneado de aadiduras y modificaciones y el tamao real de aadiduras y

3.

modificaciones. Si los mtodos A y B no puede ser utilizados y se tiene datos histricos, utilice el mtodo C. Calcular el tamao del proyecto como y = 0 + 1 (E), donde o o o o y = tamao proyectado de modificaciones y aadiduras E = tamao estimado del proxy 0 = 0 1 = ActualTotalAdded&ModifiedSizeToDate

4.

o PlanTotalAdded&ModifiedSizeToDate Si usted no tiene datos histricos, utilice el mtodo D, que consiste en utilizar su juicio para estimar el tamao de aadiduras y modificaciones.

3.5.6 Estimate program size (Estimar el tamao del programa) Calcular el tamao del proxy estimado, E = BA + PA + M. Calcular el tamao proyectado de A&M, P = 0 + 1 (E), para los mtodos A, B, y C. Para el mtodo D, P = tu juicio Calcular el tamao de aadiduras planeado, A = A&M M. Calcular el tamao total planeado, T = P + B M + R.

profesional

3.5.7 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 tamao real del proxy, E = BA+PA+M. Contar el tamao total real, T. Calcular el tamao real de aadiduras, A = T-B+D-R. Calcular el tamao actual de aadiduras y modificaciones, A&M = A+M. Contar el tamao real de reuso nuevo, NR.

3.5.8 Prediction interval definition (Definicin de intervalo de prediccin) El intervalo de prediccin se utiliza en los mtodos PROBE A y B. Un intervalo de prediccin es el intervalo en que el tamao real es probable que caiga el 70% del tiempo no un pronstico aplicable solamente si la estimacin se comporta como datos histricos

Knowledge Area 3.6: Combining Estimates (La combinacin de estimaciones) Esta rea de conocimiento describe las distintas maneras en que las estimaciones pueden ser combinadas. 3.6.1 Combine independent estimates (combinar estimaciones independientes) Utilice este mtodo de combinar estimaciones independientes. 1. Hacer proyecciones de regresin lineal separadas. 2. Sumar los tamaos proyectados. 3. Sume los cuadrados de los rangos individuales y calcule la raz cuadrada para calcular intervalo de la prediccin. 3.6.2 Use multiple proxies (utilizar multiples proxies) Utilice regresin mltiple cuando hay (a) correlacin entre el tiempo de desarrollo y cada proxy y (b) los proxies no tienen datos de tamao y tiempo separados. 1. Identifique y clasifique cada proxie. 2. Utilice regresin mltiple para proyectar el tamao del programa. y = 0 + x11 + x22 + . . . xmm 3. Calcular los intervalos de prediccin.

UPI = projected size + range (70%) LPI = projected size range (70%) Knowledge Area 3.7: Size Estimation Guidelines (Directrices de la estimacin del tamao) Esta rea de conocimiento describe las limitaciones de la estimacin de tamao. 3.7.1 Clustered or grouped data (datos amontonados o agrupados) Para datos amontonados o agrupados, las estimaciones de tamao pueden no ser muy tiles para estimar esfuerzo. Sin embargo, la estimacin de tamao todava puede ser til en el clculo del esfuerzo promedio. 3.7.2 Extreme data points (Puntos de datos extremos) Puntos extremos de datos pueden llevar a valores 0 y 1 errneos, incluso habiendo alta correlacin. Estimaciones hechas con puntos fuera de rango de los datos utilizados para calcular 0 y 1 son seriamente probables de estar equivocadas. 3.7.3 Unprecedented products (Productos sin precedentes) Resstase a hacer una estimacin antes de terminar un estudio de viabilidad y un desarrollo de prototipos. No confunda el hacer estimacin con adivinar. 3.7.4 Data range (rango de datos) Para datos amontonados o agrupados, las estimaciones de tamao pueden no ser muy tiles para estimar esfuerzo. Sin embargo, la estimacin de tamao todava puede ser til en el clculo 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 estimacin de tamao del software para planear y dar seguimiento a un proyecto de software. Partes esenciales de la planificacin del proyecto son la capacidad de construir una agenda, definir tareas, planear las tareas de conformidad a la agenda, y hacer un seguimiento de finalizacin 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 planeacin) Esta rea de conocimiento enuncia los principios sobre los que se basa el marco de planificacin de PSP. 4.2 The PSP Planning Framework (marco de planificacin de PSP) Esta rea de conocimiento delimita el marco de PSP que integra las tareas de planificacin, bases de datos histricos, y el seguimiento de las actividades. Tambin dirige mediante PROBE para generar estimaciones de recursos en general. 4.3 Software Size and Effort (tamao del software y esfuerzo) La planificacin de proyectos requiere una estimacin del tamao del software (vase el rea de Competencia 3). Esta rea de conocimiento se describe la relacin entre el tamao y esfuerzo. 4.4 Task and Schedule Planning (tareas y calendario de planeacion) Esta rea de conocimiento describe cmo utilizar una estimacin global de los recursos para crear una agenda que define las tareas que deben completarse y la fecha de finalizacin 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 clculo 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 administracin debe mantenerse informada del estatus de proyecto. Los proyectos que no sern terminados a tiempo deben ser replaneados. Knowledge Area 4.1: PSP Planning Principles (principios de planeacin) Esta rea de conocimiento enuncia los principios sobre los que se basa el marco de planificacin de PSP. 4.1.1 Plan your work (planea tu trabajo) Las personas que hacen el trabajo son los ms adecuados para planificar. Las personas siempre deben desarrollar un plan de trabajo antes de comprometerse o iniciar un proyecto. Cuando las personas estn involucradas en el desarrollo del plan, es ms probable que se apeguen a ese plan. Los planes deben basarse en un proceso definido y datos histricos, y estar hecho con un nivel de detalle apropiado para el trabajo a realizar. Cuando es difcil hacer un plan exacto, comience con un plan preliminar y replanifique a menudo. Cuando el plan no corresponde al trabajo, revisar el plan. 4.1.2 What is a PSP plan? (que es un plan de PSP) Un plan de PSP define el trabajo y cmo se har es una base para un acuerdo sobre el costo, horario, y los recursos para un proyecto es una organizacin estructurada para hacer el trabajo es un marco para la obtencin de los recursos necesarios proporciona un registro a lo que inicialmente nos hemos comprometido

4.1.3 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 ms precisos, proporcionan medidas ms precisas, y dan una mejor orientacin para los planes de alto nivel. Los planes detallados tambin permiten que las personas puedan hacer proyecciones precisas y compromisos realistas, ser ms productivos, hacer un trabajo de alta calidad, y mantener su motivacin para alcanzar los objetivos del plan.

Knowledge Area 4.2: The PSP Planning Framework (El Marco de Planificacin de PSP) Esta rea de conocimiento delimita el marco de PSP que integra las tareas de planificacin, bases de datos histricos, y el seguimiento de las actividades. Tambin dirige usando PROBE para generar estimaciones totales del recurso. 4.2.1 Software product plan components (Plan de producto de componentes de software) Los componentes de un plan de producto de software son las siguientes. El tamao del proyecto: Qu tan grande es el proyecto y cunto tiempo se necesitar para realizar el proyecto en su Estructura del proyecto: Cmo se llevar a cabo el trabajo? Cmo debe ser secuenciado las tareas? Estado del proyecto: Cul es el estado del proyecto en un momento determinado? Cmo puede estimarse la fecha de Evaluacin: Comparar los datos reales contra los estimados. Qu tan bueno fue el plan? Cmo se puede mejorar el plan conjunto?

finalizacin? la prxima vez? 4.2.2 PSP planning framework (Marco de planificacin de PSP) El marco de planificacin de PSP consiste en siete tareas bsicas.

1. 2. 3. 4. 5. 6. 7.

Definir los requerimientos (see 4.2.3). Producir el diseo conceptual (see 4.2.4). Producir la estimacin de tamao del producto (see 3.5.5). Producir la estimacin de recursos (see 4.2.6). Producir el calendario (see 4.2.10 and 4.5). Desarrollar el producto (see 4.2.11). Analizar el proceso (see 4.2.12 and 2.3.2).

4.2.3 Requirements definition (La definicin de requerimientos) Empezar por definir el trabajo a realizar, en tanto detalle como sea posible. La precisin del plan depende de cunto sepan las personas acerca de la labor a realizar en el momento en que se est planificando. 4.2.4 Produce the conceptual design (producir el diseo conceptual) El diseo conceptual (vase 3.5.2) es un acercamiento preliminar al producto, nombra los objetos previstos y sus funciones. Al hacer un diseo 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 diseo conceptual. Producir una lista preliminar de objetos del producto y sus funciones esperadas. o o Comience con un diseo de alto nivel del sistema o del producto. Subdividir las piezas resultantes en un nivel de detalle que corresponda a los elementos existentes en la base de datos histrica (si las hay). Utilice el mtodo PROBE adecuado para producir estimaciones de recursos y de tamao. El total de la estimacin de los elementos para producir la estimacin del producto.

4.2.5 Use PROBE for size and resource estimation (Utilizar PROBE para estimar tamao y recursos) El mtodo PROBE se utiliza para estimar el tamao del producto y el tiempo necesario para hacer el trabajo (vase 3.5.5 y 4.2.6). 4.2.6 Select the appropriate PROBE method for resource estimation (seleccione el metodo PROBE adecuado para estimacion de recursos) Compruebe si el mtodo A puede ser utilizado. o o o o o o Se tienen tres o ms puntos de datos (E estimada y el tiempo de desarrollo real) que se correlacionan. El valor absolute de 0 est cerca de 0. 1 est dentro del 50% de 1/(productividad histrica). Se tienen tres o ms puntos de datos (A&M planeadas y el tiempo de desarrollo real) que se correlacionan. El valor absoluto de 0 est cerca de 0. 1 est dentro del 50% de 1/(productividad histrica).

Si el mtodo A no puede ser usado, revise para ver si el mtodo B se puede utilizar.

Si el mtodo B no puede ser utilizado y tiene datos histricos, utilice el mtodo C. Si usted no tiene datos histricos, utilice el mtodo D.

4.2.7 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 ms el tiempo a la fecha de esa fase histrico de proyectos. 4.2.8 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 da en cada fase. 4.2.9 Distributing time across phases (La distribucin de tiempo a travs de las fases) El tiempo planeado se distribuye a travs de fases usando el porcentaje de tiempo a la fecha en cada fase. 4.2.10 Schedule projection (proyeccin de calendario)

Un calendario de valor ganado proporciona una proyeccin de la fecha de terminacin del proyecto (ver 4.5). 4.2.11 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. 4.2.12 Process analysis (analisis de proceso) Al final de un proyecto, los datos recogidos son analizados (ver 2.3.2). 4.2.13 Cost performance index (CPI) (ndice de costo del desempeo) El ndice de costo del desempeo (CPI) se calcula como tiempo de desarrollo total planeado/tiempo real total a la fecha. Knowledge Area 4.3: Software Size and Effort (tamao y esfuerzo del software) La planificacin de proyectos requiere una estimacin del tamao del software (vase el rea de Competencia 3). Esta rea de conocimiento se describe la relacin entre el tamao y esfuerzo. 4.3.1 Size and effort correlation (correlacion de tamao con esfuerzo) Grandes proyectos de programacin requieren ms esfuerzo. Estimar con precisin el esfuerzo de programacin requiere el uso de una medida de tamao que tenga una correlacin significativa con el esfuerzo. Los datos de tamao son adecuados para la planificacin si el valor de r es ms grande que 0.5 y si y si el rea de la cola en el clculo de la significancia es = 0,05. 4.3.2 Productivity (productividad) La productividad es la relacin del tamao de un producto contra el tiempo dedicado a desarrollar este producto, por lo general se determina como medida de tamao por hora. Knowledge Area 4.4: Task and Schedule Planning (planeacion de tareas y calendario) Esta rea de conocimiento describe cmo utilizar una estimacin global de los recursos para crear una agenda que define las tareas que deben completarse y la fecha de finalizacin prevista. 4.4.1 Project plan characteristics (Las caractersticas del plan de proyecto) Un plan de proyecto debe ser accesible: fcil de localizar y de referenciar claro: concreto y fcil de leer Especfico: responsabilidades y costes identificados Preciso: nivel apropiado de precisin exacto: basado en datos relevantes y un proceso de clculo objetivo

4.4.2 Period plans and project plans (Planes del perodo y planes del proyecto) Un plan del perodo cubre una unidad de tiempo especfica, tal como una semana o un mes. Un plan del proyecto describe todos los esfuerzos y costes para desarrollar un producto. 4.4.3 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 contestacin del y email, atencin en reuniones, etc. 4.4.4 Milestones (hitos) Los hitos son los indicadores clave del progreso del proyecto. Sus fechas de terminacin pueden ser estimadas para poder seguir progreso contra ellas y los riesgos a su terminacin puedan ser tratados antes de que vaya el proyecto seriamente fuera de tiempo. 4.4.5 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 completarn esfuerzo estimado para cada tarea

4.4.6 Task order (orden de las tareas) El orden de las reas est determinado por la estrategia de desarrollo Cada tarea necesita criterios de la terminacin. Las interdependencias de las tareas deben estar definidas.

4.4.7 Estimated task time (tiempo estimado de las tareas) El tiempo necesario para completar la tarea se estima en una de varias maneras, mediante: El tamao del producto fabricado por la tarea y los datos histricos de productos con tareas similares una estimacin total basada en datos de porcentaje a la fecha de procesos terminados similares una tcnica apropiada PROBE de estimacin

4.4.8 PSP schedule plans (planes calendario) Los planes de calendario son producidos para los proyectos de PSP siguiendo estos tres pasos de progresin.

1. 2. 3.

Elija un perodo de tiempo adecuado (por ejemplo, de tres a seis meses a partir de la fecha de inicio planeda). Distribuya el tiempo disponible estimado para tareas a lo largo de la duracin del calendario del proyecto. Calcular el acumulativo de horas calendario planeadas al final de cada ciclo del proyecto.

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. 2. 3. 4.

Estimar el tiempo de trabajo en horas (vase 4.4.7). Calcular la suma del total de horas previstas. Calcule el plazo del plan en el cual cada tarea definida ser terminada, basado en el cronograma (vase 4.4.8). Calcular la fecha planeada para la finalizacin 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 clculo 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.5.1 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 tendra un PV de 10. 4.5.2 Earned value (EV) (valor ganado) Earned Value es un mtodo 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. 4.5.3 Using EV measures (usando metricas de valor ganado) Cuando se utiliza VE, tenga en cuenta estas limitaciones. El mtodo EV supone que la tasa de finalizacin de la tarea en el futuro ser aproximadamente la misma que en el pasado. Las medidas del mtodo de EV progresan en relacin con el plan. Si el plan es inexacto, las proyecciones de EV es tambin El mtodo de EV asume que los recursos del proyecto son uniformes. Si el nivel de personal aumenta, las proyecciones de Si este no es el caso, la proyeccion de EV no ser exacta. probable que sean inexactas. EV sern pesimistas, y si disminuye el personal, las proyecciones sern optimistas. 4.5.4 EV as a measure of actual progress relative to planned progress (EV como una forma de medir el progreso real en relacin 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 comparacin 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 ms grande que PV: el trabajo se termina antes de lo previsto PV es mayor que EV: el trabajo se ha retrasado

4.5.5 Project tracking with EV (Seguimiento del proyecto con EV) Durante la planificacin, el PV total de las tareas del proyecto se puede calcular para cada perodo de tiempo. Del mismo modo, sumando los EVs de las tareas completadas en cualquier perodo 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 4.5.4 above). 4.5.6 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 100. 4.5.7 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. 4.5.8 Calculating cumulative PV for a given time period (Clculo del PV acumulado para un perodo de tiempo determinado) El PV acumulado hasta la fecha en un perodo de tiempo determinado se calcula sumando los PVs de todos los plazos precedentes al PV del plazo dado. 4.5.9 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 perodo de tiempo determinado y el EV acumulado para ese mismo perodo 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 (vase 4.5.4 supra). 4.5.10 Estimating the project completion date (Estimacin de la fecha de terminacin del proyecto)

La fecha estimada de terminacin del proyecto se puede calcular mediante el clculo de la EV promedio por semana hasta la fecha y, a continuacin, utilizar el valor promedio de VE por semana para calcular el tiempo necesario para completar el valor planeado restante. Esto asume que el proyecto contina ganando la tasa media de EV como antes. Knowledge Area 4.6: Planning and Tracking Issues (Planeacion y seguimiento de Issues) La administracin debe mantenerse informada del estatus de proyecto. Los proyectos que no sern terminados a tiempo deben ser replaneados. 4.6.1 Informing management of issues (Informar a la administracion de los issues) Mantenga a la gerencia informada resultados de anlisis de valor ganado e infrmeles sobre problemas de cumplimiento del calendario. Los datos acerca del estado del proyecto pueden ser tiles para obtener ayuda de la administracin. 4.6.2 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 mtodos o los procesos del trabajo, el plan entero debe ser reexaminado. 4.6.3 Handling part-time assignments Asignaciones de tiempo parcial pueden ser problematicas porque porque las horas de trabajo se dividen entre varios proyectos. El intercambio conmutacin frecuente entre las tareas hace el trabajo en cualquier tarea se dificulte, y obstaculiza la coordinacin 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 satisfaccin 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 (mtricas de calidad) Los datos de PSP permiten la determinacin de medidas de calidad de producto y del proceso as como de la eficacia del proceso en la eliminacin de defectos. 5.3 Quality Methods (Mtodos de Calidad) Las revisiones personales son efectivas y una manera eficaz de mejorar la calidad del producto y la productividad individual. Los diversos mtodos de revisin son eficaces en diversas situaciones. 5.4 PSP Code Reviews (revisiones de codigo) Las revisiones de cdigo 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 revisin basada en la experiencia puede hacer revisiones ms eficientes y eficaces. 5.5 PSP Design Reviews (revisiones de diseo) Las revisiones de diseo deben seguir un proceso definido de revisin, usando los checklists que estn construidos sobre robustos principios de diseo. La coherencia en el seguimiento de una estrategia de revisin basada en la experiencia de medicin puede hacer revisiones ms 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. 5.1.1 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 gestin de su tiempo personal, y mantener la calidad como la mxima prioridad. 5.1.2 The economics of quality (la economa de la calidad) Es menos costoso encontrar y corregir los defectos antes en un proceso, que despus. Cuanto ms 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 ms eficiente prevenir los defectos que encontrarlos y arreglarlos La manera correcta es siempre la manera ms rpida y ms barata de producir un resultado de alta calidad. Las revisiones son fundamentalmente ms eficientes que las pruebas para encontrar y corregir defectos.

5.1.3 Product quality (La calidad del producto) Un producto de calidad es aquel que satisface al cliente. Este producto debe satisfacer un umbral mnimo de funcionalidad y utilidad. El producto tambin debe satisfacer las expectativas del usuario con respecto a un nmero de otros criterios. El producto debe funcionar, es decir, desempearse con una coherencia razonable. Si este objetivo no se logra, entonces o o o o rendimiento Seguridad invulnerabilidad Usabilidad nada es ms importante. Inquietudes adicionales de los usuarios podran incluir

funcionalidad

El producto debe proporcionar la funcionalidad que el usuario necesita y en el momento que lo necesita. En muchos proyectos de desarrollo, las percepcin 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. 5.1.4 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 sistemticamente ser utilizable y eficiente ser fcil de aprender y adaptarse a las nuevas circunstancias

Knowledge Area 5.2: Quality Measures (mtricas de calidad) Los datos de PSP permiten la determinacin de medidas de calidad de producto y del proceso as como de la eficacia del proceso en la eliminacin de defectos. 5.2.1 Personal defect data (datos personales de defectos) Los datos personales de defectos son tiles para comprender y refinar el proceso personal. El anlisis de estos datos proporciona un recurso valioso para la construccin de checklists personales de revisin. 5.2.2 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 histricos de los proyectos. 5.2.3 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. 5.2.4 Yield (rendimiento) El yield es el porcentaje de defectos en el producto que se eliminan en una fase particular o grupo de fases. Una mtrica de yield se puede calcular para cualquier fase o grupo de fases. 5.2.5 Phase Yield (yield de fase) Phase yield es el porcentaje de defectos removidos durante una fase. 5.2.6 Process Yield (yield del proceso) Process yield es el porcentaje de defectos removidos antes de entrar en la fase de compilacin (o antes de entrar a prueba la unidad si no hay fase de compilacin). 5.2.7 Review Yield (revision del yield) Review yield es el porcentaje de defectos en el programa encontrados durante la revisin. 5.2.8 Percent appraisal cost of quality (COQ) (Porcentaje de coste de evaluacin de la calidad) Percent appraisal cost of quality (COQ) es el porcentaje de tiempo de desarrollo empleado en el diseo y revisin de cdigo. 5.2.9 Percent failure COQ (Porcentaje de fracas de COQ) Percent failure COQ es el porcentaje de tiempo de desarrollo empleado en compilar y probar. 5.2.10 Cost of Quality (COQ) Costo de la calidad es el porcentaje de tiempo dedicado a realizar tareas de evaluacin y en tareas correctivas. COQ define los asuntos relativos a la calidad en trminos de gerencia y del negocio. Las principales mtricas 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 correccin de un producto defectuoso, incluyendo todos los costos derivados de las deficiencias prevention costs: los costos de la elaboracin e implementacin de medidas para prevenir fallas

del producto.

5.2.11 COQ appraisal to failure ratio (COQ A/FR) (COQ relacin de la evaluacin de las fallas) COQ A/FR es la proporcin de tiempo gastado en tareas de evaluacin con respecto al tiempo invertido en tareas de correccin de fallas. 5.2.12 Defect Density (densidad de defectos)

Densidad de defectos es el nmero de defectos detectados por medida de tamao. Se normaliza al tamao del producto para permitir la comparacin de diversos productos y procesos que los construyeron. 5.2.13 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. 2. 3. 4. 5.

Calidad de diseo se expresa como la proporcin del tiempo de diseo entre el tiempo de codificacin. Calidad de revisin del diseo es la proporcin de tiempo de revisin de diseo entre el tiempo de diseo. Calidad de revisin de cdigo es la proporcin del tiempo de revisin de cdigo de tiempo de codificacin. Calidad de codificacin es la proporcin de defectos de compilacin entre medida de tamao. Calidad del programa es la proporcin de defectos en pruebas de unidad entre una medida de tamao.

Los componentes PQI se normalizan a [0, 1] tal que el cero representa una mala prctica y el uno representa la prctica deseada. Las proporciones se representan en los ejes de un pentgono con la escala [0, 1]. El polgono resultante puede ser comparado con el pentgono que lo contiene para determinar la calidad del proceso. Los valores recomendados para cada componente PQI son los siguientes. La calidad del diseo es el mnimo de 1,0 o el tiempo empleado en hacer diseo detallado, dividido entre el tiempo empleado Calidad de revisin de diseo es el mnimo de 1,0 o dos veces el tiempo empleado en la revisin del diseo detallado, Calidad de revisin de Cdigo es el mnimo de 1,0 o dos veces el tiempo empleado en la revisin de cdigo dividido entre el Calidad de la revisin de cdigo es el mnimo de 1,0 o dos veces el tiempo empleado en la revisin de cdigo dividido por el La calidad del cdigo es el mnimo de 1,0 o 20/(10 + Defectos/Kloc en compilacion). La calidad del programa es el mnimo de 1,0 o 10/(5 + Defectos/Kloc en pruebas de unidad).

en codificacin. dividido entre el tiempo empleado en el diseo detallado). tiempo empleado en la codificacin. tiempo empleado en la codificacin.

5.2.14 Calculating values for the PQI components (Clculo de los valores de los componentes PQI) Para calcular e interpretar los valores PQI: Multiplicar los cinco mtricas de elementos PQI juntas para dar un nmero 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 ms

pobre la calidad es probable que sea. 5.2.15 Composite PQI (Compoestos PQI) Una medida PQI compuesta representa la calidad del proceso global para un proyecto que construy mltiples programas. Esta composicin 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. b. 2. Ventaja: Esta medida indicar rpidamente que un producto tiene componentes con valores bajos de PQI Desventaja: Para los grandes sistemas, los valores tienden a ser demasiado bajos para ser tiles en la gestin de sistemas de calidad. 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 sera la suma de los tiempos de revisin para todos los elementos de programa y los defectos de pruebas de unidad seran la densidad total del defecto para todos los programas combinados. a. b. 3. Ventaja: Esta medida tiene la ventaja de ser fcil de calcular y proporcionar un indicador general de la calidad global del producto. Desventaja: Algunos componentes de mala calidad no podrn ser percibido por que hay un nmero de componentes de alta calidad. La medida PQI mnimo se calcula utilizando el valor de PQI para este componente del programa que tuvo el valor de PQI mnimo. a. b. Ventaja: Esta medida tiene la ventaja de la rpida localizacin de cualquier componente de mala calidad. Desventaja: La medida no indica nada sobre la calidad del programa en general.

Puesto que no hay la mejor metrica compuesta para todos los propsitos, las metricas compuestas de PQI se deben utilizar con el cuidado y su significado ser explicados a conciencia. 5.2.16 Phase defect removal rate (la tasa de correccin de defectos) Para cada fase de un proceso, la tasa de correccin de defectos de la fase es el nmero de defectos encontrados por hora en esa fase. 5.2.17 Review Rate (tasa de revisin)

La tasa de revisin se refiere al tamao del producto revisado por hora. Esta tasa se calcula tanto para la fase de revisin como de inspeccin (vase 5.3.3). 5.2.18 Defect-removal leverage (DLR) Defect-removal leverage es una medida de la eficacia relativa de la eliminacin de defectos entre dos fases cualquiera del proceso. Por ejemplo, el DRL para la revisin del diseo con respecto a las pruebas de unidad se define como DRL (RD / UT) = defectos por hora en revisin del diseo dividido entre defectos por hora en la prueba de la unidad. Knowledge Area 5.3: Quality Methods (Mtodos de Calidad) Las revisiones personales son eficaces y un modo eficaz mejorar calidad del producto y productividad individual. Los varios mtodos de la revisin son eficaces en diversas situaciones. 5.3.1 Personal reviews (revisions personales) Una revisin personal es conducida por el individuo que examina su propio producto con la meta de encontrar y de reparar tantos defectos como sea posible. Las revisiones personales deben preceder cualquier otra actividad que utilice el producto (codificacin, compilacin, prueba, inspeccin, etc.). 5.3.2 Personal review principles (principios de revisin personal) Encuentre y repare todos los defectos en su trabajo. Use un checklist derivado de los datos personales de defectos. Sigue un proceso estructurado de revisin. Siga las prcticas sensatas de revisin. Mide tus revisiones. Usa datos histricos para mejorar tus revisiones Construye productos revisables. Utiliza los datos histricos para identificar dnde y por qu se inyectan los defectos para de cambiar el proceso para evitar

defectos similares en el futuro. 5.3.3 Inspections (insepecciones) Una inspeccin es una revisin estructurada en equipo de un componente o producto. El objeto de la inspeccin es identificar los problemas en el producto. Las inspecciones se conducen segn un procedimiento definido en que los asistentes desempean roles establecidos. correcta gestin de inspeccin, los participantes no discuten los problemas identificados, ni intentan solucionarlos. 5.3.4 Walkthroughs (recorridos) A walkthrough es menos formal que una inspeccin. Un producto, como un diseo o un segmento de cdigo, se presenta a una audiencia que plantea cuestiones y preguntas. 5.3.5 Relationship between reviews and inspections (relacin entre las revisiones y las inspecciones) Una revisin personal debe preceder a cualquier control. Una revisin antes de la inspeccin asegura que los inspectores buscan cuestiones finas, en lugar de errores evidentes. 5.3.6 Conducting effective personal reviews (condicir revisiones personales efectivas) Para lograr revisiones eficaces y eficientes, estas prcticas deben ser seguidas. Tmese un descanso entre el trabajo y la revisin. Haga la revisin de productos en forma impresa, y no en medios electrnicos. Marque cada punto cuando se vaya completando. Actualice los checklists peridicamente para responder a los cambios en los datos personales. Construir y utilizar una lista diferente para cada mtodo de diseo, el lenguaje de programacin, o tipo de producto. Analice y verifique a conciencia cada construccin no trivial del diseo (vase 6.6). En una

Knowledge Area 5.4: PSP Code Reviews (revisiones de cdigo revisiones) Las revisiones de cdigo deben seguir un proceso definido y emplear checklist construidas a partir de datos de defectos personales. La coherencia en el seguimiento de una estrategia de revisin basada en la experiencia puede hacer revisiones ms eficientes y eficaces. 5.4.1 Code review checklist (checklist de revisin de cdigo) Un checklist de revisin de cdigo es especfico para el proceso de codificacin de un individuo. Enumera las categoras de los defectos que han causado problemas en el pasado para que estos defectos se comprueba la durante la revisin. 5.4.2 PSP code review process (proceso de revisin de codigo) El proceso de la revisin de cdigo en PSP es como sigue. Obtenga el checklist de revisin de cdigo, estndar de codificacin, y estndar de defectos. Imprima una copia del cdigo para ser revisado.

Para cada categora de defecto en la lista, hacer una pasada completa sobre el cdigo y marque cada punto hasta Corregir todos los defectos y comprobar cada correccin de defecto para asegurar su correccin.

completarlos todos.

5.4.3 Code review strategy (estrategia de revisin de cdigo) Una estrategia de revisin deber basarse en datos que muestran que la estrategia sea eficaz. Una estrategia inicial consiste en de tal manera que las abastracciones procedurales sean revisadas y entendidas antes que las de ms alto nivel. Despus de que una estrategia se ha determinado como eficaz, debe ser seguido de forma coherente. Dependiendo del tipo de producto y del conocimiento individual del propio diseo, diversas estrategias de revisin pueden ser apropiadas. 5.4.4 Review against a coding standard (revisin contra un estndar de codificacin) Las revisiones de cdigo deben comprobar el cumplimiento de normas de codificacin. Los estndares aplicables de codificacin deben referirse en los checklist de revisin de cdigo. Knowledge Area 5.5: PSP Design Reviews (revisines de diseo PSP) Revisiones de diseo deben seguir un proceso de revisin de diseo, incluyendo anlisis de diseo adecuado, basado en checklists que se basan en los principios sensatos de diseo. La coherencia en el seguimiento de una estrategia de revisin basada en la experiencia de medicin pueden hacer revisiones ms eficiente y eficaz.

5.5.1 Design review principles (principios de revisin de diseo) Produce diseos que puedan ser revisados Sigue una estrategia de revisin explcitos. Revise el diseo en etapas. Compruebe que la lgica implementa correctamente los requisitos. Revisa las cuestiones de consistencia y seguridad.

5.5.2 Design review checklist (checklist de revisin de diseo) Una lista de comprobacin de la revisin de diseo es especfica a un proceso de diseo individual. Se basa en datos de defectos personales y listas de categoras de defectos que han causado problemas en el pasado para que estos defectos se comprueben durante la revisin. 5.5.3 PSP design reviews (revisions de diseo en PSP) El proceso de revisin del diseo en PSP es el siguiente. 1. 2. 3. 4. 5. Obtenga el checklist de revision de diseo y el estandar de diseo y de defectos. Imprime una copia del diseo a ser revisado si es pertinente. Para cada categora de defecto en la lista, hacer una pasada completa sobre el diseo y marque cada punto hasta terminar. Corregir todos los defectos y comprobar cada correccin de defecto para asegurar su correccin. Analice todas las construcciones complejas del diseo para verificar su correccin (vase 6.6).

5.5.4 Design review strategy (estrategia de revisin de diseo) Una estrategia de revisin deber basarse en datos que muestren que la estrategia es eficaz. Despus de que una estrategia ha determinado ser eficaz, debe ser seguida de forma coherente. Knowledge Area 5.6: Review Issues (aspectos de revision) Las revisiones pueden ser muy eficaces si se conducen usando guas que se basen en experiencia extensa y cuantitativa. 5.6.1 Review efficiency (eficiencia en la revisin) Las revisiones del diseo y de cdigo encuentran defectos directamente, ayudando al revisor a generar una imagen mental del comportamiento previsto del programa. En procesos grandes de desarrollo de sistemas, las revisiones del diseo y de cdigo son especialmente importantes porque los mtodos incrementales de PSP requieren que todos los incrementos sean de alta calidad. Para garantizar que los sistemas a gran escala alcancen la misma calidad que los sistemas ms pequeos, los scripts de PSP deben seguidos, y cada mdulo y / o incremento debe ser sometido a revisiones de diseo, revisiones de cdigo, y pruebas de regresin para garantizar que los nuevos incrementos no tengan problemas con mdulos funcionales previamente probados y aceptados. 5.6.2 Reviewing before or after compiling (Revisar antes o despus de compilar) Muchos entornos de desarrollo utilizan analizadores automticos de cdigo y/o compiladores que son muy tiles ya que su uso no se desanima. Sin embargo, para ser ms eficaz, la revisin debera ser realizada antes de usar el analizador de cdigo o el compilador. Las revisiones de cdigo deben realizarse antes de las pruebas. 5.6.3 Review objectives (objetivos de la revision) Las revisiones de cdigo correctamente conducidas reducen perceptiblemente tiempo de la prueba y producen los resultados de alta calidad. A menos que el individuo est comprometido a construir productos de alta calidad, el proceso de revisin es probable que sea

ineficaz. Las personas cuyo objetivo es comenzar a probar lo antes posible, rara vez realizan revisiones de cdigo o las hacen tan mal que son una prdida de tiempo.

Competency Area 6: Software Design El rea de competencia de diseo de software se describe la capacidad de incorporar el diseo y las actividades de verificacin de diseo en un proceso personal de desarrollo de software. Las reas de conocimiento principales que componen esta rea de competencia son las siguientes: 6.1 Software Design Principles Esta rea de conocimiento se describen los principios de diseo de software incorporados en PSP. 6.2 Design Strategies Esta rea de conocimiento aborda las estrategias de diseo utilizadas en PSP. 6.3 Design Quality Esta rea de conocimiento describe las caractersticas clave que se pueden utilizar para evaluar la calidad de un diseo de software. 6.4 Design Documentation Los diseos de software se deben documentar, junto con los requerimientos, las limitaciones, y el anlisis relacionados. Esta rea de conocimiento describe la documentacin de diseo que es responsabilidad de la persona. 6.5 Design Templates El PSP no especifica tcnicas de diseo, sino proporciona a un conjunto de modelos como marco para la documentacin del diseo. Los modelos ayudan a asegurar que un sistema y sus mdulos estn completamente y precisamente implementados. 6.6 Design Verification Para ser eficaz, la revision de diseo debe ir ms all de la simple lectura a travs de un documento de diseo. El PSP ofrece una serie de tcnicas de verificacin de diseo que pueden ser utilizados para identificar los errores y omisiones en los diseos de software. Knowledge Area 6.1: Software Design Principles Esta rea de conocimiento describe los principios de diseo de software incorporado en PSP. 6.1.1 Definition of software design Un diseo de software transforma un requerimiento dbilmente definido en una especificacin de producto realizable. 6.1.2 The design process Un proceso de diseo es el conjunto de pasos que se utilizan dentro de una metodologa para crear un diseo. El proceso de diseo debe dar lugar a una visin global de la solucin del requerimiento, que est esclarecida por los detalles de bajo nivel de la implementacin. No construye la solucin sino explora el espacio de solucin potencial y toma decisiones sobre la estructura y el comportamiento del producto previsto. 6.1.3 The role of design in the overall software development process El diseo de software conecta los requisitos de un sistema a su implementacin. Por el uso apropiado de la abstraccin, maneja la complejidad y se asegura de que los componentes de sistema trabajen juntos para producir los resultados deseados. 6.1.4 The requirements uncertainty principle Debido a que un nuevo sistema afecta a los usuarios y cambia sus necesidades, los requisitos para un sistema informtico a menudo no se saben totalmente hasta despus de que el producto terminado se pone en uso. El proceso de diseo debe proporcionar a una base estable para esta evolucin. 6.1.5 The role of design in PSP Los componentes bien diseados son crticos para el xito de los sistemas ms grandes que los usan. Los individuos deben emplear prcticas de diseo que puedan satisfacer las exigencias de la compleja y dinmica evolucin de los sistemas. 6.1.6 Design methodology in PSP El PSP no prescribe el uso de cualquier metodologa de diseo especfico, pero s define los requisitos para la documentacin de diseo. 6.1.7 Design specification structure Los elementos de un diseo completo se pueden especificar usando la siguiente estructura de especificacin. externa- esttica (la herencia, la estructura de clases) externa- dinmica (servicios, mensajes) interna-esttica (atributos, estructura del programa, lgica) interna-dinmica (mquina de estado)

6.1.8 Need for design precision Una especificacin de diseo debe ser precisa. La falta de un diseo preciso es la fuente de muchos errores de implementacin. Para obtener mejor precisin del diseo, especifique y documente las decisiones de diseo antes de entrar a la fase de codificacin. Knowledge Area 6.2: Design Strategies

Esta rea de conocimiento aborda las estrategias de diseo utilizadas en PSP. 6.2.1 The need for design strategies El diseo es un proceso intelectual complejo que no puede ser automtico, reducido a un procedimiento de rutina, o precisamente controlado ni pronosticado; sin embargo, algunas guas y estrategias pueden ser aprovechadas en la separacin de actividades rutinarias y creativas, para asegurarse de que el trabajo de diseo est realizado correctamente, e identificar las herramientas y mtodos de diseo eficaces. 6.2.2 Nature of the design process El diseo es un proceso de aprendizaje que requiere comnmente moverse entre los niveles de diseo y de una parte del sistema a otra. 6.2.3 Design process guidelines Cuando sea prctico, termine los diseos de alto nivel primero. Registrar todos los supuestos, las cuestiones pendientes, preguntas y problemas. Cuando sea apropiado, use prototipeo o experimentacin para reducir la incertidumbre antes de disear. No considere un diseo como terminado hasta que los diseos de todos los componentes interdependientes tambin se Documente todo el diseo (see 6.6).

terminen.

6.2.4 Types of design strategies Las estrategias de diseo pueden incluir el siguiente: progressive functional enhancement fast-path dummy

Knowledge Area 6.3: Design Quality Esta rea de conocimiento describe las caractersticas clave que se pueden utilizar para evaluar la calidad de un diseo de software. 6.3.1 Design precision Los diseos deben ser concretos y sin ambigedades. El diseo debe contener suficiente detalle para todos los usos previstos de la documentacin de diseo. 6.3.2 Design completeness Todos los detalles pertinentes deben ser incluidos, sin redundancias innecesarias. La documentacin de diseo no debe limitarse a los diseos de componentes individuales, sino que tambin debera Es provechoso incluir el anlisis de las decisiones de diseo; es a menudo provechoso documentar las alternativas que no

documentar el sistema en su conjunto y las consideraciones emergentes. fueron elegidas. 6.3.3 Design usability El diseo debe ser accesible y comprensible por todos sus usuarios. Knowledge Area 6.4: Design Documentation Los diseos de software se deben documentar, junto con los requerimientos, las limitaciones, y el anlisis relacionados. Esta rea de conocimiento describe la documentacin de diseo que es responsabilidad de la persona. 6.4.1 The need for software design documentation Los diseos de software se deben documentar, junto con los requerimientos, las limitaciones, y el anlisis relacionados, debido a que el diseo, a menos de que se trate de programas pequeos, es necesario para las personas que estarn involucradas con los productos consiguientes. Algunos ejemplos son los siguientes. El individuo: para facilitar la puesta en prctica, la verificacin, y la prueba del programa Los miembros del equipo: permitir las inspecciones de diseo y la coordinacin de diseo Testers: para permitir la planeacin de las pruebas. Administradores: para facilitar la mejora y reparacin Documentadores y usuarios: para que otros puedan entender lo que el producto hace y cmo funciona

6.4.2 Overall design documentation concerns Para garantizar que la documentacin de diseo, siga representando el producto, la documentacin de diseo debe ser auto consistente, y los cambios deben ser administrados y debidamente documentados. 6.4.3 Common types of design documentation

El individuo produce documentacin de diseo que cubre El contexto del programa La estructura del programa los componentes relacionados variables externas, llamadas y referencias descripcin detallada de la lgica de programacin para las decisiones de diseo, es a menudo provechoso documentar las

alternativas que no fueron elegidas 6.4.4 Design visibility La documentacin del diseo proporciona una representacin visible de un diseo usado para las revisiones y las verificaciones. El diseo se registra usando una notacin apropiada de diseo (vase 6.5.1). 6.4.5 Design documentation practice Una prctica til en la implementacin de un diseo es comenzar con el diseo del programa completo y, conforme cada seccin de diseo se implementa, encapsular ese segmento de diseo en una vista inmediatamente antes de la aplicacin. Knowledge Area 6.5: Design Templates El PSP no especifica tcnicas de diseo, sino proporciona a un conjunto de modelos como marco para la documentacin del diseo. Los modelos ayudan a asegurar que un sistema y sus mdulos estn completamente y precisamente implementados. 6.5.1 Design notation Una notacin basada en lgica matemtica puede ayudar en la produccin de documentacin de diseo, concisa y sin ambigedades. Ejemplos de ello son seudocodigo y Zed. Los siguientes criterios deben seguirse cuando se selecciona una notacin de diseo adecuada. La notacin de diseo debe ser capaz de representar de manera precisa y completa el diseo. Debe ser comprensible y til para la gente que va a usar y / o aplicar el diseo. Debe ayudar a los diseadores para producir un diseo de alta calidad. Debe ser compatible con el lenguaje de implementacin que se utilizar. Debe permitir rangos variables de dependencia de la implementacin

6.5.2 PSP design templates Los modelos de diseo de PSP representan la estructura esttica y el comportamiento dinmico de un sistema informtico, capturando las caractersticas externamente visibles y los detalles internos (vase 6.1.6). externa-dinamica: Use la plantilla de especificacin operacional (OST) y la plantilla de especificacin funcional (FST) para externa-statica: Use la plantilla de especificacion funcional (FST) para registrar esta informacion (see 6.5.4). interna-dinamica: Use la plantilla de especificacion de estado (SST) para registrar esta informacin (see 6.5.5). interna-statica: Use la plantilla de especificacion logica (LST) para registrar esta informacion (see 6.5.6). registrar esta informacin (see 6.5.3 and 6.5.4).

6.5.3 Operational specification template (OST) El OST documenta las caractersticas externa-dinmica de una parte de un sistema informtico. Describe uno o mas scenarios de participacion de la parte y los actores (e.g., users or other systems) que interactan con ella. Cada OST tiene un identificador nico, un objetivo de usuario, y un objetivo escenario. Para cada paso en un escenario la OST lista la fuente (system or specified actor) numero de paso accion comentarios

6.5.4 Functional specification template (FST) El FST documenta una parte (e.g., a class) de un sistema de software, sus relaciones externas-staticas, y susatributos visibles externamente. El FST tambin documenta las caractersticas externa-dinmica de una parte. Describe las acciones (e.g., mtodos de una clase) que la parte pone disponibles para el uso externo, esta descripcin incluye la interfaz definida para cada accin, incluyendo argumentos, restricciones, y resultados devueltos. 6.5.5 State specification template (SST) El SST documenta el comportamiento interno-dinmico de un sistema y de sus partes (e.g., clases) cuando ese comportamiento se representa como conjunto de estados, de transiciones entre los estados, y de acciones asociadas a las transiciones. El SST se puede complementar por un diagrama de estado separado que represente grficamente los estados, las condiciones de la transicin, y las acciones. Un SST contiene nombre y descripcin de los estados las funciones y los parmetros internos usados en la condiciones de transicin datalles de la transicin de estados estado actual

estado proximo condicin de transicin(predicado) accin que se realiza cuando ocurre la transicion

6.5.6 Logic specification template (LST) El LST documenta las caractersticas interno-estticas de una parte de un sistema informtico. Describe la lgica interna de la parte, usando pseudocdigo para explicar clara y concisamente su operacin. Tenga en cuenta que la informacin del LST puede estar embebida como comentarios en el cdigo fuente del programa, en lugar de utilizar un formulario separado, siempre y cuando sea clara y suficientemente detallada. 6.5.7 Template usage Las plantillas de diseo PSP pueden ser utilizadas para documentar un diseo producidos a partir de diferentes tcnicas de diseo utilizadas para documentar el diseo de un sistema de software existente, para apoyar el rediseo o verificacin complementadas o substituidas parcialmente por otras tcnicas de documentacin de diseo (e.g., UML), mientras la aplicado en diversos niveles de la jerarqua del diseo

informacin equivalente del diseo se registre en una forma fcilmente usable

Knowledge Area 6.6: Design Verification Para ser eficaz, la revision de diseo debe ir ms all de la simple lectura a travs de un documento de diseo. El PSP ofrece una serie de tcnicas de verificacin de diseo que pueden ser utilizados para identificar los errores y omisiones en los diseos de software. 6.6.1 Design standards Los diseos de software se pueden verificar contra los estndares, que promueven consistencia y calidad. Estos estndares pueden incluir Convenios de producto estandares de diseo de producto estandares de reuso

6.6.2 Verification methods Los mtodos de verificacin de software son: execution table verification trace-table verification state-machine verification loop verification other analytical verification methods 6.6.3 Choosing the appropriate design verification method Analice sus datos personales de defectos para determinar qu aspectos de diseo son ms propensos a defectos. No es un uso prudente del tiempo verificar aspectos de diseo donde se cometen pocos (o ningun) defectos. Evaluar la eficacia de los mtodos de verificacin actual. Identificar una familia de tcnicas eficaces y usarlas, incluso en Considere la economa de las tcnicas de verificacin actuales. Elija los mtodos de verificacin que sean ms eficaces

programas pequeos. personalmente y que se apliquen mejor a las condiciones del diseo. 6.6.4 Using execution table verification Identificar los bucles y rutinas complejas para la verificacin. Elija la orden del anlisis (e.g., arriba a abajo o abajo para arriba). Construya una tabla de ejecucin con los pasos del programa y valores relevantes de las variables, usando mltiples copias Verificar los resultados de la ejecucin en contra de la especificacin de requerimientos.

o bucles de iteracin.

6.6.5 Using trace-table verification Identifique los casos lgicos representativos para el anlisis. Para cada caso lgico, verifique usando una tabla de ejecucin.

6.6.6 Execution table verification vs. trace-table verification Distinga entre la verificacin execution table y trace-table y sepa cuando utilizarlas. 6.6.7 Using state-machine verification Revise la estructura de la maquina de estados para asegurarse que no tiene ningunos desvos o bucle ocultos, usando un diagrama de estado, si es prctico

Examine cada estado y verifique que el conjunto de transiciones de ese estado es completo (definido para todos los posibles Examine cada estado y verifique que las transiciones asociadas del estado son ortogonales (solamente una transicin

valores de condiciones de transicin). definida para cada conjunto de valores de la condicin de la transicin). 6.6.8 Using loop verification Verificar el inicio del bucle, incremento, y la terminacin, utilizando los mtodos de verificacin apropiados al tipo de ciclo Verificacin de ciclos for Verificacin de ciclos while Verificacin de ciclos repeat-until

Competency Area 7: Process Extensions and Customization El area de conocimiento Proceso de extencion y adecuacion describe las modificaciones al PSP que son requeridas cuando se escala de pequeos a grandes programas, al trabajar con situaciones o ambientes desconocidos, o al moverse al desarrollo basado en equipo en lugar de el trabajo en solitario. Las reas de conocimiento principales que componen esta rea de competencia son las siguientes: 7.1 Defining a Customized Personal Process Un proceso definido no debe ser considerada como un solo tamao para todos. Esta rea de conocimiento aborda situaciones en que los procesos deben adaptarse a las variaciones de los productos necesarios o desarrollados a partir de cero para hacer frente a nuevas situaciones o entornos. 7.2 Process Evolution Un proceso no se puede evolucionar para cubrir necesidades o situaciones cambiantes hasta que el proceso actual represente exactamente lo qu se hace realmente al usar ese proceso. Esta rea de conocimiento se refiere a la actividades relacionadas con el desarrollo incremental de un proceso inicial a uno que es una descripcin exacta y completa del proceso real. 7.3 Professional Responsibility El trabajo excepcional requiere comportamiento responsable de parte de un profesional. Esta rea del conocimiento describe algunas de las prcticas de profesionales responsables. Knowledge Area 7.1: Defining a Customized Personal Process Un proceso definido no debe ser considerada como un solo tamao para todos. Esta rea de conocimiento aborda situaciones en que los procesos deben adaptarse a las variaciones de los productos necesarios o desarrollados a partir de cero para hacer frente a nuevas situaciones o entornos. 7.1.1 When to define a new or customiz ed process Diferentes situaciones requieren diferentes mtodos: lo que funciona bien en un medio ambiente no puede ser eficaz en otro. Por ejemplo, las tareas de programacin simple puede requerir poco o nada de tiempo de diseo. Sin embargo, los sistemas ms grandes o sistemas de alta seguridad (independientemente de su tamao), requieren un diseo robusto. Un proceso sin una etapa de diseo puede requerir adecuacion para incluir esta actividad ala hora de adaptar un proceso existente para cubrir una nueva situacion, cuando la escalabilidad del proceso cambia o los requerimientos de seguridad cambian. 7.1.2 How to define a new or customized process Definicin de un proceso personal nuevo o personalizado sigue los mismos principios que para el desarrollo de software: comenzar con las necesidades del usuario, y terminar con la prueba final y la liberacin. Hay ocho pasos generales para la adaptacin o la creacin de un proceso personal. 1. 2. 3. 4. 5. 6. 7. 8. Determinar sus necesidades y prioridades. Definir los objetivos del proceso, las metas y los criterios de calidad.. Caracterizar el proceso actual Caracterizar el proceso deseado. Establecer una estrategia de desarrollo de proceso. Definir el proceso inicial. Validar el proceso inicial. Mejorar el proceso.

7.1.3 Using information mapping for documenting a new or customized process Al adaptar un proceso existente (o desarrollo de scripts y las plantillas a partir de cero), siga los siguientes principios de mapeo de informacin [Horn 90]. Chunking: Organizar la informacin en grupos que son manejables para leer y / o llevar a cabo. Relevance: Agrupar de acuerdo a las similares y excluir lo que noe sta relacionado para cada pedazo. Labeling: proveer al usuario de una etiqueta para cada pedazo de informacion. Consistency: Use terminus consistentes entre cada pedazo de informacion, entre el pedazo y la etiqueta, en la organizacion Integrate graphics: Usar tablas, ilustraciones y diagramas, como parte integral de la escritura. Accessible detail: Escribir en el nivel de detalle que haga que el documento sea til para todos los lectores. Hierarchy of chunking and labeling: Agrupe los pequeos pedazos alrededor de un solo asunto relevante y provea a cada

de la informacion y en el format del document en el que la informacion es registrada.

grupo con una etiqueta. Knowledge Area 7.2: Process Evolution

Un proceso no se puede evolucionar para cubrir necesidades o situaciones cambiantes hasta que el proceso actual represente exactamente lo qu se hace realmente al usar ese proceso. Esta rea de conocimiento se refiere a la actividades relacionadas con el desarrollo incremental de un proceso inicial a uno que es una descripcin exacta y completa del proceso real. 7.2.1 Initial process definition Las descripciones de proceso iniciales son raramente exactas, debido a un fenmeno anlogo al principio de incertidumbre de Heisenberg: el acto de definir un proceso cambia ese proceso. La descripcin inicial del proceso contiene generalmente omisiones, idealizaciones, y otras inexactitudes. El proceso de describir exactamente qu sucede, realmente afecta a menudo al proceso durante el acto mismo de definirlo. 7.2.2 Refining a personal process 1. 2. 3. 4. 5. Comience con una caracterizacin del proceso como se utilizan actualmente. Definir el objetivo o el proceso ideal. Definir los pasos necesarios para avanzar del proceso actual al proceso ideal. Desarrollar los scripts necesarios, formas, estandares y metricas para el uso del proceso. Revisar el proceso, ya que se est aplicando y corregir los errores identificados u omisiones.

Knowledge Area 7.3: Professional Responsibility El trabajo excepcional requiere comportamiento responsable de parte de un profesional. Esta rea del conocimiento describe algunas de las prcticas de profesionales responsables. 7.3.1 Use effective methods in your work Las buenas prcticas son sencillas, pero muy pocas personas los utilizan constantemente. El profesional dedicado encuentra constantemente mtodos efectivos para producir trabajo de alta calidad y luego usa esos mtodos. 7.3.2 Use data to discover your strengths and weaknesses Utilice el anlisis post mortem de sus datos personales para construir una comprensin de lo que usted hace bien y las reas donde usted necesita mejorar. Cntrese en llevar a cabo pequeas mejoras regularmente, y los cambios importantes vendrn por si solos. 7.3.3 Practice La clave para mejorar su trabajo es para practicar sus habilidades en el trabajo en la medida de lo posible. 7.3.4 Learn from others, and pass on what you know Hable con sus colegas y revise la literatura para aprender nuevas tcnicas y aprenda de los errores de otros. A medida que aprenda y construya su propio conocimiento, comparta lo que ha aprendido con los dems. Tome Beneficio de lo que encuentra y contribuya con lo que aprende. 7.3.5 Find and learn new methods Est atento a las innovaciones que sean pertinentes a sus necesidades personales. Asignar tiempo en su agenda para desarrollar sus habilidades siempre que sea posible. Al mantenerse al da, usted se hace ms atractivo para su empleador actual (y para los futuros empresarios) como un profesional competente y deseable.