Pspbok español-2.0

1
El Proceso Personal de SoftwareSM
(PSPSM
)
Cuerpo de Conocimiento, Versión 2.0
PSPBOK
Marsha Pomeroy-Huff
Robert Cannon
Timothy A. Chick
Julia Mullaney
William Nichols
August 2009
SPECIAL REPORT
CMU/SEI-2009-SR-018
Copyright 2009 Carnegie Mellon University.
NO WARRANTY
THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS
FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF
ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED
TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS
OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE
ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR
COPYRIGHT INFRINGEMENT.
SM
Team Software Process and TSP are service marks of Carnegie Mellon University.

2
Copyright Carnegie Mellon University.
Traducción NO oficial para uso interno
Traducción Inicial: Alexander Narvaez @narvaezberrio
Revisión y Actualización: SEONTI
Contenido
Competency Area 1: Foundational Knowledge (Fundamentos del Conocimiento) ....................................................................................8
1.1 Process Definition (Definición del Proceso).....................................................................................................................................8
1.2 Process Elements (Elementos del Proceso)....................................................................................................................................8
1.3 Measurement Principles (Principios de Medición) ...........................................................................................................................8
1.4 Statistical Elements (Elementos de Estadística)..............................................................................................................................8
Knowledge Area 1.1: Process Definition (Definición del Proceso) ........................................................................................................8
1.1.1 Process (Proceso) ....................................................................................................................................................................8
1.1.2 Defined process (Proceso Definido)..........................................................................................................................................8
1.1.3 Benefits of defining a process (Beneficios de definir un proceso)............................................................................................8
1.1.4 Process documentation (Documentación del proceso)..............................................................................................................8
1.1.5 Processes and plans (procesos y planes).................................................................................................................................8
1.1.6 Personal processes (proceso personal)....................................................................................................................................8
1.1.7 Enactable and operational processes (Patrón de procesos y procesos operativos) ..................................................................8
1.1.8 Process phases (Fases del proceso) ........................................................................................................................................8
1.1.9 The PSP process phases (las fases del proceso PSP) .............................................................................................................8
1.1.10 Incremental development (desarrollo incremental)..................................................................................................................9
1.1.11 Process tailoring (adaptación de procesos).............................................................................................................................9
1.1.12 Process building and refining (definición y refinamiento de procesos).....................................................................................9
Knowledge Area 1.2: Process Elements (Elementos del Proceso) .......................................................................................................9
1.2.1 Process elements (Elementos del Proceso)..............................................................................................................................9
1.2.2 Guiones (Scripts)......................................................................................................................................................................9
1.2.3 Forms (formas, formatos) .........................................................................................................................................................9
1.2.4 Measures (métricas).................................................................................................................................................................9
1.2.5 Standards (estándares) ............................................................................................................................................................9
Knowledge Area 1.3: Measurement Principles (Principios de medición)...............................................................................................9
1.3.1 The need for measures (la necesidad de usar métricas)......................................................................................................... 10
1.3.2 Measurement types (tipos de métricas) .................................................................................................................................. 10
1.3.3 Defined measures (métricas definidas)................................................................................................................................... 10
1.3.4 Precise and accurate measures (Métricas precisas y exactas) ............................................................................................... 10
1.3.5 Meaningful measures (Métricas significativas) ........................................................................................................................ 10
1.3.6 Uses of process measures (usos de las métricas de proceso)................................................................................................ 10
Knowledge Area 1.4: Statistical Elements (Elementos de Estadística) ................................................................................................ 10
1.4.1 Distributions (distribución)....................................................................................................................................................... 10
1.4.2 Mean (Media) ......................................................................................................................................................................... 10
1.4.3 Variance (Varianza)................................................................................................................................................................ 10
1.4.4 Standard deviation (Desviación estándar).............................................................................................................................. 10
1.4.5 Correlation (correlación) ......................................................................................................................................................... 10
1.4.6 Significance of a correlation (Significancia de una correlación) ............................................................................................... 10
1.4.7 Linear regression (Regresion Lineal) ...................................................................................................................................... 10
1.4.8 Prediction interval (Intervalo de predicción) ............................................................................................................................ 11
1.4.9 Multiple regression (regression multiple)................................................................................................................................. 11
1.4.10 Standard normal distribution (distribución normal estándar).................................................................................................. 11
1.4.11 Log-normal distribution (Distribución logarítmica normal)...................................................................................................... 11
1.4.12 Degrees of freedom (Grados de libertad).............................................................................................................................. 11
1.4.13 The t-distribution (la distribución T)....................................................................................................................................... 11
Competency Area 2: Basic PSP Concepts ............................................................................................................................................. 11
Knowledge Area 2.1: Process Fidelity (Adherencia al proceso).......................................................................................................... 11
2.1.1 Process fidelity (Adherencia al proceso) ............................................................................................................................... 11
2.1.2 Process fidelity and useful data (Adherencia al proceso y datos útiles)................................................................................... 11
2.1.3 Process fidelity and product quality (Adherencia al proceso y calidad del producto) ............................................................... 11
2.1.4 Process fidelity and planning (Adherencia al proceso y planeación) ....................................................................................... 12

3
2.1.5 Process fidelity and performance improvement (Adherencia al proceso y mejora del desempeño) ......................................... 12
Knowledge Area 2.2: Data Collection (Recolección de datos) ............................................................................................................. 12
2.2.1 Collecting data (recopilación de datos) ................................................................................................................................... 12
2.2.2 Collecting useful data (Recolección de datos útiles) .............................................................................................................. 12
2.2.3 Collecting high-quality data (recopilación de datos de alta calidad)......................................................................................... 12
2.2.4 Ensuring data quality (Garantizar la calidad de los datos)....................................................................................................... 12
2.2.5 Using data for planning purposes (Usar los datos para fines de planificación) ........................................................................ 12
Knowledge Area 2.3: Data Measures................................................................................................................................................. 13
2.3.1 Basic PSP measures (Métricas Básicas de PSP) .................................................................................................................. 13
2.3.2 Time measures (Metricas de Tiempo)..................................................................................................................................... 13
2.3.3 Size measures (métricas de tamaño)...................................................................................................................................... 13
2.3.4 Quality measures (defect data) metricas de calidad (datos de defectos)................................................................................. 13
2.3.5 Defect type standard (estandar de tipos de defectos) ............................................................................................................. 13
2.3.6 Schedule measures (métricas de calendario) ......................................................................................................................... 13
2.3.7 Derived measures (métricas derivadas)................................................................................................................................. 14
Knowledge Area 2.4: Data Analysis (análisis de datos)...................................................................................................................... 14
2.4.1 Measurement framework and data analysis (marco de medición y análisis de datos) ............................................................. 14
2.4.2 Postmortem ............................................................................................................................................................................ 14
2.4.3 Performance measures (métricas de desempeño).................................................................................................................. 14
2.4.4 Performance baselines (líneas base de desempeño).............................................................................................................. 14
2.4.5 Combined measures (métricas combinadas) .......................................................................................................................... 14
2.4.6 Analyzing historical data (análisis de datos históricos)............................................................................................................ 14
2.4.7 Analyzing size-estimating accuracy (Análisis de la precisión de la estimación del tamaño)................................................... 14
2.4.8 Analyzing effort-estimating accuracy....................................................................................................................................... 14
2.4.9 Analyzing size and time relationships (análisis entre la relación de tamaño y tiempo)............................................................. 15
2.4.10 Analyzing phase yields (analizando los yields de las fases).................................................................................................. 15
2.4.11 Analyzing defects injected per phase (analizando los defectos inyectados por fase)............................................................. 15
2.4.12 Determining the cost of rework (determinar el costo del re-trabajo)....................................................................................... 15
Knowledge Area 2.5: Process Improvement (mejora de procesos)..................................................................................................... 15
2.5.1 Rationale for process improvement (Justificación de la mejora de procesos).......................................................................... 15
2.5.2 Scope for process improvement (Ámbito de aplicación del proceso de mejora) ..................................................................... 15
2.5.3 Benchmarks for process improvement (Puntos de referencia para la mejora de procesos)..................................................... 15
2.5.4 Set performance improvement goals based on data (establecer las metas de mejora con base en los datos históricos ......... 16
2.5.5 Record process improvement suggestions (registro de PIPs) ................................................................................................. 16
2.5.6 Implement highest payoff improvements first (implementar primero las mejoras de más alto valor) ....................................... 16
2.5.7 Measure process changes (Métricas de Cambios de proceso) ............................................................................................... 16
2.5.8 Monitor performance results (Monitor de resultados de desempeño) ...................................................................................... 16
2.5.9 Watch for improvement opportunities (Estar atento a las oportunidades de mejora) ............................................................... 16
Competency Area 3: Size Measuring and Estimating (Medición del tamaño y estimación) .................................................................... 16
Knowledge Area 3.1: Size Measures (métricas de tamaño) ............................................................................................................... 17
3.1.1 Rationale for using size measures (Justificación para el uso de medidas de tamaño)............................................................. 17
3.1.2 Types of measures (tipos de métricas) ................................................................................................................................... 17
3.1.3 Criteria for size measures (Criterios para las métricas de tamaño) ......................................................................................... 17
3.1.4 Counting standards (estándares de conteo)........................................................................................................................... 17
3.1.5 Physical and logical size (tamaño físico y lógico).................................................................................................................... 17
3.1.6 Size accounting (conteo de tamaño)....................................................................................................................................... 17
3.1.7 Using the size measure selection procedure (Uso del procedimiento de selección de la métrica) .......................................... 17
Knowledge Area 3.2: Size Data (datos de tamaño) ............................................................................................................................ 18
3.2.1 Size data help to make better plans (los datos ayudan a hacer mejores planes)..................................................................... 18
3.2.2 Size data are useful for tracking development effort (los datos de tamaño son útiles para el seguimiento del esfuerzo de
desarrollo)....................................................................................................................................................................................... 18
3.2.3 Size data help in assessing program quality (los datos de tamaño ayudan a evaluar la calidad del programa) ....................... 18
Knowledge Area 3.3: Size Estimating Principles (principios de estimación de tamaño) ...................................................................... 18

4
3.3.1 Estimating is uncertain (la estimación es incierta)................................................................................................................... 18
3.3.2 Estimating is a learning process (la estimación es un proceso de aprendizaje)...................................................................... 18
3.3.3 Estimating is a skill (Estimar es una habilidad)........................................................................................................................ 18
3.3.4 Strive for consistency (Esforzarse por la coherencia).............................................................................................................. 18
3.3.5 Use defined methods for making estimates(Uso de métodos definidos para hacer estimaciones) .......................................... 18
3.3.6 Estimates are subject to error (Las estimaciones están sujetas a error).................................................................................. 18
3.3.7 Estimate in detail (Estimación a detalle).................................................................................................................................. 18
3.3.8 Use historical data to make estimates (utilizar datos históricos para hacer estimaciones)....................................................... 18
Knowledge Area 3.4: Proxies (Sustitutos) .......................................................................................................................................... 18
3.4.1 Using proxies instead of a size measure (Usando proxies en lugar de una métrica de tamaño).............................................. 18
3.4.2 Criteria for choosing a proxy (criterios para elegir un proxy).................................................................................................... 19
3.4.3 Using relative size tables (usando tablas de tamaños relativos).............................................................................................. 19
3.4.4 Building a relative size table (construyendo tablas de tamaños relativos) ............................................................................... 19
3.4.5 Building a relative size table with the sort procedure (construyendo la tabla de tamaños relativos con el procedimiento del
ordenamiento)................................................................................................................................................................................. 19
3.4.6 Building a relative size table with the standard deviation procedure (La construcción de una tabla de tamaño relativo con .... 19
el procedimiento de la desviación estándar)........................................................................................................................................ 19
Knowledge Area 3.5: The PROBE Estimating Method (el método de estimación PROBE)................................................................. 19
3.5.1 What is PROBE? (¿Qué es PROBE?) .................................................................................................................................... 19
3.5.2 Conceptual design (diseño conceptual) .................................................................................................................................. 19
3.5.3 Formulate size estimates for proxies (Formular las estimaciones del tamaño de los proxies) ................................................ 19
3.5.4 Formulate estimates for various types of program elements (Formular las estimaciones para los distintos tipos de elementos de
programa) ....................................................................................................................................................................................... 19
3.5.5 Select the appropriate PROBE method (seleccionar el método PROBE adecuado)............................................................... 20
3.5.6 Estimate program size (Estimar el tamaño del programa)...................................................................................................... 20
3.5.7 Count and calculate actual data for various program elements (Contar y calcular los datos reales para los diferentes .......... 20
elementos del programa) .................................................................................................................................................................... 20
3.5.8 Prediction interval definition (Definición de intervalo de predicción) ........................................................................................ 20
Knowledge Area 3.6: Combining Estimates (La combinación de estimaciones) ................................................................................. 20
3.6.1 Combine independent estimates (combinar estimaciones independientes)............................................................................. 20
3.6.2 Use multiple proxies (utilizar multiples proxies)....................................................................................................................... 21
Knowledge Area 3.7: Size Estimation Guidelines (Guías para la estimación del tamaño)................................................................... 21
3.7.1 Clustered or grouped data (datos amontonados o agrupados)................................................................................................ 21
3.7.2 Extreme data points (Puntos de datos extremos).................................................................................................................... 21
3.7.3 Unprecedented products (Productos sin precedentes)........................................................................................................... 21
3.7.4 Data range (rango de datos).................................................................................................................................................. 21
Competency Area 4: Making and Tracking Project Plans (Construir y dar seguimiento a planes de proyecto)....................................... 21
Knowledge Area 4.1: PSP Planning Principles (principios de planeación).......................................................................................... 21
4.1.1 Plan your work (planea tu trabajo) .......................................................................................................................................... 21
4.1.2 What is a PSP plan? (¿Qué es un plan de PSP?).................................................................................................................. 22
4.1.3 Detailed plans (planes detallados) .......................................................................................................................................... 22
Knowledge Area 4.2: The PSP Planning Framework (El Marco de Planificación de PSP).................................................................. 22
4.2.1 Software product plan components (Componentes del plan de producto de software)............................................................ 22
4.2.2 PSP planning framework (Marco de planificación de PSP) ..................................................................................................... 22
4.2.3 Requirements definition (1Definir los requerimientos) ............................................................................................................. 22
4.2.4 Produce the conceptual design (Generar el diseño conceptual).............................................................................................. 22
4.2.5 Use PROBE for size and resource estimation (Utilizar PROBE para estimar tamaño y recursos) ........................................... 22
4.2.6 Select the appropriate PROBE method for resource estimation (seleccione el método PROBE adecuado para estimación.... 22
de recursos)........................................................................................................................................................................................ 22
4.2.7 To-date time in phase (tiempos a la fecha en las fases).......................................................................................................... 23
4.2.8 To-date percent time in phase (porcentaje de tiempo a la fecha en fase)................................................................................ 23
4.2.9 Distributing time across phases (Distribución de tiempo a través de las fases) ....................................................................... 23
4.2.10 Schedule projection (proyección de calendario)................................................................................................................... 23

5
4.2.11 Product development (desarrollo del producto)..................................................................................................................... 23
4.2.12 Process analysis (analisis de proceso) ................................................................................................................................ 23
4.2.13 Cost performance index (CPI) (índice de desempeño del costo)........................................................................................... 23
Knowledge Area 4.3: Software Size and Effort (tamaño y esfuerzo del software)............................................................................... 23
4.3.1 Size and effort correlation (correlacion de tamaño con esfuerzo)............................................................................................ 23
4.3.2 Productivity (productividad)..................................................................................................................................................... 23
Knowledge Area 4.4: Task and Schedule Planning (planeación de tareas y calendario) .................................................................... 23
4.4.1 Project plan characteristics (Características del plan de proyecto).......................................................................................... 23
4.4.2 Period plans and project plans (Planes del período y planes del proyecto) ............................................................................. 23
4.4.3 Task hours and working hours (Horas de tareas y horas de trabajo)....................................................................................... 23
4.4.4 Milestones (hitos).................................................................................................................................................................... 23
4.4.5 Schedule plan requirements (requerimientos del calendario planeado)................................................................................... 23
4.4.6 Task order (orden de las tareas)............................................................................................................................................. 24
4.4.7 Estimated task time (tiempo estimado de las tareas) .............................................................................................................. 24
4.4.8 PSP schedule plans (planes de calendario PSP).................................................................................................................... 24
4.4.9 PSP task plans (planes de tareas PSP).................................................................................................................................. 24
Knowledge Area 4.5: Schedule Tracking with Earned Value (seguimiento al calendario con valor ganado ) ...................................... 24
4.5.1 Planned value (PV) (valor planeado) ...................................................................................................................................... 24
4.5.2 Earned value (EV) (valor ganado)........................................................................................................................................... 24
4.5.3 Using EV measures (usando métricas de valor ganado)......................................................................................................... 24
4.5.4 EV as a measure of actual progress relative to planned progress (EV como una forma de medir el progreso real en relación con
el avance planeado)........................................................................................................................................................................ 24
4.5.5 Project tracking with EV (Seguimiento del proyecto con EV)................................................................................................... 24
4.5.6 Calculating PV for each task (calculando el valor planeado para cada tarea).......................................................................... 25
4.5.7 Calculating PV for each time period (calculando el PV para cada periodo de tiempo)............................................................. 25
4.5.8 Calculating cumulative PV for a given time period (Cálculo del PV acumulado para un período de tiempo determinado) ....... 25
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) .......... 25
4.5.10 Estimating the project completion date (Estimación de la fecha de terminación del proyecto)............................................... 25
Knowledge Area 4.6: Planning and Tracking Issues (Planeacion y seguimiento de Issues) ............................................................... 25
4.6.1 Informing management of issues (Informar a la gerencia sobre los asuntos) .......................................................................... 25
4.6.2 When to adjust a plan (cuando ajustar un plan) ...................................................................................................................... 25
4.6.3 Handling part-time assignments (manejando asignaciones de tiempo parcial)...................................................................... 25
Competency Area 5: Planning and Tracking Software Quality (planeación y seguimiento a la calidad del software).............................. 25
Knowledge Area 5.1: PSP Quality Principles (principios de calidad)................................................................................................... 25
5.1.1 Personal responsibility (responsabilidad personal).................................................................................................................. 26
5.1.2 The economics of quality (la economía de la calidad) ............................................................................................................. 26
5.1.3 Product quality (La calidad del producto) ................................................................................................................................ 26
5.1.4 Process quality (calidad del proceso)...................................................................................................................................... 26
Knowledge Area 5.2: Quality Measures (métricas de calidad)............................................................................................................ 26
5.2.1 Personal defect data (datos personales de defectos).............................................................................................................. 26
5.2.2 To-date defects injected and removed (defectos insertados y removidos a la fecha) .............................................................. 26
5.2.3 To-date percent defects injected and to-date percent defects removed (porcentaje de defectos inyectados a la fecha y porcentaje
de defectos removidos a la fecha)................................................................................................................................................... 26
5.2.4 Yield (rendimiento).................................................................................................................................................................. 26
5.2.5 Phase Yield (yield (rendimiento) de fase)................................................................................................................................ 26
5.2.6 Process Yield (yield (rendimiento) del proceso) ..................................................................................................................... 26
5.2.7 Review Yield (yield (rendimiento) de revisión)......................................................................................................................... 26
5.2.8 Percent appraisal cost of quality (COQ) (Porcentaje de costo de evaluación de la calidad COQ) ........................................... 27
5.2.9 Percent failure COQ (Porcentaje de fallas COQ) .................................................................................................................. 27
5.2.10 Cost of Quality (COQ) (Costo de la Calidad)........................................................................................................................ 27
5.2.11 COQ appraisal to failure ratio (COQ A/FR) (COQ relación de evaluación / fallas) ................................................................. 27
5.2.12 Defect Density (densidad de defectos).................................................................................................................................. 27
5.2.13 Process Quality Index (PQI) (índice de calidad del proceso)................................................................................................ 27

6
5.2.14 Calculating values for the PQI components (Cálculo de los valores de los componentes PQI) ............................................. 27
5.2.15 Composite PQI (PQI Compuesto)......................................................................................................................................... 27
5.2.16 Phase defect removal rate (tasa de eliminacion de defectos de fase) ................................................................................... 28
5.2.17 Review Rate (tasa de revisión) ............................................................................................................................................. 28
5.2.18 Defect-removal leverage (DLR) (Apalancamiento de eliminación de defectos).................................................................... 28
Knowledge Area 5.3: Quality Methods (Métodos de Calidad).............................................................................................................. 28
5.3.1 Personal reviews (revisiones personales)............................................................................................................................... 28
5.3.2 Personal review principles (principios de revisión personal).................................................................................................... 28
5.3.3 Inspections (inspecciones)...................................................................................................................................................... 28
5.3.4 Walkthroughs (recorridos)....................................................................................................................................................... 28
5.3.5 Relationship between reviews and inspections (relación entre las revisiones y las inspecciones)........................................... 28
5.3.6 Conducting effective personal reviews (conducir revisiones personales efectivas).................................................................. 28
Knowledge Area 5.4: PSP Code Reviews (revisiones de código en PSP).......................................................................................... 29
5.4.1 Code review checklist (checklist de revisión de código) .......................................................................................................... 29
5.4.3 Code review strategy (estrategia de revisión de código) ........................................................................................................ 29
5.4.4 Review against a coding standard (revisión contra un estándar de codificación)..................................................................... 29
Knowledge Area 5.5: PSP Design Reviews (revisiónes de diseño PSP) ............................................................................................. 29
5.5.1 Design review principles (principios de revisión de diseño).................................................................................................... 29
5.5.2 Design review checklist (checklist de revisión de diseño)........................................................................................................ 29
5.5.3 PSP design reviews (revisions de diseño en PSP)................................................................................................................. 29
5.5.4 Design review strategy (estrategia de revisión de diseño)....................................................................................................... 29
Knowledge Area 5.6: Review Issues (aspectos de la revision) ........................................................................................................... 29
5.6.1 Review efficiency (eficiencia en la revisión) ............................................................................................................................ 30
5.6.2 Reviewing before or after compiling (Revisar antes o después de compilar)........................................................................... 30
5.6.3 Review objectives (objetivos de la revisión) ............................................................................................................................ 30
Competency Area 6: Software Design (Diseño de Software) ................................................................................................................. 30
Knowledge Area 6.1: Software Design Principles (Principios de diseño de Software) ........................................................................ 30
6.1.1 Definition of software design (Definición de Diseño de Software)............................................................................................ 30
6.1.2 The design process (El proceso de diseño) ............................................................................................................................ 30
6.1.3 The role of design in the overall software development process (El role del diseño dentro del proceso general de desarrollo de
Software)......................................................................................................................................................................................... 30
6.1.4 The “requirements uncertainty principle” (El “principio de incertidumbre del diseño”) .............................................................. 30
6.1.5 The role of design in PSP (El rol de diseño en PSP)............................................................................................................... 30
6.1.6 Design methodology in PSP (Metodología de Diseño en PSP)............................................................................................... 31
6.1.7 Design specification structure (Estructura de la epecificación de diseño)............................................................................... 31
6.1.8 Need for design precision (Necesidad de la precisión en el diseño)........................................................................................ 31
Knowledge Area 6.2: Design Strategies (Estrategias de Diseño) ....................................................................................................... 31
6.2.1 The need for design strategies (La necesidad de estrategias de diseño) ................................................................................ 31
6.2.2 Nature of the design process (Naturaleza del proceso de diseño)........................................................................................... 31
6.2.3 Design process guidelines (Guías del proceso de diseño) ..................................................................................................... 31
6.2.4 Types of design strategies (Tipos de estrategias de diseño)................................................................................................... 31
Knowledge Area 6.3: Design Quality (Calidad en el Diseño) .............................................................................................................. 31
6.3.1 Design precision (Precisión del Diseño)................................................................................................................................. 31
6.3.2 Design completeness (Completitud del Diseño)...................................................................................................................... 31
6.3.3 Design usability (Usabilidad del diseño)................................................................................................................................. 32
Knowledge Area 6.4: Design Documentation (Documentación del Diseño)........................................................................................ 32
6.4.1 The need for software design documentation (La necesidad de documentar el diseño) .......................................................... 32
6.4.2 Overall design documentation concerns (Preocupaciones generales sobre la documentación del diseño) ............................. 32
6.4.3 Common types of design documentation (Tipos comunes de documentación del diseño) ...................................................... 32
6.4.4 Design visibility (Visibilidad del diseño)................................................................................................................................... 32
6.4.5 Design documentation practice (Practica de documentación del diseño) ................................................................................ 32
Knowledge Area 6.5: Design Templates (Plantillas de Diseño) .......................................................................................................... 32
6.5.1 Design notation (Notación de diseño) ..................................................................................................................................... 32

7
6.5.2 PSP design templates (Pantillas de diseño)............................................................................................................................ 32
6.5.3 Operational specification template (OST) (Plantilla de especificación operacional - OST)...................................................... 33
6.5.4 Functional specification template (FST) (Plantilla de especificación funcional - FST).............................................................. 33
6.5.5 State specification template (SST) (Plantilla de especificación de estados SST) .................................................................... 33
6.5.6 Logic specification template (LST) (Plantilla de especificación lógica - LST)........................................................................... 33
6.5.7 Template usage (Uso de la plantillas) ..................................................................................................................................... 33
Knowledge Area 6.6: Design Verification (Verificación del Diseño) .................................................................................................... 33
6.6.1 Design standards (Estándares de diseño) .............................................................................................................................. 33
6.6.2 Verification methods (Métodos de verificación)....................................................................................................................... 33
6.6.3 Choosing the appropriate design verification method (Selección del método de verificación adecuado) ................................. 34
6.6.4 Using execution table verification (Uso de verificación con la tabla de ejecución) ................................................................... 34
6.6.5 Using trace-table verification (Uso de verificación con la tabla de rastreo) .............................................................................. 34
6.6.6 Execution table verification vs. trace-table verification (Verificación con tabla de ejecución vs. Verificación con tabla de rastreo)
........................................................................................................................................................................................................ 34
6.6.7 Using state-machine verification (Uso de la verificación de la máquina de estados) ............................................................... 34
6.6.8 Using loop verification (Uso de la verificación de ciclos) ......................................................................................................... 34
Competency Area 7: Process Extensions and Customization (Extensión y adaptación del proceso) ..................................................... 34
Knowledge Area 7.1: Defining a Customized Personal Process (Definiendo un proceso personal adaptado)..................................... 34
7.1.1 When to define a new or customized process (Cuando definer un proceso nuevo o adaptado) .............................................. 34
7.1.2 How to define a new or customized process (Como definir un proceso nuevo o adaptado) .................................................... 35
7.1.3 Using information mapping for documenting a new or customized process (Usando el mapero de la información para documentar
un proceso nuevo o adatpar un proceso) ........................................................................................................................................ 35
Knowledge Area 7.2: Process Evolution (Evolución del Proceso)....................................................................................................... 35
7.2.1 Initial process definition (Definición Inicial del proceso)........................................................................................................... 35
7.2.2 Refining a personal process (Refinando un proceso personal) ............................................................................................... 35
Knowledge Area 7.3: Professional Responsibility (Responsabilidad profesional) ............................................................................... 35
7.3.1 Use effective methods in your work (Uso de métodos efectivos en el trabajo) ........................................................................ 35
7.3.2 Use data to discover your strengths and weaknesses (Uso de datos para descubrir sus debilidades y fortalezas) ................. 35
7.3.3 Practice (Práctica) .................................................................................................................................................................. 35
7.3.4 Learn from others, and pass on what you know (Aprenda de otros y enseñe lo que sabe) ..................................................... 36
7.3.5 Find and learn new methods (Encuentre y aprenda nuevos métodos) .................................................................................... 36

8
Competency Area 1: Foundational Knowledge (Fundamentos del Conocimiento)
El área de competencia de Fundamentos del Conocimiento bosqueja las principales definiciones y habilidades en métodos estadísticos
que constituyen los conceptos fundamentales sobre los que se creó el PSP. Las áreas de conocimiento principales que componen esta
área de competencia son los siguientes:
1.1 Process Definition (Definición del Proceso) – Esta área de conocimiento esboza los conceptos fundamentales y las habilidades
que permiten a los profesionales de la ingeniería de software crear, usar, y ajustar los procesos definidos que componen el PSP.
1.2 Process Elements (Elementos del Proceso) – Esta área de conocimiento delinea los componentes que se incluyen en cualquier
proceso personal y constituyen un marco para organizar el trabajo en un proyecto.
1.3 Measurement Principles (Principios de Medición) – Esta área de conocimiento describe las métricas del proceso y del producto y
explica por qué es importante medir para producir un trabajo de alta calidad.
1.4 Statistical Elements (Elementos de Estadística) – Esta área de conocimiento analiza las estadísticas que proveen una base para
la planificación y el seguimiento de las metodologías utilizadas en el PSP, y que también proporcionan un medio objetivo de analizar y
mejorar los procesos personales.
Knowledge Area 1.1: Process Definition (Definición del Proceso)
El PSP es una serie de procesos definidos que permiten a los profesionales de ingeniería (como los desarrolladores de software) construir
productos de alta calidad a tiempo y dentro del presupuesto. Esta área de conocimiento esboza los conceptos y las habilidades necesarias
para crear, ajustar, y usar los procesos definidos.
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 específico. Los procesos se definen
habitualmente para los trabajos que se realizan en varias ocasiones y que hay que hacer de la misma manera cada vez que se realizan.
1.1.3 Benefits of defining a process (Beneficios de definir un proceso)
Un proceso definido proporciona:
• un marco claramente delineado para la planificación, seguimiento y gestión del trabajo
• una guía para hacer el trabajo correcta y completamente, con los pasos en el orden apropiado.
• una base objetiva para medir el trabajo y dar seguimiento al progreso en la consecución de metas, y para refinar el proceso en
futuras versiones
• Una herramienta para la planificación y la gestión de la calidad de los productos
• Procedimientos acordados y entendidos por los miembros del equipo para usarlos para coordinar su trabajo y con ellos construir
un producto común.
• un mecanismo que permite a los miembros del equipo apoyarse mutuamente en el transcurso del proyecto
1.1.4 Process documentation (Documentación del proceso)
Documentar un proceso es el acto de producir una representación escrita y concreta de un proceso, los criterios de entrada y salida, las
fases del proceso, y los pasos del proceso para cada fase. La documentación del proceso no debe contener tutoriales u otros materiales
explicativos generalmente requeridos por personas no calificadas o desinformadas, sino que sólo debería facilitar la información
necesaria que requieren profesionales experimentados, 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 una instanciación específica del proceso, tales como los recursos necesarios, los roles
de los diversos miembros del proyecto, calendarios, presupuesto, metas y objetivos, los compromisos y los riesgos identificados.
1.1.6 Personal processes (proceso personal)
Un proceso 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 personal. 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 (Patrón de procesos y procesos operativos)
Un Patrón de procesos (enactable process) define con precisión como hacer un proceso e incluye todos los elementos necesarios para
usar un proceso. Un Patrón de procesos (enactable process) consiste en una definición del proceso, los insumos que requiere, los
agentes asignados, los recursos (por ejemplo, las personas, equipos, tiempo, dinero), y los criterios de salida. Un proceso operativo
define con precisión lo que se debe hacer mediante una lista de tareas necesarias, con el detalle suficiente para guiar a un profesional
con conocimiento para hacer la tarea. Los procesos operativos proporcionan una guía con suficiente detalle para que los equipos y los
individuos puedan hacer planes detallados para realizar un proyecto y luego usar el proceso para guiar y dar seguimiento a su trabajo.
El PSP es un ejemplo de un patrón de proceso operativo.
1.1.8 Process phases (Fases del proceso)
Un proceso definido, consta de una serie de pasos, elementos o actividades que comúnmente se llaman fases. Las fases de un proceso
simple consisten en pasos sin mayor sub-estructura. Los procesos más complejos pueden tener fases que son así mismo procesos.
Los pasos o actividades en cada fase se definen por un script (ver 1.2.2). Como mínimo, cualquier proceso debe tener tres fases:
planificación, desarrollo, y postmortem.
1.1.9 The PSP process phases (las fases del proceso PSP)
El proceso básico PSP tiene tres fases.

9
1. Planificación: Elaborar un plan para hacer el trabajo.
2. Desarrollo: Realizar el trabajo.
a. definir los requerimientos (ver 4.2.2)
b. diseñar el programa
c. revisar el diseño y corregir todos los defectos
d. codificar el programa
e. revisar el código y corregir todos los defectos
f. construir o compilar y corregir todos los defectos
g. probar el programa y corregir todos los defectos
3. Postmortem: Comparar los resultados reales con el plan, registrar los datos históricos del proceso, elaborar un informe
resumen, 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 una parte de una fase de desarrollo PSP, dependiendo de las necesidades particulares.
• Varios procesos de desarrollo incremental PSP están disponibles [Humphrey 05a].
• Con desarrollos incrementales a gran escala, los métodos de PSP se usan más eficazmente cuando cada incremento es de
alta calidad.
1.1.11 Process tailoring (adaptación de procesos)
La adaptación de procesos es el acto de personalizar la definición de un proceso para soportar la adaptación de ese proceso para un
propósito particular (ver 7.1).
1.1.12 Process building and refining (definición y refinamiento de procesos)
Los profesionales calificados en PSP pueden utilizar o adaptar los scripts de PSP para definir o personalizar sus propios procesos
personales de alta calidad, para la construcción de un producto. Los profesionales deben definir sus propios procesos para garantizar
que los procesos se ajusten a sus necesidades lo más posible [Humphrey 95, p. 16]. Como el proceso está definido para diversos
proyectos, los usuarios del proceso deben procurar el perfeccionamiento y la mejora continua tanto en el proceso mismo como en la
calidad de los productos construidos con ese proceso.
Knowledge Area 1.2: Process Elements (Elementos del Proceso)
Esta área de conocimiento describe los componentes que se incluyen en cualquier proceso personal y define un marco para organizar el
trabajo del proyecto.
1.2.1 Process elements (Elementos del Proceso)
Los elementos del proceso son los componentes de un proceso. El PSP contiene cuatro elementos básicos: guiones (scripts), formas
(formatos), métricas y estándares.
1.2.2 Guiones (Scripts)
Los guiones (Scripts) son descripciones a nivel experto que guían el uso de un proceso. Contienen referencias a las formas, estándares,
Listas de verificación (checklists), sub-guiones (sub-scripts), y métricas pertinentes. Un guion (script) puede estar definido a alto nivel
para todo un proceso o en un nivel más detallado para una fase en particular de un proceso. Un guion (script) de proceso documenta
• el propósito u objetivo del proceso
• los criterios de entrada
• directrices generales, consideraciones de uso, o restricciones
• fases o etapas que deben realizarse
• métricas del proceso y criterios de calidad
• condiciones de salida (como productos de trabajo definidos o datos requeridos del proceso)
1.2.3 Forms (formas, formatos)
Las formas proporcionan un marco adecuado y coherente para la recolección y registro de datos, especifican los datos requeridos y
donde registrarlos. Según corresponda, las formas también definen los cálculos necesarios y la definición de datos. Se pueden utilizar
formas en papel si no se tienen herramientas automatizadas, fácilmente accesibles, para la recopilación y el registro.
En PSP, los checklist (listas de verificación) son formas especiales usadas para guiar las revisiones personales. Cada elemento del
checklist verifica aspectos relacionados con que el producto este correcto o la conformidad con las normas o especificaciones. Los puntos
del checklist incluyen los defectos que más comúnmente ocurren y que se pueden encontrar con una revisión. Todo el producto es
revisado enfocándose en un solo punto del checklist a la vez. Conforme se revisa cada punto, ese punto se va marcando como
completado. Cuando el checklist entero se ha completado, sirve como un registro de la revisión.
1.2.4 Measures (métricas)
Las métricas cuantifican el proceso y el producto, la métricas proporcionan datos de cómo está funcionando el proceso permitiéndole a
los usuarios
• desarrollar perfiles de datos de proyectos anteriores que puedan ser usados para la planeación y mejora de procesos
• analizar un proceso para determinar la manera de mejorarlo
• determinar la eficacia de las modificaciones al proceso
• supervisar la ejecución de sus procesos y tomar decisiones con respecto a los siguientes pasos
• supervisar la capacidad para cumplir los compromisos y tomar acciones correctivas cuando sea necesario
1.2.5 Standards (estándares)
Los estándares proporcionan definiciones precisas y consistentes que guían el trabajo y la recopilación y uso de datos. Los estándares
(como el de codificación, conteo de líneas, y tipos de defectos) permiten que las métricas se apliquen uniformemente en diversos
proyectos y que se usen de manera consistente. Los profesionales de PSP deberían ser capaces de reconocer las áreas donde los
estándares podrían ser útiles y elaborarlos cuando sea necesario.
Knowledge Area 1.3: Measurement Principles (Principios de medición)
Esta área de conocimiento describe la medición del proceso y del producto, y explica por qué las métricas son esenciales para producir
trabajo de alta calidad.

10
1.3.1 The need for measures (la necesidad de usar métricas)
Las métricas se utilizan en PSP de manera que los cambios al proceso pueden ser identificados, evaluados, lógicamente implementados,
y jugados como efectivos o inefectivos.
1.3.2 Measurement types (tipos de métricas)
Para que sean útiles para la gestión de procesos, toda métrica debe ser definida, precisa, exacta, y significativa. Hay dos tipos principales
de métricas utilizadas en PSP: métricas de producto (artefacto) y del proceso.
• Las métricas de producto se utilizan para cuantificar las características del producto, tales como el tamaño del producto o los
defectos encontrados por elemento
• Las métricas del proceso describen o cuantifican el proceso de desarrollo o de corrección utilizado, y se clasifican como
métricas históricas o actuales.
o Las Métricas históricas del proceso se utilizan después de que el proceso se ha realizado para registrar los datos
reales, tales como el tiempo de inspección, el tiempo de pruebas, etc.
o Las métricas actuales del proceso se utilizan mientras el proceso se está ejecutando para registrar datos como la
duración de las reuniones de inspección, el tiempo de revisión de código como porcentaje del tiempo total de
codificación, y similares.
Tanto las métricas de producto (artefacto) como las de proceso pueden basarse en métricas individuales o múltiples. La elección de
métricas individuales o múltiples depende de la naturaleza de los datos y el uso que se le dará a cada una. Cuando se toman métricas
múltiples, es necesario un procedimiento estadísticamente sensato para calcular los valores a ser utilizados a partir de estas métricas.
1.3.3 Defined measures (métricas definidas)
Una métrica definida es aquella que tiene un significado explícito e inequívoco. Para las métricas de proceso, se requiere que el proceso
esté definido con precisión para incluir criterios de entrada y salida para todas las fases. Las propiedades que se miden en un proceso
también deben estar completa y explícitamente definidas.
1.3.4 Precise and accurate measures (Métricas precisas y exactas)
Una métrica precisa es la que especifica un valor a un nivel adecuado de precisión, como con un número determinado de dígitos después
del punto decimal. Una métrica exacta es la que mide correctamente la propiedad que se pretende medir. Las métricas pueden ser
precisas y exactas, precisas pero inexactas, imprecisas pero exactas, o imprecisas e inexactas. En gestión de procesos, las métricas
deben ser tan precisas y exactas como sea posible.
1.3.5 Meaningful measures (Métricas significativas)
Para ser significativa, las métricas deben representar realmente el verdadero valor de la propiedad del producto o proceso que se está
midiendo, lo que indica que la métrica representa una característica objetiva de un fenómeno real. La significancia de la métrica aumenta
con el número y consistencia de las métricas que se van tomando.
1.3.6 Uses of process measures (usos de las métricas de proceso)
Las métricas de proceso pueden ser utilizadas para evaluar las características del producto o proceso, para estimar elementos del
producto o del proceso, o para predecir los resultados futuros. También pueden ser utilizadas como base para determinar las
oportunidades de mejora y sus probables objetivos individuales y de negocio.
Knowledge Area 1.4: Statistical Elements (Elementos de Estadística)
La estadística es el fundamento para la planeación y las metodologías de seguimiento en PSP, además proporcionan un medio objetivo
de analizar y mejorar los procesos personales. (Nota: Las definiciones específicas, interpretaciones o aplicaciones de términos
estadísticos que hace PSP se mencionan en cada subsección del área de conocimiento aplicable.)
1.4.1 Distributions (distribución)
Una distribución es un conjunto de valores numéricos que son generadas por un proceso común (tamaños reales de las partes
desarrolladas o estimaciones del tamaño de las partes).
1.4.2 Mean (Media)
La media es el valor promedio aritmético de una distribución. En PSP, la media es normalmente una estimación de la media de la
distribución, no es la media real.
1.4.3 Variance (Varianza)
La varianza es una medida de la difusión o estrechez de una distribución alrededor de la media. En PSP, la varianza es normalmente
una estimación de la varianza de la distribución, en lugar de la varianza real.
1.4.4 Standard deviation (Desviación estándar)
La desviación estándar es la raíz cuadrada de la varianza. A menudo se utiliza para caracterizar el rango esperado de la desviación entre
una estimación y un valor real. Por ejemplo, un método en PSP utiliza la desviación estándar para clasificar el tamaño de software en
tablas de tamaño relativo. La desviación estándar también se utiliza como parte del cálculo de los intervalos de predicción.
1.4.5 Correlation (correlación)
La correlación mide como dos conjuntos de datos están relacionados. En PSP la correlación es medida entre el tamaño estimado y real,
y entre el esfuerzo estimado y el real.
1.4.6 Significance of a correlation (Significancia de una correlación)
La significancia mide la probabilidad de que dos conjuntos de datos tengan un alto grado de correlación por casualidad. Las estimaciones
de tamaño y esfuerzo en PSP son más confiables cuando se basan en datos históricos que tienen un alto grado de correlación que es
significativo.
1.4.7 Linear regression (Regresion Lineal)
La regresión lineal determina la línea a través de los datos que minimiza la varianza de los datos con respecto a dicha línea. Por ejemplo,
cuando el tamaño y el esfuerzo se relacionan linealmente, la regresión lineal puede utilizarse para obtener estimaciones de esfuerzo a
partir de las estimaciones de tamaño.

11
1.4.8 Prediction interval (Intervalo de predicción)
El intervalo de predicción provee el rango alrededor de una estimación hecha mediante regresión lineal en el que el valor real caerá con
una cierta probabilidad. Por ejemplo, en PSP, el 70% de intervalo de predicción de una estimación de tamaño o de tiempo implica un
0.7 de probabilidad de que el valor real de tamaño o tiempo estará dentro del rango definido por el intervalo de predicción.
1.4.9 Multiple regression (regression multiple)
La regresión múltiple se utiliza en PSP cuando las estimaciones de tamaño o tiempo dependen de más de una variable. Por ejemplo, si
las modificaciones de los programas requieren mucho más tiempo que las adiciones, entonces añadir y modificar se pueden separar en
dos variables para el cálculo de regresión.
1.4.10 Standard normal distribution (distribución normal estándar)
La distribución normal estándar es una distribución normal que se ha convertido a una media de cero y una desviación estándar de uno
La distribución normal estándar se usa en PSP al construir una tabla de estimación de tamaño.
1.4.11 Log-normal distribution (Distribución logarítmica normal)
Muchas de las operaciones estadísticas asumen que los valores de los datos se distribuyen normalmente, pero algunas métricas de PSP
no cumplen con este requisito. Por ejemplo, los valores de tamaño no pueden ser negativos, pero pueden tener valores pequeños que
están cerca de cero. Estas distribuciones también suelen tener probabilidades más altas de tener valores grandes que una distribución
normal. Cuando una transformación logarítmica se aplica a un conjunto de datos de este tipo, la distribución resultante puede tener una
distribución normal y por tanto ser adecuada para los análisis estadísticos de datos que asumen una distribución normal. Los parámetros
estadísticos de la distribución normal se pueden calcular y luego transformarse de nuevo a la distribución original. Los datos de tamaño
en PSP generalmente tienen una distribución logarítmica normal, por lo que deben transformarse en una distribución normal para la
construcción de una tabla de estimación de tamaño.
1.4.12 Degrees of freedom (Grados de libertad)
Los grados de libertad (df) miden el número de puntos de datos (n), en comparación con el número de parámetros (p) que se utilizan
para representarlos. En la regresión lineal, dos parámetros (ß0 y ß1) describen la línea que se utiliza para aproximar los datos. Dado al
menos dos puntos son necesarios para determinar una línea, el número de grados de libertad es n-2. En general, el número de grados
de libertad es n-p.
1.4.13 The t-distribution (la distribución T)
La distribución t permite la estimación de la varianza de una distribución normal cuando los verdaderos parámetros no son conocidos,
permitiendo así el cálculo de los parámetros estadísticos basados en estimaciones de datos de una muestra. Como la distribución normal,
la distribución-t tiene forma de campana, pero varía dependiendo del número de puntos en la muestra. Para menos puntos de datos, la
distribución es corta con cabos gruesos. Conforme aumenta el número de puntos de datos, la distribución se hace más alta, con pequeños
cabos y se aproxima a la distribución normal. En PSP, la distribución t es importante porque ayuda a determinar la significancia de una
correlación y el intervalo de predicción para la regresión, cada una de las cuales depende del número de puntos en el conjunto de datos
de la muestra.
Competency Area 2: Basic PSP Concepts
La segunda área de conocimiento, presenta los conceptos básicos de mejora de procesos y habilidades en las cuales PSP está
fundamentado. Las áreas de conocimiento principales que componen esta área de competencia son las siguientes:
2.1 Process Fidelity (Adherencia al proceso) - Esta área de conocimiento introduce el concepto de adherencia al proceso y aborda el
efecto de la misma respecto a la calidad del proceso.
2.2 Data colecction (Recolección de Datos) - Esta área de conocimiento aborda habilidades y conceptos relativos a la recolección y
utilización de datos del proceso.
2.4 Data Analysis (Análisis de Datos) - Esta área de conocimiento describen los conocimientos y aptitudes necesarios de los
profesionales PSP para analizar los datos que se recolectan 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 disciplina de proceso o cumplimiento del proceso) es el grado en que los individuos siguen
su propio proceso personal definido. El objetivo de la adherencia al proceso es mejorar el desempeño del trabajo y construir productos
de mayor calidad. A menos que el proceso sea cumplido fielmente, la mejora del proceso no será posible.
2.1.2 Process fidelity and useful data (Adherencia al proceso y datos útiles)
Con el fin de tener datos significativos para implementar y mejorar 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 creación y el uso consistente de un proceso de alta calidad se
traducirán en la construcción de productos de alta calidad. La calidad del producto, a su vez, tiene un efecto directo sobre la capacidad
de los individuos para cumplir el calendario y los objetivos presupuestarios del producto.

12
2.1.4 Process fidelity and planning (Adherencia al proceso y planeación)
Cuando un proyecto está planeado conforme a procesos eficaces y eficientes y se hacen estimaciones basadas en datos sólidos, el
compromiso de entrega resultante probablemente será exacto. Cuando los proyectos se realizan de acuerdo a los detalles de un plan
preciso, se entrega consistentemente 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. Si el proceso definido no es seguido, el plan no reflejara lo que se está
haciendo y se vuelve imposible dar seguimiento de forma exacta al avance con respecto al plan. El seguimiento preciso del proyecto
requiere datos exactos.
2.1.5 Process fidelity and performance improvement (Adherencia al proceso y mejora del desempeño)
Un proceso bien definido y medido que se sigue fielmente permite a las personas seleccionar los métodos que mejor se adaptan a sus
habilidades particulares y apoya las tareas que se deben realizar. Las personas deben utilizar procesos personales bien definidos y
medidos con el fin de mejorar consistentemente su desempeño.
Knowledge Area 2.2: Data Collection (Recolección de datos)
Esta área de conocimiento aborda las habilidades y conceptos relativos a la recolección y utilización de datos del proceso.
2.2.1 Collecting data (recopilación 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 cómo
trabajan y exactamente que hacen. Los datos deben utilizarse para identificar las áreas de mejora y para proporcionar una base para
medir los efectos de los cambios hechos al proceso. Entre los beneficios de la recolección y análisis de los datos se incluye:
• el establecimiento de estándares para productos y procesos
• determinar si un determinado producto o proceso cumple con los criterios definidos
• controlar de manera precisa el trabajo de los individuos
• generar indicadores de desempeño de los individuos
• mejorar el rendimiento personal
• gestionar la calidad de los productos producidos
• estimar cuando se terminará el trabajo
• planear, dar seguimiento y reportar de forma precisa el trabajo
2.2.2 Collecting useful data (Recolección de datos útiles)
Para ser más útiles, los datos deben ser recolectados de acuerdo a las siguientes directrices:
• El proceso de recolección de datos debe tener objetivos y planes específicos.
• Los datos reales deben ser seleccionados por su relevancia en la aplicación de un modelo o prueba de una hipótesis.
• Los datos deben ser recolectados por aquellas personas que realmente los van a utilizar, y deben entender la importancia y
tener el cuidado de recolectar información precisa y relevante.
• El proceso de recolección de datos debe incluir consideraciones sobre el impacto que tiene la recolección de datos en la
organización y su gente.
• El plan de recolección de datos debe contar con el apoyo de la gerencia, la propia gerencia debe considerar la recolección de
datos como una inversión con alto retorno, en términos de poder ser capaces de predecir con precisión los costos y calendario
de desarrollo de productos, así como proporcionar una base para mejorar la eficiencia de la organización y la calidad de sus
productos.
2.2.3 Collecting high-quality data (recopilación de datos de alta calidad)
Los datos de software son altamente propensos a errores. La mejor manera de garantizar que los datos son de alta calidad es capacitar
a los individuos en métodos adecuados para tomar métricas del proceso y registrar los datos que recolecten. El uso de herramientas
automatizadas para la recolección de datos, cuando hay herramientas adecuadas disponibles, puede ayudar a mejorar la calidad de los
datos ofreciendo a las personas un medio conveniente para la captura de información de los procesos inmediatamente después de que
esta se genera.
2.2.4 Ensuring data quality (Garantizar la calidad de los datos)
La mejor manera de asegurarse de que se recolectan datos de alta calidad es hacer que los individuos recolecten su propia información
en tiempo real (o lo más pronto posible después de que se generan los datos). Sin embargo, los individuos deben estar seguros que los
datos de su proceso personal no serán utilizados para evaluar su desempeño, si la gente teme que sus datos sean utilizados para
calificarla o para castigarla, no recolectaran datos exactos, si es que recolectan alguno.
2.2.5 Using data for planning purposes (Usar los datos para fines de planificación)
Los datos de alta calidad son útiles para hacer planes personales precisos, sin embargo, cualquier conjunto de datos (independientemente
de la calidad) es mejor que no tener datos. Siempre que sea posible, cada producto, trabajo, o proyecto debe ser planeado con
estimaciones que se basen en datos históricos semejantes (véase el punto 2.3 para los tipos de mediciones de datos que normalmente
se utilizan para las estimaciones).
• Las mejores estimaciones se basan en datos reales de uno o más productos, trabajos o proyectos de la misma naturaleza
previamente realizados.
• Cuanto más similares sean los esfuerzos previamente realizados al que se está planeando, más probable será que se llegue
a una estimación exacta.
• Entre más datos históricos se utilicen al hacer una estimación, es mayor la probabilidad que la estimación sea exacta.

13
• La estimación de un trabajo grande o un proyecto completo como un compuesto de varios productos de trabajo o sub-proyectos
compuestos es más precisa que la estimación del proyecto como una gran unidad única.
Knowledge Area 2.3: Data Measures
En esta área de conocimiento se describen las cuatro métricas básicas de PSP.
2.3.1 Basic PSP measures (Métricas Básicas de PSP)
Las métricas básicas de PSP son tiempo, tamaño, 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 después tienen mayor
probabilidad de ser inexactos. Los componentes básicos son start date (fecha de inicio), start time (tiempo de inicio), end date (fecha
de finalización), end time (tiempo de finalización), interrupt time (tiempo de interrupción), off-task time (tiempo fuera de tareas),
and delta time (tiempo delta). El time in phase (tiempo de fase) es el tiempo planeado o real invertido en una fase particular del
proceso.
• El interrupt time (tiempo de interrupción) no se incluye en la medición del tiempo para una tarea o fase del proceso. Si hay
una interrupción durante el trabajo, ese tiempo se resta de la medición del tiempo.
• El off-task time (tiempo fuera de tareas) es el tiempo haciendo otras cosas diferentes a las tareas planeadas del proyecto,
por lo general no es medido ni se le da seguimiento, ya que no contribuye a alcanzar el objetivo de calendario establecido. El
off-task time (tiempo fuera de tareas) incluye el tiempo dedicado a la gestión y en reuniones administrativas, asistir a cursos
de formación, lectura de correo electrónico, o cualquier otras de las actividades esenciales que un miembro del equipo debe
hacer. El off-task time (tiempo fuera de tareas) para una tarea determinada o período de trabajo se calcula restando el delta
time (tiempo delta) total, del tiempo total transcurrido dedicado a una tarea.
• Delta time (tiempo delta) es el tiempo que tomó completar una tarea o fase del proceso. Se calcula como el tiempo final (end
time) menos el tiempo de inicio (start time), menos el tiempo de interrupción (interrupt time).
Los registros de tiempo son más exactos cuando se recolectan con una herramienta automatizada, la herramienta debe ser capaz de
registrar el tiempo de inicio y finalización así como las fechas, calcular el tiempo transcurrido, y restar el tiempo de interrupción al tiempo
transcurrido para calcular el delta time (tiempo delta). Cada entrada en el registro de tiempos debe también incluir los nombres de la fase
o paso del proceso, el producto y el elemento que se está trabajando, la tarea del proyecto que se está realizando y la persona que está
haciendo el trabajo.
2.3.3 Size measures (métricas de tamaño)
Una métrica de tamaño se utiliza para medir qué tan grande es un producto de trabajo. Las métricas de tamaño se seleccionan de manera
que sean apropiadas para el producto de trabajo, por ejemplo, la utilización de páginas (en vez de palabras o letras) como una métrica
para documentos, o tomar en cuenta las tareas de programación y el lenguaje para los componentes de software (ver el Áreas de
Conocimiento 3.1 y 3.2). Los datos de las métricas de tamaño deben recolectarse en tiempo real en la medida de lo posible porque los
datos recolectados después de los hechos es más probable que sean inexactos. La medición de tamaño se aplica no sólo a los
componentes del producto final, sino también a los componentes y versiones intermedias de los productos.
Los datos de tamaño son más exactos cuando se recolectan utilizando una herramienta automática en la que se registran tanto el tamaño
planeado como el real de las diferentes partes del producto o componentes, usando las categorías de las métricas de tamaño descritas
en 3.1.6. La herramienta debe calcular los totales de los datos para cada categoría de tamaño o por lo menos garantizar la propia
consistencia de los datos recolectados.
2.3.4 Quality measures (defect data) metricas de calidad (datos de defectos)
En la PSP la calidad del producto se mide en términos de defectos. Un defecto es cualquier cosa en algún componente de software o del
producto que debe ser cambiado para que sea correctamente diseñado, desarrollado, mantenido, fortalecido, o usado. Los defectos
pueden estar en el código, diseño, requerimientos, especificaciones, u otra documentación. Los defectos deben ser registrados tan pronto
como son descubiertos, preferiblemente usando una herramienta automatizada. Los siguientes datos deben recolectarse para cada
defecto insertado: numero identificador del defecto, fecha de cuando el defecto fue descubierto, fase en que el defecto fue insertado,
fase en que el defecto fue removido, tipo de defecto, tiempo para encontrar y corregir el defecto y una breve descripción del defecto.
Un nuevo defecto se puede insertar mientras que se corrige otro defecto, en este caso el segundo defecto se registra por separado con
una referencia (llamada de referencia de corrección (fix reference)) al defecto original. El tiempo necesario para corregir cada defecto
incluye el tiempo total requerido para encontrar y solucionar el problema y el tiempo requerido para validar la corrección. El tiempo de
corrección se registra por separado para cada defecto.
2.3.5 Defect type standard (estandar de tipos de defectos)
El estándar define las categorías dentro de las cuales se pueden clasificar defectos similares. La asignación coherente de los defectos
similares a la misma categoría de tipo de defecto es fundamental para el análisis del proceso.
2.3.6 Schedule measures (métricas de calendario)
Las métricas de calendario se usan para planear cuando el proyecto debe terminarse y para dar seguimiento al mismo con respecto al
plan. Los datos de calendario son más exactos cuando se recolectan utilizando una herramienta automatizada que registre nombres y

14
descripciones de las tareas planeadas, las fases en las que el trabajo se hará, producto o elemento en cuestión, fechas pertinentes
comprometidas para completar las tareas y las fechas en que se terminaron las tareas. Los datos de calendario deben ser recolectados
en tiempo real en la medida de lo posible, sobre todo la información de las fechas de terminación de las tareas, ya que esta es la manera
de obtener el earned value (valor ganado) (EV) que permite a los individuos el seguimiento de su progreso en relación con el calendario
planeado (ver 4.5).
2.3.7 Derived measures (métricas derivadas)
PSP ofrece un conjunto de métricas de desempeño y calidad para ayudar a las personas a aplicar y mejorar sus procesos personales.
Las métricas derivadas específicas se revisan en áreas de conocimiento posteriores.
Knowledge Area 2.4: Data Analysis (análisis de datos)
Esta área de conocimiento describe los conocimientos y habilidades necesarias para los profesionales de PSP que les permitan analizar
los datos que recolectan del proceso.
2.4.1 Measurement framework and data analysis (marco de medición y análisis de datos)
Todas las métricas en PSP están relacionadas. Las personas deben entender cómo cada métrica se relaciona con las demás y cómo
pueden ser utilizadas para derivar las métricas que proporcionan información sobre la eficacia del proceso.
2.4.2 Postmortem
Un análisis postmortem sobre el trabajo realizado en una fase o proyecto proporciona información valiosa, incluida
• datos actualizados del proyecto para tiempo, tamaño, defectos y calendario (real, a la fecha, y porcentaje (%) a la fecha)
• los cálculos actualizados de datos para calidad y desempeño
• una revisión del desempeño contra lo planeado
• base de datos históricos actualizado para el tamaño y la productividad
• ajustes necesarios al proceso, basado en datos personales (notas tomadas en formatos de propuestas de mejora de procesos
(PIP), cambios en las listas de revisión de diseño o código señalados por los defectos que se escaparon de alguna fase, etc.)
2.4.3 Performance measures (métricas de desempeño)
Las métricas clave del desempeño del proceso personal son
• capacidad para cumplir los compromisos de calendario para la entrega de los componentes prometidos
• calidad de los elementos entregados
• métricas específicas de proyecto
2.4.4 Performance baselines (líneas base de desempeño)
Antes de que las personas puedan mejorar su desempeño, primero tienen que entender el nivel de su desempeño actual. Después de
recolectar suficientes datos del proyecto que proporcione una cantidad significativa de información para el análisis, las personas deben
realizar un análisis de línea base de su desempeño a la fecha y formular cambios adecuados en los procesos para mejorar su desempeño
en las áreas problemáticas.
2.4.5 Combined measures (métricas combinadas)
Las métricas se pueden combinar para proporcionar datos útiles para los planes de futuros proyectos y mejoras en los procesos. Por
ejemplo, las métricas de varios proyectos pueden ser combinadas para crear un gráfico que muestra las tendencias en el tamaño
estimado frente a tamaño real, para proporcionar datos para las futuras estimaciones de tamaño.
2.4.6 Analyzing historical data (análisis de datos históricos)
Los datos deben ser examinados para determinar si son adecuados para el análisis. Por ejemplo, los datos de los proyectos basados en
el lenguaje C# pueden no proporcionar una correlación adecuada para el análisis de proyectos basados en el lenguaje C ++. Los datos
históricos también deben ser examinados para determinar si la correlación es adecuada y significativa como base para los procesos de
medición y análisis del proyecto.
2.4.7 Analyzing size-estimating accuracy (Análisis de la precisión de la estimación del tamaño)
Los datos Históricos del tamaño estimado frente a tamaño real tomados del proceso personal pueden ser analizados para determinar las
posibles causas de malas estimaciones. Considere las siguientes preguntas.
• ¿Con qué frecuencia está lo estimado contra lo real dentro del 70% del intervalo de predicción?
• ¿Hay una tendencia a omitir partes en el diseño conceptual?
• ¿Qué podría hacerse para mejorar las estimaciones?
• ¿Están las estimaciones de tamaño sesgadas de alguna manera?
• ¿Existe una tendencia a juzgar mal los tamaños relativos de las partes?
• ¿Las estimaciones de tamaño mejoran con el tiempo?
2.4.8 Analyzing effort-estimating accuracy
Los datos históricos de las estimaciones de esfuerzo estimado vs esfuerzo real del proceso personal pueden ser analizados para
determinar las posibles causas de malas estimaciones.
• ¿Con qué frecuencia está lo estimado contra lo real dentro del 70% del intervalo de predicción?
• ¿Los errores de estimación de tamaño correlacionan con los errores de estimación del esfuerzo?

15
• ¿los proyectos subestimados correlacionan con un mayor porcentaje de re-trabajo?
• ¿Están mejorando las estimaciones de esfuerzo?
• ¿Qué podría hacerse para mejorar la exactitud de la estimación?
2.4.9 Analyzing size and time relationships (análisis entre la relación de tamaño y tiempo)
Los datos históricos del proceso personal pueden ser analizados para determinar cualquier relación entre tamaño y esfuerzo. Considere
las siguientes preguntas.
• ¿La productividad es estable? ¿Por qué o por qué no?
• ¿Existen diferencias cuantitativas entre los proyectos de mayor y menor productividad? Si es así, ¿cómo se
podrían explicar estas diferencias cuantitativas?
2.4.10 Analyzing phase yields (analizando los yields de las fases)
Los datos históricos del yield (rendimiento) por fase del proceso personal pueden ser analizados para identificar problemas y generar
PIP´s para posibles mejoras. Considere las siguientes preguntas.
• ¿Existe una relación entre el yield y la tasa de revisión (tamaño revisado por hora) para las revisiones de diseño y de código?
• ¿Se encuentran suficientes defectos en las fases adecuadas?
• ¿Las revisiones se están llevando a cabo de manera efectiva?
• ¿Cuáles son los apalancamientos (leverages) de eliminación de defectos personales para las diversas combinaciones de las
fases de evaluación/falla?, ¿cómo se pueden mejorar estos apalancamientos (leverages)?
2.4.11 Analyzing defects injected per phase (analizando los defectos inyectados por fase)
Un análisis de Pareto de los tipos de defectos es una herramienta útil para analizar los datos personales del proceso para defectos
inyectados por fase. Considere las siguientes cuestiones.
• Determinar qué tipos de defectos se presentan con más frecuencia.
• Determinar qué tipos de defectos tardan más en encontrarse y corregirse.
• Analizar las tendencias por fase y generales de los defectos inyectado por unidad de tamaño.
• Analizar las tendencias por fase y generales de los defectos inyectados por hora.
2.4.12 Determining the cost of rework (determinar el costo del re-trabajo)
Los datos pueden ser analizados para determinar el costo del re-trabajo. Tenga en cuenta los siguientes aspectos al realizar un análisis.
• Determinar el porcentaje de tiempo del proyecto PSP que tomará hacer una prueba libre de defectos.
• Determinar cuánto tiempo toman las pruebas para los proyectos de PSP.
• Determinar qué tipos de defectos son los más costosos para encontrar y corregir en términos de tiempo (por fase y por
proyecto).
• Determinar los tipos de defectos más comúnmente encontrados en la compilación y las pruebas personales.
• Determinar los tipos de defectos más comúnmente encontrados en las pruebas de producto y en el producto entregado.
• Generar un análisis de Pareto 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 (Justificación de la mejora de procesos)
La implementación de mejoras en los procesos se hace para aumentar la predictibilidad y la calidad de las entregas, reducir el tiempo de
ciclo y mantener o mejorar la productividad.
2.5.2 Scope for process improvement (Ámbito de aplicación del proceso de mejora)
Muchos tipos de procesos pueden y deben ser utilizados, incluidos los personales, de equipo, y los procesos de la organización.
• Aunque las personas implicadas en la mejora del proceso varía en función del tipo de proceso, los principios y métodos son
idénticos para todos los tipos de proceso.
• Las personas que deben realizar el trabajo de mejora son las personas que utilizan el proceso: los miembros del equipo, los
equipos, o incluso las organizaciones enteras. Las personas que no están utilizando actualmente el proceso normalmente son
incapaces de definir mejoras útiles y de ayuda para quienes lo usan.
• Son raras las mejoras sustanciales al proceso, pero pequeños 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 la siguiente.
• Identifique a uno o más proyectos que realicen un trabajo similar.
• Establecer convenios de evaluación comparativa con los individuos que hagan un trabajo similar. Al hacerlo, hay que considerar
o la similitud del trabajo
o oportunidades para los equipos de interactuar y compartir datos relevantes
o material confidencial
o disposición a la divulgación
o entrega de datos y/o publicación
o gestión de las revisiones y supervisión

16
• Seleccionar los puntos de referencia mejores de su clase, entre los proyectos de colaboración.
• Periódicamente establecer y actualizar objetivos de referencia para el costo, fechas, y el desempeño de calidad.
2.5.4 Set performance improvement goals based on data (establecer las metas de mejora con base en los datos históricos)
Antes de implementar cualquier cambio al proceso, los profesionales de PSP deben analizar los datos históricos del proceso para
determinar las causas originales de los pasados problemas en desempeño. La ejecución de un análisis a fondo en las líneas base del
desempeño debe ayudar a los individuos a determinar las áreas más importantes de mejora. Una vez que se han identificado los cambios
potenciales, es importante fijar metas medibles de la mejora (e.g., “reducir el costo del re-trabajo en 20%”) para saber cuándo se ha
alcanzado la mejora deseada.
2.5.5 Record process improvement suggestions (registro de PIPs)
PSP utiliza un formato de Propuesta de Mejora de Procesos (PIP) que recoge los problemas en el uso del proceso y las sugerencias
para mejorarlo o modificarlo. Se debe mantener el formato PIP a la mano en todo momento, para el 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 más alto valor)
El análisis de datos personales genera muchas PIPs. Los profesionales deben optar por la aplicación de las PIPs que ofrecen el mayor
potencial de mejora en comparación con el esfuerzo requerido para hacer los cambios.
2.5.7 Measure process changes (Métricas de Cambios de proceso)
Debido a que los profesionales de PSP utilizan procesos personales como base para hacer su trabajo, deben entender la forma de
actualizar sus procesos para reflejar los cambios realizados a esos procesos. Deben también ser conscientes del impacto que los cambios
pueden tener en la aplicabilidad de sus datos históricos para el trabajo futuro que se realizará con el proceso modificado.
2.5.8 Monitor performance results (Monitor de resultados de desempeño)
Para determinar si las mejoras de proceso ejecutadas han sido eficaces, los profesionales de PSP periódicamente debe repetir los pasos
para generar la línea base de sus procesos de trabajo y compararla contra los objetivos de mejora previamente establecidos. Cuando
esto se hace los profesionales deben ser cuidadosos de evitar el bolstering (reforzar) y el clutching (agarrarse)
• El Bolstering (reforzar) es el recuerdo selectivo de únicamente los resultados que refuerzan una opinión o creencia, por lo
general se manifiesta olvidando las fallar y recordando solamente los éxitos. El uso de todos los datos de PSP de todos los
proyectos debería evitar el bolstering.
• Clutching (agarrarse) es la tendencia a un mal desempeño cuando se está bajo presión o cuando un buen resultado es
especialmente crítico, negando así el desempeño exitoso de los proyectos anteriores utilizando los mismos procesos.
Siguiendo procesos establecidos y usando datos (en vez del 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 problemáticas y ser conscientes de
ideas para la mejora continua.
Competency Area 3: Size Measuring and Estimating (Medición del tamaño y estimación)
En esta área de competencia se describen los conceptos de medición del tamaño y estimación en que se basa PSP. Los elementos
esenciales de la medición y estimación de tamaño son la capacidad de definir las métricas de tamaño adecuadas y utilizar métodos
disciplinados y datos históricos para estimar el tamaño. Las áreas de conocimiento principales que componen esta área de competencia
son las siguientes:
3.1 Size Measures (métricas de tamaño) – Esta área de conocimiento bosqueja los objetivos para medir el tamaño, los criterios para la
selección de una métrica de tamaño y el sistema de conteo de tamaño de PSP.
3.2 Size Data (datos de tamaño) – Esta área de conocimiento describe las principales formas en que los datos de tamaño se utilizan en
PSP.
3.3 Size Estimating Principles (principios de estimación de tamaño) – En esta área de conocimiento se revisan los principios sobre
los cuales se basa el proceso de estimación de tamaño de PSP. El PSP apoya muchos métodos de estimación de tamaño, pero todos
los métodos deben adherirse a estos principios.
3.4 Proxies (sustitutos) – Esta área de conocimiento se describe la selección y organización de los datos de proxy.
3.5 The PROBE Estimating Method (el método de estimación PROBE) – PSP utiliza un proceso de estimación definido llamado
Estimación basada en proxies (PROBE – PROxy Based Estimating). Este método se utiliza para estimar tanto el tamaño como el
esfuerzo. Esta área de conocimiento define cómo se realizan las estimaciones del tamaño mediante el método PROBE.
3.6 Combining Estimates (combinación de estimaciones) – Esta área de conocimiento describe las distintas maneras en que las
estimaciones pueden ser combinadas
3.7 Size Estimation Guidelines (guias de estimación de tamaño) – Esta área de conocimiento se mencionan las limitaciones de la
estimación de tamaño.

17
Knowledge Area 3.1: Size Measures (métricas de tamaño)
En esta área de conocimiento se bosquejan los objetivos para medir el tamaño, los criterios para la selección de una métrica de tamaño,
y el sistema de conteo de tamaño de PSP.
3.1.1 Rationale for using size measures (Justificación para el uso de medidas de tamaño)
Entre los objetivos para utilizar métricas de tamaño se incluyen
• lograr consistencia en la descripción de tamaño
• normalizar los datos de tiempos y defectos
• lograr mejores estimaciones de tamaño y mejores planes
3.1.2 Types of measures (tipos de métricas)
Las métricas pueden clasificarse como:
• absolutas o relativas
• explicitas o derivadas
• objetivas o subjetivas
• dinámicas o estáticas
• predictivas o explicativas
3.1.3 Criteria for size measures (Criterios para las métricas de tamaño)
Las buenas métricas de tamaño deben ser
• relacionadas con el esfuerzo de desarrollo
o ¿el tamaño del producto correlaciona estadísticamente con el esfuerzo de desarrollo?
o ¿el tiempo invertido en el desarrollo de la parte medida del producto representa una parte significativa del trabajo del
proyecto?
• definidas con precisión
• directamente contables
• adecuadas para la planificación temprana
3.1.4 Counting standards (estándares de conteo)
Los estándares de conteo proveen una guía que es
• precisa sobre lo que debe contar
• específica para el lenguaje y el tipo de aplicación
• invariable, que da el mismo resultado cada vez que el estándar se aplica
3.1.5 Physical and logical size (tamaño físico y lógico)
Una métrica de tamaño físico proporciona información acerca del tamaño de una entidad física (el número real de ocurrencias de un
elemento en algún producto). Una métrica de tamaño lógico también proporciona información sobre el tamaño, pero se basa en el conteo
de las agrupaciones de entidades físicas que se pueden agrupar lógicamente. La métrica lógica del tamaño de una entidad física no
corresponde necesariamente a la métrica física del tamaño de esa misma entidad, dependiendo del estándar de conteo definido para la
métrica lógica.
3.1.6 Size accounting (conteo de tamaño)
Los métodos de conteo de tamaño de PSP para el tamaño planeado, actual, y a la fecha definen métricas para
• base (B): la parte no modificada del programa a la que se añaden mejoras posteriores
• added (A): (agregadas) código que se agrega al código base
• modified (M): (modificadas) la parte del código base se cambia
• deleted (D): (borradas la parte del código base que posteriormente se borra
• reused (R): (re-usadas) partes o elementos que son copiados sin cambios de una fuente distinta de la base
• added and modified (A&M): (agregadas y modificadas) todo el código añadido y modificado
• new reusable (NR): (nuevo re-uso) una parte o elemento que se desarrolla con la intención de volverlo a utilizar después
• total (T): el tamaño del programa completo
3.1.7 Using the size measure selection procedure (Uso del procedimiento de selección de la métrica)
Los pasos para la selección de métricas de tamaño son los siguientes.
1. Recolectar datos sobre el desarrollo de productos (recursos necesarios, métricas de las características del producto, cualquier
condición especial de desarrollo, etc.)
2. Ordenar los productos con base en los recursos necesarios.
3. Identificar las características que distinguen a los productos que requirieron el mayor esfuerzo de los que requirieron el menor
esfuerzo.
4. Seleccionar una métrica o métricas de tamaño. Para las métricas de tamaño viables determinar la correlación entre el tamaño
y los recursos necesarios. Si no hay una correlación, repita los pasos 3 y 4 para las otras métricas de tamaño viables.
Algunas métricas típicas de tamaño incluyen
• elementos de base de datos: un conteo de los campos, consultas, o de otros elementos de uso común en un producto de base
de datos.

18
• líneas de código (LOC): un conteo de las líneas lógicas de código en un producto.
• elementos de la pantalla: un conteo de los elementos de una interfaz de usuario o GUI (interfaz gráfica de usuario) del producto.
• tamaño del documento: un conteo de las páginas, líneas, palabras o caracteres del documento.
• tamaño del diseño: un conteo de las clases, definiciones de datos, especificaciones de interface, o características definidas de
interfaz gráfica de usuario.
• tamaño de los requerimientos: un conteo de páginas de requerimientos, narrativas o puntos de función.
Knowledge Area 3.2: Size Data (datos de tamaño)
Esta área de conocimiento describe las principales formas en que los datos de tamaño se utilizan en PSP.
3.2.1 Size data help to make better plans (los datos ayudan a hacer mejores planes)
El tamaño y el tiempo a menudo tienen correlación, y cuando eso ocurre, las estimaciones de tamaño se pueden utilizar para estimar el
esfuerzo. Los planes pueden ser creados con base en las estimaciones de tamaño y esfuerzo.
3.2.2 Size data are useful for tracking development effort (los datos de tamaño son útiles para el seguimiento del esfuerzo de
desarrollo)
El tamaño y el tiempo a menudo tienen correlación, y cuando la tienen, las estimaciones de tamaño se pueden utilizar para dar
seguimiento al esfuerzo.
3.2.3 Size data help in assessing program quality (los datos de tamaño ayudan a evaluar la calidad del programa)
La normalización de los datos de los defectos basándose en el tamaño permite determinar
• la calidad de la totalidad o una parte del proceso de desarrollo
• contenido relativo de defectos de algunas partes de programa o de programas grandes
• carga de trabajo futura para el mantenimiento y soporte
Knowledge Area 3.3: Size Estimating Principles (principios de estimación de tamaño)
En esta área de conocimiento se revisan los principios sobre los cuales se basa el proceso de estimación de tamaño de PSP. El PSP
apoya muchos métodos de estimación de tamaño, pero todos los métodos deben adherirse a estos principios.
3.3.1 Estimating is uncertain (la estimación es incierta)
Nadie sabe cuán grande será el producto, y mientras más temprano en el proceso se hace la estimación menos se sabe. Las estimaciones
pueden estar sesgadas por las necesidades de negocio y otras presiones.
3.3.2 Estimating is a learning process (la estimación es un proceso de aprendizaje)
La estimación de mejora con la experiencia y con los datos.
3.3.3 Estimating is a skill (Estimar es una habilidad)
Algunas personas pueden ser mejores estimando que otras. La mayoría de las personas mejoran en la estimación mediante la práctica.
3.3.4 Strive for consistency (Esforzarse por la coherencia)
El objetivo del proceso de estimación del tamaño es que consistentemente se generen estimaciones sin sesgos. Hacerlo, equilibrará las
sobreestimaciones y las subestimaciones.
3.3.5 Use defined methods for making estimates(Uso de métodos definidos para hacer estimaciones)
Utilizar un proceso definido de estimación de tamaño facilita el aprendizaje, proporciona una estructura para el uso de datos históricos,
establece una línea de referencia contra la cual se puede medir la mejora y ayuda a eliminar el sesgo en el proceso.
3.3.6 Estimates are subject to error (Las estimaciones están sujetas a error)
La exactitud de estimaciones fluctuará alrededor de una media. Las estimaciones pueden también tener cierto sesgo.
3.3.7 Estimate in detail (Estimación a detalle)
Cuando se estima en partes, el error total será menor que la suma de los errores de las partes, suponiendo que las partes se estiman de
forma independiente. La estimación a detalle también ayuda a asegurar que la estimación está completa.
3.3.8 Use historical data to make estimates (utilizar datos históricos para hacer estimaciones)
Al hacer las estimaciones de tamaño, encontrar una manera de utilizar cualquier dato histórico disponible.
Knowledge Area 3.4: Proxies (Sustitutos)
Esta área de conocimiento describe la selección y organización de los datos de los proxies.
3.4.1 Using proxies instead of a size measure (Usando proxies en lugar de una métrica de tamaño)
La mayoría de las métricas de tamaño que cumplen los criterios necesarios no están disponibles durante la planeación. Un proxy es una
métrica sustituta que relaciona el tamaño del producto con la funcionalidad planeada y proporciona un medio en la fase de planeación
para juzgar (y por lo tanto, estimar) el tamaño probable de un producto.

19
3.4.2 Criteria for choosing a proxy (criterios para elegir un proxy)
Los criterios de un buen proxy son los siguientes.
• El tamaño de la métrica del proxy debe correlacionar cercanamente con el esfuerzo necesario para desarrollar el producto y
correlacionar con los costos de desarrollo.
• El contenido de proxies en un producto se debe poder contar directamente.
• El proxy debe ser fácil de visualizar al inicio de un proyecto.
• El proxy debe ser adaptable a las necesidades de cada proyecto e individuo
• El proxy debe ser sensible a las variaciones de la implementación que afectan el costo o el esfuerzo.
3.4.3 Using relative size tables (usando tablas de tamaños relativos)
Las tablas de tamaño relativo se utilizan para organizar los datos de los proxies para que los datos históricos puedan ser utilizados para
estimar el tamaño de partes nuevas semejantes.
3.4.4 Building a relative size table (construyendo tablas de tamaños relativos)
PSP establece dos procedimientos para la creación de una tabla de datos históricos de tamaños relativos: el método del ordenamiento
(sort) y el método de la desviación estándar. Otros métodos pueden ser utilizados, pero deben cumplir con los principios de estimación
de tamaño.
3.4.5 Building a relative size table with the sort procedure (construyendo la tabla de tamaños relativos con el procedimiento
del ordenamiento)
Cuando se utiliza el procedimiento del ordenamiento para la construcción de una tabla del tamaño relativo, las partes son separadas en
categorías funcionales, tales como cálculo, texto, datos, etc. La tabla se llena completando los siguientes pasos para cada categoría:
1. Ordenar los datos de tamaño.
2. Elija el valor más pequeño como muy pequeño (VS).
3. Elija el valor más grande como muy grande (VL).
4. Escoja el valor mediano como medio (M).
5. Para grande (L) y pequeño (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 construcción de una tabla de tamaño relativo con
el procedimiento de la desviación estándar)
Cuando se utiliza el procedimiento de la desviación estándar para la construcción de una tabla del tamaño relativo, las partes son
separadas en categorías funcionales, tales como cálculo, texto, datos, etc. La tabla se llena completando los siguientes pasos para cada
categoría:
1. Si los datos tienen una distribución logarítmica normal (como es común para el caso de los datos de tamaño de programa), transformar
los datos en una distribución normal mediante el cálculo del logaritmo natural de cada dato, de no ser así saltarse este pasó.
2. Calcular la media (avg) y la desviación estándar (σ) del conjunto de datos.
3. Calcular los rangos de tamaño a través de VS = avg–2σ; S = avg– σ; M = avg; L = avg+ σ; VL = avg+2 σ.
4. Si los datos originales tenían una distribución logarítmica normal, aplicar la transformación inversa mediante el cálculo del antilogaritmo
de cada uno de VS, S, M, L, y VL; de otra forma no hacer nada.
Knowledge Area 3.5: The PROBE Estimating Method (el método de estimación PROBE)
PSP utiliza un proceso de estimación definido llamado Estimación basada en proxies (PROBE – PROxy Based Estimating). Este método
se utiliza para estimar tanto el tamaño como el esfuerzo. Esta área de conocimiento define cómo se realizan las estimaciones del tamaño
mediante el método PROBE.
3.5.1 What is PROBE? (¿Qué es PROBE?)
PROBE es un procedimiento para estimar el tamaño y el esfuerzo. El procedimiento general es el siguiente.
1. Definir el diseño conceptual (ver 3.5.2).
2. Identificar y darle tamaño a los proxies.
3. Estimar los otros elementos.
4. Estimar el tamaño del programa. (Seleccione el método PROBE apropiado, como se describe en 3.3.5.)
5. Calcular los intervalos de predicción (solamente para los métodos A y B) (ver 3.5.8).
3.5.2 Conceptual design (diseño conceptual)
El diseño conceptual es una representación de alto nivel de los elementos del producto y de sus funciones. El diseño conceptual divide
un producto deseado en sus partes principales. El diseño conceptual se utiliza únicamente como una base para construir la estimación
de tamaño y esfuerzo (ver 4.2.4) y no necesariamente refleja cómo el producto real será diseñado y construido.
3.5.3 Formulate size estimates for proxies (Formular las estimaciones del tamaño de los proxies)
Compare el tamaño de las piezas nuevas en el diseño conceptual contra las partes similares en la base de datos histórica para evaluar
el tipo y tamaño relativo. Utilice el número de elementos por parte y los datos históricos de tamaño por parte para estimar el tamaño del
proxy.
3.5.4 Formulate estimates for various types of program elements (Formular las estimaciones para los distintos tipos de
elementos de programa)
• Contar el tamaño base (B).
• Estimar las Modificaciones (M).

20
• Estimar las Eliminaciones (D).
• Estimar las Adiciones a la base (BA).
• Estimar la Partes Añadidas (PA).
• Estimar el Re-uso (R).
• Estimar el nuevo re-uso planeado (NR).
3.5.5 Select the appropriate PROBE method (seleccionar el método PROBE adecuado)
1. Compruebe si el método A puede ser utilizado asegurando que los datos cumplen los criterios de abajo, y evaluando la
correlación de, ß0, y ß1.
 Hay tres o más puntos de datos (estimados E y reales A&M) que correlacionan.
 El valor absoluto de ß0 es menor al 25% del tamaño esperado del nuevo programa.
 ß1 se encuentra entre 0,5 y 2.
Si el método PROBE A se puede utilizar, entonces calcular el tamaño proyectado como y = ß0 + ß1(E), donde
 y = tamaño proyectado de adicionadas y modificadas
 E = tamaño estimado proxy
 ß0 y ß1 se calculan utilizando el tamaño estimado proxy y el tamaño real de adicionadas y modificadas
2. Si el método A no puede ser usado, verifique si el método B se puede utilizar.
 Hay tres o más puntos de datos (A&M planeadas y A&M reales) que correlacionan.
 El valor absoluto de ß0 es menor al 25% del tamaño esperado del nuevo programa.
 ß1 se encuentra entre 0,5 y 2.
Si el método PROBE B se puede utilizar, entonces, calcular el tamaño proyectado como y = ß0 + ß1(E), donde
 y = tamaño proyectado de adicionadas y modificadas
 E = tamaño estimado proxy
 ß0 y ß1 se calculan utilizando el tamaño planeado de adicionadas y modificadas y el tamaño real de
adicionadas y modificadas
3. Si los métodos A y B no puede ser utilizados y se tiene datos históricos, utilice el método C. Calcular el tamaño del
proyecto como y = ß0 + ß1 (E), donde
 y = tamaño proyectado de modificaciones y adiciones
 E = tamaño estimado proxy
 ß0 = 0
 ß1 = ActualTotalAdded&ModifiedSizeToDate (Tamaño total real a la fecha de adicionadas y modificadas) /
PlanTotalAdded&ModifiedSizeToDate (Tamaño total planeado a la fecha de adicionadas y modificadas)
4. Si no hay datos históricos, utilice el método D, que consiste en utilizar el juicio para estimar el tamaño de adicionadas y
modificadas.
3.5.6 Estimate program size (Estimar el tamaño del programa)
Calcular el tamaño del proxy estimado, E = BA + PA + M.
• Calcular el tamaño proyectado de A&M, P = ß0 + ß1 (E), para los métodos A, B, y C. Para el método D, P = juicio profesional
• Calcular el tamaño de adicionadas planeado, A = A&M – M.
• Calcular el tamaño total planeado, T = P + B – M + R.
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 tamaño real del proxy, E = BA+PA+M.
• Contar el tamaño total real, T.
• Calcular el tamaño real de adicionadas, A = T-B+D-R.
• Calcular el tamaño actual de adicionadas y modificadas, A&M = A+M.
• Contar el tamaño real del nuevo re-uso, NR.
3.5.8 Prediction interval definition (Definición de intervalo de predicción)
El intervalo de predicción se utiliza en los métodos PROBE A y B. Un intervalo de predicción es
• el rango en que el tamaño real es probable que caiga el 70% de las veces
• no es un pronóstico
• aplicable solamente si la estimación se comporta como los datos históricos
Knowledge Area 3.6: Combining Estimates (La combinación de estimaciones)
Esta área de conocimiento describe las distintas maneras en que las estimaciones pueden ser combinadas.
3.6.1 Combine independent estimates (combinar estimaciones independientes)
Utilice este método de combinar estimaciones independientes.
1. Hacer proyecciones de regresión lineal separadas.

21
2. Sumar los tamaños proyectados.
3. Sumar los cuadrados de los rangos individuales y calcule la raíz cuadrada para calcular el intervalo de predicción.
3.6.2 Use multiple proxies (utilizar multiples proxies)
Utilice regresión múltiple cuando hay (a) correlación entre el tiempo de desarrollo y cada proxy, y (b) los proxies no tienen datos de
tamaño por tiempo separados.
1. Identifique y clasifique cada proxy.
2. Utilice regresión múltiple para proyectar el tamaño del programa
y = ß0 + x1ß1 + x2ß2 + . . . xmßm
3. Calcule los intervalos de predicción.
UPI = projected size + range (70%) (tamaño proyectado + rango(70%))
LPI = projected size – range (70%) (tamaño proyectado - rango(70%))
Knowledge Area 3.7: Size Estimation Guidelines (Guías para la estimación del tamaño)
Esta área de conocimiento describe las limitaciones de la estimación de tamaño.
3.7.1 Clustered or grouped data (datos amontonados o agrupados)
Para datos amontonados o agrupados las estimaciones de tamaño pueden no ser muy útiles para estimar esfuerzo. Sin embargo, la
estimación de tamaño aún puede ser útil en el cálculo del esfuerzo promedio.
3.7.2 Extreme data points (Puntos de datos extremos)
Puntos extremos de datos pueden llevar a valores erróneos de ß0 y ß1, incluso habiendo alta correlación. Estimaciones hechas con
puntos fuera de rango de los datos utilizados para calcular ß0 y ß1 probablemente estarán seriamente equivocadas.
3.7.3 Unprecedented products (Productos sin precedentes)
Resístase a hacer una estimación antes de terminar un estudio de viabilidad y un desarrollo de prototipos. No confunda el hacer una
estimación con adivinar.
3.7.4 Data range (rango de datos)
Estimaciones hechas con puntos fuera de rango de los datos utilizados para calcular ß0 y ß1 probablemente estarán seriamente
equivocadas.
Competency Area 4: Making and Tracking Project Plans (Construir y dar seguimiento a planes de proyecto)
Esta área de conocimiento discute la habilidad de utilizar una estimación de tamaño del software para planear y dar seguimiento a un
proyecto de software. Partes esenciales de la planificación del proyecto son la capacidad de construir un calendario, definir tareas,
planear las tareas de conformidad al calendario, y hacer un seguimiento de finalización de tareas contra lo planeado. Las áreas de
conocimiento principales que componen el área de competencia son las siguientes:
4.1 PSP Planning Principles (principios de planeación) – Esta área de conocimiento enuncia los principios sobre los que se basa el
marco de planificación de PSP.
4.2 The PSP Planning Framework (marco de planificación de PSP) – Esta área de conocimiento delinea el marco que integra las
tareas de planificación de PSP, bases de datos históricos, y el seguimiento de las actividades. También incluye el uso de PROBE para
generar estimaciones generales de recursos.
4.3 Software Size and Effort (tamaño del software y esfuerzo) – La planificación de proyectos requiere una estimación del tamaño del
software (ver el área de Competencia 3). En esta área de conocimiento se describe la relación entre el tamaño y esfuerzo.
4.4 Task and Schedule Planning (planeación de tareas y calendario) – Esta área de conocimiento describe cómo utilizar una
estimación general de los recursos para crear un calendario que define las tareas que deben completarse y la fecha esperada de
finalización.
4.5 Schedule Tracking with Earned Value (Seguimiento del calendario con el Valor Ganado) – El sistema de Valor Ganado (EV) de
PSP se usa para rastrear el progreso del trabajo realizado contra el plan. Esta área de conocimiento describe el cálculo de EV, usando
el EV para determinar el progreso del trabajo contra el plan y revisar el calendario previsto, con base en el EV promedio obtenido a la
fecha en el proyecto.
4.6 Planning and Tracking Issues (Asuntos con respecto a planeación y seguimiento) – A la administración se le debe mantener
informada del estatus de proyecto. Los proyectos que no serán terminados a tiempo deben ser re-planeados.
Knowledge Area 4.1: PSP Planning Principles (principios de planeación)
Esta área de conocimiento enuncia los principios sobre los que se basa el marco de planificación de PSP.
4.1.1 Plan your work (planea tu trabajo)
Las personas que hacen el trabajo son los más adecuados para planificar.
 Las personas siempre deben desarrollar un plan de trabajo antes de comprometerse o iniciar un proyecto. Cuando las personas
están involucradas en el desarrollo del plan, es más probable que se comprometan con ese plan.
 Los planes deben basarse en un proceso definido y datos históricos, y estar hechos con un nivel de detalle apropiado para el
trabajo a realizar.
 Cuando es difícil hacer un plan exacto, comience con un plan preliminar y re-planifique a menudo. Cuando el plan no
corresponde al trabajo, revise el plan.

22
4.1.2 What is a PSP plan? (¿Qué es un plan de PSP?)
Un plan de PSP
• define el trabajo y cómo se hará
• es una base para un acuerdo sobre el costo, calendario y los recursos para un proyecto
• es una estructura de organización para hacer el trabajo
• es un marco para la obtención de los recursos necesarios
• proporciona un registro de lo que inicialmente fue comprometido
4.1.3 Detailed plans (planes detallados)
Los planes de trabajo detallados orientan el trabajo de las personas y les permite el seguimiento preciso de su progreso. Los planes
detallados son más precisos, proporcionan métricas más precisas, y dan una mejor orientación que los planes de alto nivel. Los planes
detallados también permiten que las personas puedan hacer proyecciones precisas y compromisos realistas, ser más productivos, hacer
un trabajo de más alta calidad, y mantener su motivación para alcanzar los objetivos del plan.
Knowledge Area 4.2: The PSP Planning Framework (El Marco de Planificación de PSP)
Esta área de conocimiento delinea el marco que integra las tareas de planificación de PSP, bases de datos históricos, y el seguimiento
de las actividades. También incluye el uso de PROBE para generar estimaciones generales de recursos.
4.2.1 Software product plan components (Componentes del plan de producto de software)
Los componentes de un plan de producto de software son las siguientes.
• El tamaño del proyecto: ¿Qué tan grande es el proyecto y cuánto tiempo se necesitará para realizar el proyecto completo?
• Estructura del proyecto: ¿Cómo se llevará a cabo el trabajo? ¿Cómo deben ser secuenciadas las tareas?
• Estado del proyecto: ¿Cuál es el estado del proyecto en un momento determinado? ¿Cómo puede estimarse la fecha de
finalización?
• Evaluación: Comparar los datos reales contra los estimados. ¿Qué tan bueno fue el plan? ¿Cómo se puede mejorar el plan la
próxima vez?
4.2.2 PSP planning framework (Marco de planificación de PSP)
El marco de planificación de PSP consiste en siete tareas básicas.
1. Definir los requerimientos (ver 4.2.3).
2. Generar el diseño conceptual (ver 4.2.4).
3. Generar la estimación de tamaño del producto (ver 3.5.5).
4. Generar la estimación de recursos (ver 4.2.6).
5. Generar el calendario (ver 4.2.10 y 4.5).
6. Desarrollar el producto (ver 4.2.11).
7. Analizar el proceso (ver 4.2.12 y 2.3.2).
4.2.3 Requirements definition (1Definir los requerimientos)
Empezar por definir el trabajo a realizar, a tanto detalle como sea posible. La precisión del plan depende de cuánto sepan las personas
acerca de la labor a realizar en el momento en que se está planificando.
4.2.4 Produce the conceptual design (Generar el diseño conceptual)
El diseño conceptual (ver 3.5.2) es un acercamiento preliminar al producto, nombra los objetos previstos y sus funciones. Al hacer un
diseño conceptual, varios acercamientos alternativos se pueden considerar para elegir el acercamiento óptimo para hacer el trabajo de
desarrollo. Para productos grandes, varios pasos pueden ser necesarios para generar un diseño conceptual.
• Generar una lista preliminar de objetos del producto y sus funciones esperadas.
o Comience con un diseño de sistema o de alto nivel del producto.
o Subdividir las piezas resultantes a un nivel de detalle que corresponda a los elementos existentes en la base de datos
histórica (si las hay).
• Utilice el método PROBE adecuado para generar estimaciones de recursos y de tamaño.
• Totalice la estimación de los elementos para generar la estimación del producto.
4.2.5 Use PROBE for size and resource estimation (Utilizar PROBE para estimar tamaño y recursos)
El método PROBE se utiliza para estimar el tamaño del producto y el tiempo necesario para hacer el trabajo (véase 3.5.5 y 4.2.6).
4.2.6 Select the appropriate PROBE method for resource estimation (seleccione el método PROBE adecuado para estimación
de recursos)
• Compruebe si el método A puede ser utilizado.
o Se tienen tres o más puntos de datos (E estimada y tiempo real de desarrollo) que correlacionan.
o El valor absoluto de ß0 es cercano a 0.
o ß1 está dentro del 50% de 1/(productividad histórica).
• Si el método A no puede ser usado, revise para ver si el método B se puede utilizar.
o Se tienen tres o más puntos de datos (A&M planeadas y tiempo real de desarrollo) que correlacionan.
o El valor absoluto de ß0 es cercano a 0.
o ß1 está dentro del 50% de 1/(productividad histórica).

23
• Si el método B no puede ser utilizado y hay datos históricos, utilice el método C.
• Si no hay datos históricos, utilice el método D.
4.2.7 To-date time in phase (tiempos a la fecha en las fases)
El tiempo a la fecha en fase, es la suma del tiempo real para una fase determinada en un proyecto en particular más el tiempo a la fecha
de esa fase en el los proyectos históricos.
4.2.8 To-date percent time in phase (porcentaje de tiempo a la fecha en fase)
El porcentaje de tiempo a la fecha en fase es el porcentaje de tiempo a la fecha en cada fase.
4.2.9 Distributing time across phases (Distribución de tiempo a través de las fases)
El tiempo planeado se distribuye a través de fases usando el porcentaje de tiempo histórico a la fecha en fase.
4.2.10 Schedule projection (proyección de calendario)
Un calendario de valor ganado proporciona una proyección de la fecha de terminación del proyecto (ver 4.5).
4.2.11 Product development (desarrollo del producto)
El desarrollo de productos es guiado por el proceso personal definido usado para generar el plan. A medida que se hace el trabajo, los
individuos recolectan y registran datos.
4.2.12 Process analysis (analisis de proceso)
Al final de un proyecto, los datos recolectados son analizados (ver 2.3.2).
4.2.13 Cost performance index (CPI) (índice de desempeño del costo)
El índice de desempeño del costo (CPI) se calcula como
tiempo de desarrollo total planeado a la fecha/ tiempo real total de desarrollo la fecha.
Knowledge Area 4.3: Software Size and Effort (tamaño y esfuerzo del software)
La planificación de proyectos requiere una estimación del tamaño del software (ver el área de Competencia 3). En esta área de
conocimiento se describe la relación entre el tamaño y esfuerzo.
4.3.1 Size and effort correlation (correlacion de tamaño con esfuerzo)
Proyectos más grandes de programación requieren mayor esfuerzo. Estimar con precisión el esfuerzo de programación requiere el uso
de una métrica de tamaño que tenga una correlación significativa con el esfuerzo. Los datos de tamaño son adecuados para la
planificación si el valor de r² es más grande que 0.5 y si y si el área de la cola en el cálculo de la significancia es <= 0,05.
4.3.2 Productivity (productividad)
La productividad es la relación del tamaño de un producto contra el tiempo dedicado a desarrollar este producto, por lo general se es
medida como tamaño por hora.
Knowledge Area 4.4: Task and Schedule Planning (planeación de tareas y calendario)
Esta área de conocimiento describe cómo utilizar una estimación general de los recursos para crear un calendario que define las tareas
que deben completarse y la fecha esperada de finalización.
4.4.1 Project plan characteristics (Características del plan de proyecto)
Un plan de proyecto debe ser
• accesible: fácil de localizar y de referenciar
• claro: concreto y fácil de leer
• específico: responsabilidades y costos identificados
• preciso: nivel apropiado de precisión
• exacto: basado en datos relevantes y con un proceso de estimación no prejuiciado
4.4.2 Period plans and project plans (Planes del período y planes del proyecto)
Un plan del período cubre una unidad de tiempo específica, tal como una semana o un mes. Un plan del proyecto describe todos los
esfuerzos y costos para desarrollar un producto.
4.4.3 Task hours and working hours (Horas de tareas y horas de trabajo)
Horas 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 contabilizan también actividades de no-tareas tales como tiempo de lectura y respuesta de e-mails, asistencia a
reuniones, etc.
4.4.4 Milestones (hitos)
Los hitos son los indicadores clave del progreso del proyecto. Sus fechas de terminación pueden ser estimadas para poder dar
seguimiento del progreso respecto a ellas y los riesgos para su terminación puedan ser tratados antes de que el proyecto vaya seriamente
desfasado del calendario.
4.4.5 Schedule plan requirements (requerimientos del calendario planeado)
Los elementos necesarios para elaborar un plan de calendario son
• un calendario de tiempo disponible
• el orden en que las tareas se completarán
• esfuerzo estimado para cada tarea

24
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 terminación.
 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 tamaño del producto desarrollado por la tarea y los datos históricos de productos de tareas similares
• una estimación total basada en datos de porcentaje a la fecha de procesos similares terminados
• la técnica de estimación PROBE apropiada
4.4.8 PSP schedule plans (planes de calendario PSP)
Los planes de calendario son producidos para los proyectos de PSP siguiendo los tres pasos siguientes.
1. Elija un período de tiempo adecuado (por ejemplo, de tres a seis meses a partir de la fecha de inicio planeada).
2. Distribuya el tiempo disponible estimado para tareas a lo largo de la duración del calendario del proyecto.
3. Calcule el acumulado de horas calendario planeadas hasta el final del periodo del proyecto.
4.4.9 PSP task plans (planes de tareas PSP)
Los planes son producidos para los proyectos de PSP siguiendo estos cuatro pasos.
1. Estimar el tiempo de tareas en horas (ver 4.4.7).
2. Calcular la suma del total de horas planeadas.
3. Calcular el plazo del plan en el cual cada tarea definida será terminada, basado en el calendario planeado (véase 4.4.8).
4. Calcular la fecha planeada para la finalización del proyecto.
Knowledge Area 4.5: Schedule Tracking with Earned Value (seguimiento al calendario con valor ganado )
El sistema de Valor Ganado (EV) de PSP se usa para rastrear el progreso del trabajo realizado contra el plan. Esta área de conocimiento
describe el cálculo de EV, usando el EV para determinar el progreso del trabajo contra el plan y revisar el calendario previsto, con base
en el EV promedio obtenido a la fecha, en el proyecto.
4.5.1 Planned value (PV) (valor planeado)
El valor planeado de una tarea es igual al tiempo planeado de la tarea, expresado como porcentaje del tiempo total planeado para el
proyecto. Por ejemplo, una tarea de 5 horas en un proyecto de 50 horas tendría un PV de 10.
4.5.2 Earned value (EV) (valor ganado)
El valor ganado es un método utilizado para el seguimiento del avance real del trabajo terminado con respecto al plan general del
proyecto. A medida que cada tarea se termina, 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 métricas de valor ganado)
Cuando se utiliza EV, tenga en cuenta estas limitaciones.
• El método EV supone que la tasa de finalización de las tareas en el futuro será aproximadamente la misma que en el pasado.
Si este no es el caso, la proyección de EV no será exacta.
• El método de EV mide el avance con respecto el plan. Si el plan es inexacto, las proyecciones de EV también es probable
serán inexactas.
• El método de EV asume que los recursos del proyecto son uniformes. Si el nivel de personal aumenta, las proyecciones de EV
serán pesimistas, y si disminuye el personal, las proyecciones serán optimistas.
4.5.4 EV as a measure of actual progress relative to planned progress (EV como una forma de medir el progreso real en
relación con el avance planeado)
En cualquier momento durante un proyecto la suma del valor ganado para las tareas terminadas representa el porcentaje de trabajo que
se ha completado. Una comparación del EV acumulado contra el PV acumulado indica el avance del trabajo con respecto al calendario
planeado.
• Si PV es el mismo que EV: el trabajo va a tiempo
• EV es más grande que PV: el trabajo esta adelantado con respecto al calendario
• PV es mayor que EV: el trabajo está retrasado con respecto al calendario
4.5.5 Project tracking with EV (Seguimiento del proyecto con EV)
Durante la planificación, el PV total de las tareas del proyecto se puede calcular para cada período de tiempo. Del mismo modo, sumando
los EV´s de las tareas terminadas en cualquier período de tiempo en un proyecto, se determina el porcentaje de trabajo completado a la
fecha para el proyecto. En cualquier punto en el proyecto, el EV se puede comparar con el PV acumulado para determinar si el proyecto
está en tiempo, retrasado, o adelantado (ver 4.5.4 arriba).

25
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, y multiplicando 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 durante ese periodo.
4.5.8 Calculating cumulative PV for a given time period (Cálculo del PV acumulado para un período de tiempo determinado)
El PV acumulado a la fecha para un período de tiempo determinado se calcula sumando los PV’s de todos los periodos de tiempo
precedentes al PV del periodo de tiempo 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)
El EV para un período de tiempo determinado y el EV acumulado para ese mismo período de tiempo pueden 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 va de acuerdo al calendario previsto (ver 4.5.4 arriba).
4.5.10 Estimating the project completion date (Estimación de la fecha de terminación del proyecto)
La fecha estimada de terminación del proyecto se puede calcular mediante el cálculo del EV promedio por semana a la fecha, y a
continuación utiliza el valor promedio de EV por semana para calcular el tiempo necesario para completar el valor planeado restante.
Esto asume que el proyecto continúa ganando la tasa promedio de EV como antes.
Knowledge Area 4.6: Planning and Tracking Issues (Planeacion y seguimiento de Issues)
A la administración se le debe mantener informada del estatus de proyecto. Los proyectos que no serán terminados a tiempo deben ser
re-planeados.
4.6.1 Informing management of issues (Informar a la gerencia sobre los asuntos)
Mantenga a la gerencia informada resultados de análisis de valor ganado e infórmeles sobre problemas de cumplimiento del calendario.
Los datos acerca del estado del proyecto pueden ser útiles para obtener apoyo de la gerencia.
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 métodos o los procesos de trabajo, el plan entero debe ser re-examinado.
4.6.3 Handling part-time assignments (manejando asignaciones de tiempo parcial)
Asignaciones de tiempo parcial pueden ser problemáticas porque las horas de tareas (task hours) se dividen entre varios proyectos. El
cambio frecuente entre las tareas hace difícil el trabajo en cualquier tarea y obstaculiza la coordinación con otros miembros de equipo en
un proyecto.
Competency Area 5: Planning and Tracking Software Quality (planeación y seguimiento a la calidad del software)
Esta área de competencia describe la necesidad de construir productos que satisfagan las necesidades de los usuarios, las formas de
medir el grado de satisfacción de las necesidades del usuario, y las formas 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 enuncia los principios sobre los que se basa el marco
de calidad de PSP.
5.2 Quality Measures (métricas de calidad) – Los datos de PSP permiten la determinación de métricas de calidad de producto y del
proceso así como de la eficacia del proceso en la eliminación de defectos.
5.3 Quality Methods (Métodos de Calidad) – Las revisiones personales son una manera eficaz y efectiva de mejorar la calidad del
producto y la productividad individual. Los diversos métodos de revisión son eficaces en diversas situaciones.
5.4 PSP Code Reviews (revisiones de codigo) – Las revisiones de código deben seguir un proceso definido y usar checklists (listas de
verificación) basados en los datos de defectos personales. La consistencia en el seguimiento de una estrategia de revisión basada en
la experiencia puede hacer las revisiones más eficientes y eficaces.
5.5 PSP Design Reviews (revisiones de diseño) – Las revisiones de diseño deben seguir un proceso definido de revisión incluyendo
análisis de diseño apropiado y usando checklists (listas de verificación) basados en principios de diseño sólidos. La consistencia en el
seguimiento de una estrategia de revisión basada en experiencia medida, puede hacer revisiones más eficientes y eficaces.
5.6 Review Issues (asuntos de revisiones) – Las revisiones pueden ser muy eficaces si se conducen usando directrices basadas en
experiencia extensa y cuantitativa.
Knowledge Area 5.1: PSP Quality Principles (principios de calidad)
Esta área de conocimiento enuncia los principios sobre los que se basa el marco de calidad de PSP.

26
5.1.1 Personal responsibility (responsabilidad personal)
Para construir productos de calidad, los individuos deben sentirse personalmente responsables de la calidad de sus productos (ver 7.3).
Para construir productos de calidad consistentemente, los individuos deben ser disciplinados en el desarrollo y seguimiento de planes,
en el seguimiento y la gestión de su tiempo personal, y mantener la calidad como la máxima prioridad.
5.1.2 The economics of quality (la economía de la calidad)
• Es menos costoso encontrar y corregir los defectos antes en un proceso, que después.
• Cuanto más tiempo permanece un defecto en un producto, mayor será el costo para extraerlo.
• Las pruebas son una manera ineficiente e ineficaz para eliminar defectos.
• Es más eficiente prevenir los defectos que encontrarlos y corregirlos
• La manera correcta es siempre la manera más rápida y más barata de producir un resultado de alta calidad.
• Las revisiones son fundamentalmente más eficientes que las pruebas para encontrar y corregir defectos.
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 mínimo de funcionalidad y utilidad. El
producto también debe satisfacer las expectativas del usuario con respecto a algunos otros criterios.
• El producto debe funcionar, es decir, desempeñarse con una coherencia razonable. Si este objetivo no se logra, nada más
importa. Inquietudes adicionales de los usuarios podrían incluir
o rendimiento
o seguridad
o invulnerabilidad
o usabilidad
o funcionalidad
• El producto debe proporcionar la funcionalidad que el usuario necesita y en el momento que la necesita. En muchos proyectos
de desarrollo, la percepción de calidad de los usuarios es con frecuencia pasada por alto ya que los individuos pasan la mayor
parte de su tiempo encontrando y eliminando los defectos.
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 consistentemente
• ser utilizable y eficiente
• ser fácil de aprender y adaptarse a las nuevas circunstancias
Knowledge Area 5.2: Quality Measures (métricas de calidad)
Los datos de PSP permiten la determinación de métricas de calidad de producto y del proceso así como de la eficacia del proceso en la
eliminación 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 análisis de estos datos proporciona un
recurso valioso para la construcción de Listas de verificación (checklists) personales de revisión.
5.2.2 To-date defects injected and removed (defectos insertados y removidos a la fecha)
Los defectos insertados y removidos a la fecha son la suma de los defectos reales inyectados y removidos para cada fase del proyecto,
más los defectos insertados y removidos a la fecha por fase de los proyectos históricos.
5.2.3 To-date percent defects injected and to-date percent defects removed (porcentaje de defectos inyectados a la fecha y
porcentaje de defectos removidos a la fecha)
El porcentaje de defectos insertados a la fecha es el porcentaje de defectos insertados a la fecha en cada fase. El porcentaje de defectos
removidos a la fecha es el porcentaje de defectos removidos a la fecha 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. La métrica de yield se puede
calcular para cualquier fase o grupo de fases.
5.2.5 Phase Yield (yield (rendimiento) de fase)
Yield de fase es el porcentaje de defectos removidos durante una fase.
5.2.6 Process Yield (yield (rendimiento) del proceso)
Yield del proceso es el porcentaje de defectos removidos antes de entrar en la fase de compilación (o antes de entrar a pruebas de
unidad si no hay fase de compilación).
5.2.7 Review Yield (yield (rendimiento) de revisión)
Yield de revisión es el porcentaje de defectos en el programa encontrados durante la revisión.

27
5.2.8 Percent appraisal cost of quality (COQ) (Porcentaje de costo de evaluación de la calidad COQ)
Porcentaje de costo de evaluación de la calidad COQ es el porcentaje de tiempo de desarrollo empleado en revisión de diseño y de
código.
5.2.9 Percent failure COQ (Porcentaje de fallas COQ)
Porcentaje de fallas COQ es el porcentaje de tiempo de desarrollo empleado en compilar y probar.
5.2.10 Cost of Quality (COQ) (Costo de la Calidad)
Costo de la calidad es el porcentaje de tiempo dedicado a realizar tareas de evaluación y corrección. COQ define los asuntos relativos a
la calidad en términos de gerencia y del negocio. Las principales métricas de COQ son:
• performance costs: los costos de hacer el trabajo en primer lugar
• appraisal costs: el costo de examinar un producto para determinar su calidad
• failure costs: los costos de la corrección de un producto defectuoso, incluyendo todos los costos derivados de las deficiencias
del producto.
• prevention costs: los costos de la elaboración e implementación de acciones para prevenir fallas
5.2.11 COQ appraisal to failure ratio (COQ A/FR) (COQ relación de evaluación / fallas)
COQ A/FR es la proporción de tiempo invertido en tareas de evaluación con respecto al tiempo invertido en tareas de corrección de fallas.
5.2.12 Defect Density (densidad de defectos)
Densidad de defectos es el número de defectos detectados por medida de tamaño. Se normaliza al tamaño del producto para permitir
la comparación de diversos productos y procesos que los construyeron.
5.2.13 Process Quality Index (PQI) (índice de calidad del proceso)
El índice de calidad del proceso (PQI) es una métrica derivada que caracteriza la calidad de un proceso de desarrollo del software. El
valor de PQI es el producto de cinco valores de componentes de perfil de la calidad.
1. Calidad de diseño se expresa como la proporción del tiempo de diseño entre el tiempo de codificación.
2. Calidad de revisión del diseño es la proporción de tiempo de revisión de diseño entre el tiempo de diseño.
3. Calidad de revisión de código es la proporción del tiempo de revisión de código entre el tiempo de codificación.
4. Calidad de codificación es la proporción de defectos de compilación entre medida de tamaño.
5. Calidad del programa es la proporción de defectos en pruebas de unidad entre una medida de tamaño.
Los componentes PQI se normalizan a [0, 1] tal que el cero representa una mala práctica y el uno representa la práctica deseada. Las
proporciones se representan en los ejes de un pentágono con la escala [0, 1]. El polígono resultante puede ser comparado con el
pentágono que lo contiene para determinar la calidad del proceso. Los valores recomendados para cada componente PQI son los
siguientes.
• Calidad del diseño es el mínimo de 1,0 o el tiempo empleado en hacer diseño detallado, dividido entre el tiempo empleado en
codificación.
• Calidad de revisión de diseño es el mínimo de 1,0 o dos veces el tiempo empleado en la revisión del diseño detallado dividido
entre el tiempo empleado en el diseño detallado.
• Calidad de revisión de Código es el mínimo de 1,0 o dos veces el tiempo empleado en la revisión de código dividido entre el
tiempo empleado en la codificación.
• Calidad de la revisión de código es el mínimo de 1,0 o dos veces el tiempo empleado en la revisión de código dividido por el
tiempo empleado en la codificación.
• Calidad del código es el mínimo de 1,0 o 20/(10 + Defectos/KLOC en compilación).
• Calidad del programa es el mínimo de 1,0 o 10/(5 + Defectos/ KLOC en pruebas de unidad).
5.2.14 Calculating values for the PQI components (Cálculo de los valores de los componentes PQI)
Para calcular e interpretar los valores PQI:
• Multiplicar las cinco métricas de elementos PQI juntas para dar un número entre 0,0 y 1,0.
• Los valores inferiores a 0,5 indican que el producto es probable que sea de mala calidad. Cuanto menor sea el valor, más
pobre probablemente será la calidad.
5.2.15 Composite PQI (PQI Compuesto)
Una métrica PQI compuesta representa la calidad del proceso global para un proyecto que construyó múltiples programas. Este PQI
compuesto se puede calcular de tres formas, cada uno de los cuales tiene ventajas y desventajas.
1. La métrica del PQI del producto se calcula tomando el producto de todos los PQI de los componentes del programa.
a. Ventaja: Esta medida indicará rápidamente que un producto tiene componentes con valores bajos de PQI
b. Desventaja: Para grandes sistemas, los valores tienden a ser demasiado bajos para ser útiles en la gestión de calidad del
sistema.
2. La métrica de PQI general se determina mediante el uso de todos los valores para la totalidad de los programas, para calcular
los valores de los componentes del perfil de calidad. Por ejemplo, el tiempo de revisiones sería la suma de los tiempos de

28
revisión para todos los elementos de programa y los defectos de pruebas de unidad serían la densidad total de defectos para
todos los programas combinados.
a. Ventaja: Esta métrica tiene la ventaja de ser fácil de calcular y proporcionar un indicador general de la calidad global del
producto.
b. Desventaja: Algunos pocos componentes de mala calidad podrán ser escondidos por un gran número de componentes
de alta calidad.
3. La medida mínima de PQI se calcula utilizando el valor de PQI para el componente de programa que tenga el valor de PQI
mínimo.
a. Ventaja: Esta medida tiene la ventaja de la rápida localización de cualquier componente de mala calidad.
b. Desventaja: La medida no indica nada sobre la calidad del programa general.
Puesto que no hay una mejor métrica compuesta para todos los propósitos, las métricas compuestas de PQI se deben utilizar con cuidado
y su significado debe ser explicado detalladamente.
5.2.16 Phase defect removal rate (tasa de eliminacion de defectos de fase)
Para cada fase de un proceso, la tasa de corrección de defectos de la fase es el número de defectos encontrados por hora en esa fase.
5.2.17 Review Rate (tasa de revisión)
La tasa de revisión se refiere al tamaño del producto revisado por hora. Esta tasa se calcula tanto para la fase de revisión como de
inspección (ver 5.3.3).
5.2.18 Defect-removal leverage (DLR) (Apalancamiento de eliminación de defectos)
Defect-removal leverage es una medida de la eficacia relativa de la eliminación de defectos entre dos fases cualquiera del proceso. Por
ejemplo, el DRL para la revisión del diseño con respecto a las pruebas de unidad se define como DRL (DR / UT) = defectos por hora en
revisión del diseño dividido entre defectos por hora en la prueba de la unidad.
Knowledge Area 5.3: Quality Methods (Métodos de Calidad)
Las revisiones personales son una manera eficaz y efectiva de mejorar la calidad del producto y la productividad individual. Los diversos
métodos de revisión son eficaces en diversas situaciones.
5.3.1 Personal reviews (revisiones personales)
Una revisión personal es conducida por el individuo que examina su propio producto con la meta de encontrar y de corregir tantos defectos
como sea posible. Las revisiones personales deben preceder cualquier otra actividad que utilice el producto (codificación, compilación,
prueba, inspección, etc.).
5.3.2 Personal review principles (principios de revisión personal)
Los siguientes principios deben ser seguidos cuando los individuos examinan su propio trabajo durante las revisiones personales
• Encuentre y repare todos los defectos en el trabajo.
• Use un checklist (lista de verificación) derivado de los datos personales de defectos.
• Siga un proceso estructurado de revisión.
• Siga prácticas solidas de revisión.
• Mida las revisiones.
• Use los datos para mejorar las revisiones
• Construya productos revisables.
• Utilice datos para identificar dónde y por qué se inyectan los defectos, con el objetivo de cambiar el proceso para evitar defectos
similares en el futuro.
5.3.3 Inspections (inspecciones)
Una inspección es una revisión estructurada en equipo de un componente o producto. El objeto de una inspección es identificar problemas
en el producto. Las inspecciones se conducen según un procedimiento definido en que los asistentes desempeñan roles establecidos.
En una inspección realizada correctamente, los participantes no discuten los problemas identificados ni intentan solucionarlos.
5.3.4 Walkthroughs (recorridos)
Un walkthrough es menos formal que una inspección. Un producto, como un diseño o un segmento de código, se presenta a una audiencia
que plantea posibles problemas y hace preguntas.
5.3.5 Relationship between reviews and inspections (relación entre las revisiones y las inspecciones)
Una revisión personal debe preceder a cualquier inspección. Una revisión antes de la inspección asegura que los inspectores buscan
cuestiones finas, en lugar de errores evidentes.
5.3.6 Conducting effective personal reviews (conducir revisiones personales efectivas)
Para lograr revisiones eficaces y eficientes, estas prácticas deben ser seguidas.
• Tómese un descanso entre el trabajo y la revisión.
• Haga la revisión de productos en forma impresa, y no en medios electrónicos.
• Marque cada punto cuando se vaya completando.

29
• Actualice los checklists de revisión periódicamente para reaccionar a los cambios en los datos personales.
• Construya y utilice un checklist diferente para cada método de diseño, lenguaje de programación o tipo de producto.
• Analice y verifique a conciencia cada construcción no trivial del diseño (ver 6.6).
Knowledge Area 5.4: PSP Code Reviews (revisiones de código en PSP)
Las revisiones de código deben seguir un proceso definido y usar checklists (listas de verificación) basados en los datos de defectos
personales. La consistencia en el seguimiento de una estrategia de revisión basada en la experiencia puede hacer las revisiones más
eficientes y eficaces.
5.4.1 Code review checklist (checklist de revisión de código)
Un checklist de revisión de código es específico para el proceso de codificación de un individuo. Este checklist lista las categorías de los
defectos que han causado problemas en el pasado, para que estos defectos sean verificados durante la revisión.
5.4.2 PSP code review process (proceso de revisión de código en PSP)
El proceso de la revisión de código en PSP es como sigue.
1. Obtenga el checklist de revisión de código, estándar de codificación, y estándar de defectos.
2. Imprima una copia del código para ser revisado.
3. Para cada categoría de defecto en el checklist, hacer una pasada completa sobre el código y marque cada punto a medida
que se va completando.
4. Corregir todos los defectos y comprobar cada corrección de defectos para asegurar sea correcta.
5.4.3 Code review strategy (estrategia de revisión de código)
Una estrategia de revisión deberá basarse en datos que muestran que la estrategia sea eficaz. Una estrategia inicial consiste en examinar
primero los módulos de bajo nivel de tal manera que las abstracciones procedurales sean revisadas y entendidas antes que las de más
alto nivel. Después de que una estrategia se ha determinado como eficaz, debe ser seguida consistentemente. Dependiendo del tipo de
producto y del conocimiento del individuo en su diseño, diversas estrategias de revisión pueden ser apropiadas.
5.4.4 Review against a coding standard (revisión contra un estándar de codificación)
Las revisiones de código deben verificar el cumplimiento de estándares de codificación. Los estándares aplicables de codificación deben
referenciarse en los checklist de revisión de código.
Knowledge Area 5.5: PSP Design Reviews (revisiónes de diseño PSP)
Las revisiones de diseño deben seguir un proceso definido de revisión incluyendo análisis de diseño apropiado y usando checklists (listas
de verificación) basados en principios de diseño sólidos. La consistencia en el seguimiento de una estrategia de revisión basada en
experiencia medida, puede hacer revisiones más eficientes y eficaces.
5.5.1 Design review principles (principios de revisión de diseño)
• Produzca diseños que puedan ser revisados
• Siga una estrategia de revisión explicita.
• Revise el diseño en etapas.
• Compruebe que la lógica implementa correctamente los requerimientos.
• Revise asuntos de vulnerabilidad y seguridad.
5.5.2 Design review checklist (checklist de revisión de diseño)
Un checklist de revisión de diseño es específico para el proceso de codificación de un individuo. El checklist se basa en datos de defectos
personales y lista las categorías de los defectos que han causado problemas en el pasado, para que estos defectos sean verificados
durante la revisión.
5.5.3 PSP design reviews (revisions de diseño en PSP)
El proceso de revisión del diseño en PSP es el siguiente.
1. Obtenga el checklist de revision de diseño y los estándares de diseño y de defectos.
2. Imprima una copia del diseño a ser revisado, si es pertinente.
3. Para cada categoría de defecto en la lista, hacer una pasada completa sobre el diseño y marque cada punto a medida que se
va completando.
4. Corregir todos los defectos y comprobar cada corrección de defecto para asegurar sea correcta.
5. Analice todas las construcciones complejas del diseño para verificar sean correctas (ver 6.6).
5.5.4 Design review strategy (estrategia de revisión de diseño)
Una estrategia de revisión deberá basarse en datos que muestren que la estrategia es eficaz. Después de que una estrategia ha
determinado ser eficaz, debe ser seguida consistentemente.
Knowledge Area 5.6: Review Issues (aspectos de la revision)
Las revisiones pueden ser muy eficaces si se conducen usando directrices basadas en experiencia extensa y cuantitativa.

30
5.6.1 Review efficiency (eficiencia en la revisión)
Las revisiones del diseño y de código encuentran defectos directamente, ayudando al revisor a generar una imagen mental del
comportamiento previsto del programa. En procesos de desarrollo de grandes sistemas, las revisiones del diseño y de código son
especialmente importantes porque los métodos incrementales de PSP requieren que todos los incrementos sean de alta calidad. Para
garantizar que los sistemas de gran escala alcancen la misma alta calidad que los sistemas más pequeños, los scripts de PSP deben
seguirse, y cada módulo y/o incremento debe ser sometido a revisiones de diseño, revisiones de código, y pruebas de regresión para
garantizar que los nuevos incrementos no causen problemas con módulos funcionales previamente probados y aceptados.
5.6.2 Reviewing before or after compiling (Revisar antes o después de compilar)
Muchos entornos de desarrollo utilizan analizadores automáticos de código y/o compiladores que son muy útiles, su uso no se
desincentiva. Sin embargo, para ser más eficaz, la revisión debería ser realizada antes de usar el analizador de código o el compilador.
Las revisiones de código deben realizarse antes de las pruebas.
5.6.3 Review objectives (objetivos de la revisión)
Las revisiones de código correctamente realizadas reducen perceptiblemente el tiempo de pruebas y producen resultados de alta calidad.
Si el individuo no está comprometido a construir productos de alta calidad, el proceso de revisión probablemente será ineficaz. Las
personas cuyo objetivo es comenzar a probar lo antes posible, rara vez realizan revisiones de código o las hacen tan mal que son una
pérdida de tiempo.
Competency Area 6: Software Design (Diseño de Software)
El área de competencia de diseño de software describe la capacidad de incorporar el diseño y las actividades de verificación de diseño
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 (Principios de diseño de Software) – Esta área de conocimiento se describen los principios de diseño
de software incorporados en PSP.
6.2 Design Strategies (Estrategias de Diseño) – Esta área de conocimiento aborda las estrategias de diseño utilizadas en PSP.
6.3 Design Quality (Calidad en el Diseño) – Esta área de conocimiento describe las características clave que se pueden utilizar para
evaluar la calidad de un diseño de software.
6.4 Design Documentation (Documentación del Diseño) – Los diseños de software se deben documentar, junto con los requerimientos
relacionados, las limitaciones, y las justificaciones. Esta área de conocimiento describe la documentación de diseño que es
responsabilidad de la persona.
6.5 Design Templates (Plantillas de Diseño) – El PSP no especifica técnicas de diseño, pero proporciona a un conjunto de plantillas
como marco para la documentación del diseño. Las plantillas ayudan a asegurar que un sistema y sus módulos están completa y
precisamente implementados.
6.6 Design Verification (Verificación del Diseño) – Para ser eficaz, la revisión de diseño debe ir más allá de la simple lectura a través
de un documento de diseño. El PSP ofrece una serie de técnicas de verificación de diseño que pueden ser utilizadas para identificar los
errores y omisiones en los diseños de software.
Knowledge Area 6.1: Software Design Principles (Principios de diseño de Software)
Esta área de conocimiento describe los principios de diseño de software incorporado en PSP.
6.1.1 Definition of software design (Definición de Diseño de Software)
Un diseño de software transforma un requerimiento débilmente definido en una especificación de producto realizable.
6.1.2 The design process (El proceso de diseño)
Un proceso de diseño es el conjunto de pasos que se utilizan dentro de una metodología para crear un diseño. El proceso de diseño
debe dar lugar a una visión global de la solución del requerimiento, que es clarificada con los detalles de bajo nivel de la implementación.
No construye la solución sino explora el espacio de solución 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 role del diseño dentro del proceso general de
desarrollo de Software)
El diseño de software conecta los requisitos de un sistema a su implementación. Con el uso apropiado de la abstracción, 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” (El “principio de incertidumbre del diseño”)
Debido a que un nuevo sistema afecta a los usuarios y cambia sus necesidades, los requisitos para un sistema informático a menudo no
se conocen completamente hasta después que el producto terminado se pone en uso. El proceso de diseño debe proporcionar a una
base estable para esta evolución continua.
6.1.5 The role of design in PSP (El rol de diseño en PSP)
Los componentes bien diseñados son críticos para el éxito de los sistemas más grandes que los usan. Los individuos deben emplear
prácticas de diseño que puedan satisfacer las exigencias de la compleja y dinámica evolución de los sistemas.

31
6.1.6 Design methodology in PSP (Metodología de Diseño en PSP)
El PSP no prescribe el uso de alguna metodología específica de diseño, pero sí define los requisitos para la documentación de diseño.
6.1.7 Design specification structure (Estructura de la epecificación de diseño)
Los elementos de un diseño completo se pueden especificar usando la siguiente estructura de especificación.
• externa- estática (herencia, estructura de clases)
• externa- dinámica (servicios, mensajes)
• interna-estática (atributos, estructura del programa, lógica)
• interna-dinámica (máquina de estado)
6.1.8 Need for design precision (Necesidad de la precisión en el diseño)
Una especificación de diseño debe ser precisa. La falta de un diseño preciso es la fuente de muchos errores de implementación. Para
obtener mejor precisión del diseño, especifique y documente las decisiones de diseño antes de entrar a la fase de codificación del
proceso.
Knowledge Area 6.2: Design Strategies (Estrategias de Diseño)
Esta área de conocimiento aborda las estrategias de diseño utilizadas en PSP.
6.2.1 The need for design strategies (La necesidad de estrategias de diseño)
El diseño es un proceso intelectual complejo que no puede ser automatizado, reducido a un procedimiento rutinario, o precisamente
controlado ni pronosticado; sin embargo, algunas guías y estrategias pueden ser aprovechadas en la separación de actividades rutinarias
y creativas, para asegurarse de que el trabajo de diseño es realizado correctamente y para identificar herramientas y métodos de diseño
eficaces.
6.2.2 Nature of the design process (Naturaleza del proceso de diseño)
El diseño es un proceso de aprendizaje que requiere comúnmente moverse entre niveles de diseño y de una parte del sistema a otra.
6.2.3 Design process guidelines (Guías del proceso de diseño)
• Cuando sea práctico, termine los diseños de alto nivel primero.
• Registrar todos los supuestos, cuestiones pendientes, preguntas y problemas.
• Cuando sea apropiado, use prototipos o experimentación para reducir la incertidumbre antes de diseñar.
• No considere un diseño como terminado hasta que los diseños de todos los componentes interdependientes también se
terminen.
• Documente todo el diseño (ver 6.6).
6.2.4 Types of design strategies (Tipos de estrategias de diseño)
Las estrategias de diseño pueden incluir las siguientes:
• Progresiva (progressive)
• Expansión funcional (Functional enhancement)
• Camino Rápido (fast-path)
• Simulación (dummy)
Knowledge Area 6.3: Design Quality (Calidad en el Diseño)
Esta área de conocimiento describe las características clave que se pueden utilizar para evaluar la calidad de un diseño de software.
6.3.1 Design precision (Precisión del Diseño)
Los diseños deben ser consistentes y sin ambigüedades. El diseño debe contener suficiente detalle para todos los usos previstos de la
documentación de diseño.
6.3.2 Design completeness (Completitud del Diseño)
• Todos los detalles relevantes deben ser incluidos, sin redundancia innecesaria.

32
• La documentación de diseño no debe limitarse a los diseños de componentes individuales, sino que también debería
documentar el sistema en su conjunto y las consideraciones emergentes.
• Es útil incluir la justificación de las decisiones de diseño; es a menudo provechoso documentar las alternativas que no fueron
elegidas.
6.3.3 Design usability (Usabilidad del diseño)
El diseño debe ser accesible y comprensible por todos sus usuarios.
Knowledge Area 6.4: Design Documentation (Documentación del Diseño)
Los diseños de software se deben documentar, junto con los requerimientos relacionados, las limitaciones, y las justificaciones. Esta área
de conocimiento describe la documentación de diseño que es responsabilidad de la persona.
6.4.1 The need for software design documentation (La necesidad de documentar el diseño)
Los diseños de software se deben documentar, junto con los requerimientos relacionados, las limitaciones, y las justificaciones, debido
a que el diseño, a menos de que se trate de programas pequeños, es necesario para las personas que estarán involucradas con los
productos consiguientes. Algunos ejemplos a continuación.
• El individuo: para facilitar implementación, verificación, prueba del programa
• Los miembros del equipo: para permitir las inspecciones de diseño y la coordinación de diseño
• Testers: para permitir la planeación de las pruebas.
• Administradores: para facilitar la ampliación y las correcciones del producto
• Documentadores y usuarios: para que otros puedan entender lo que el producto hace y cómo funciona
6.4.2 Overall design documentation concerns (Preocupaciones generales sobre la documentación del diseño)
Para garantizar que la documentación de diseño siga representando el producto, la documentación de diseño debe ser auto consistente,
y los cambios deben ser administrados y debidamente documentados.
6.4.3 Common types of design documentation (Tipos comunes de documentación del diseño)
El individuo produce documentación de diseño que cubre
• el contexto del programa
• la estructura del programa
• componentes relacionados
• variables externas, llamadas y referencias
• descripción detallada de la lógica de programación para las decisiones de diseño, es a menudo provechoso documentar las
alternativas que no fueron elegidas
6.4.4 Design visibility (Visibilidad del diseño)
La documentación del diseño proporciona la representación visible de un diseño, usada para las revisiones y verificaciones. El diseño se
registra usando una notación apropiada de diseño (ver 6.5.1).
6.4.5 Design documentation practice (Practica de documentación del diseño)
Una práctica útil en la implementación de un diseño es comenzar con el diseño del programa completo y conforme cada sección del
diseño es implementada, encapsular ese segmento de diseño en un comentario inmediatamente antes de la implementación.
Knowledge Area 6.5: Design Templates (Plantillas de Diseño)
El PSP no especifica técnicas de diseño, pero proporciona a un conjunto de plantillas como marco para la documentación del diseño.
Las plantillas ayudan a asegurar que un sistema y sus módulos están completa y precisamente implementados.
6.5.1 Design notation (Notación de diseño)
Una notación basada en lógica matemática puede ayudar en la generación de documentación de diseño, concisa y sin ambigüedades.
Ejemplos de ello son seudocódigo y Zed. Los siguientes criterios deben seguirse cuando se selecciona una notación de diseño adecuada.
• La notación de diseño debe ser capaz de representar de manera precisa y completa el diseño.
• Debe ser comprensible y útil para la gente que va a usar y/o implementar el diseño.
• Debe ayudar a los diseñadores para producir un diseño de alta calidad.
• Debe ser compatible con el lenguaje de implementación que se utilizará.
• Debe permitir rangos variables de dependencia en la implementación
6.5.2 PSP design templates (Pantillas de diseño)
Las plantillas de diseño de PSP representan la estructura estática y el comportamiento dinámico de un sistema informático, capturando
tanto las características externamente visibles como los detalles internos (ver 6.1.6). Un diseño completo en PSP debería contener las
siguientes cuatro categorías o elementos de diseño-
• externa-dinámica: Use la plantilla de especificación operacional (OST) y la plantilla de especificación funcional (FST) para
registrar esta información (ver 6.5.3 y 6.5.4).
• externa-estática: Use la plantilla de especificación funcional (FST) para registrar esta información (ver 6.5.4).

33
• interna-dinámica: Use la plantilla de especificación de estados (SST) para registrar esta información (ver 6.5.5).
• interna-estática: Use la plantilla de especificación lógica (LST) para registrar esta información (ver 6.5.6).
6.5.3 Operational specification template (OST) (Plantilla de especificación operacional - OST)
El OST documenta las características externa-dinámicas de una parte de un sistema informático. Describe uno o más escenarios que
involucran a la parte y los actores (ej. usuarios de otros sistema) que interactúan con ella. Cada OST tiene un identificador único, un
usuario meta, y un escenario meta. Para cada paso en un escenario, la OST lista los siguientes elementos.
• la fuente (sistema o actor especifico)
• numero de paso
• acción
• comentarios
6.5.4 Functional specification template (FST) (Plantilla de especificación funcional - FST)
El FST documenta una parte (ej. una clase) de un sistema de software, sus relaciones externa-estáticas, y sus atributos externos visibles.
El FST también documenta las características externas-dinámicas de una parte. Describe las acciones (ej., métodos de una clase) que
la parte pone disponibles para uso externo, esta descripción incluye la interfaz definida para cada acción, incluyendo argumentos,
restricciones y resultados devueltos.
6.5.5 State specification template (SST) (Plantilla de especificación de estados SST)
El SST documenta el comportamiento interno-dinámico de un sistema de software y de sus partes (ej., clases) cuando el comportamiento
es representado como un conjunto de estados, transiciones entre los estados, y acciones asociadas a las transiciones. El SST puede
complementarse con un diagrama de estados separado, que represente gráficamente los estados, las condiciones de la transición, y las
acciones. Un SST contiene
• nombre y descripción de los estados
• las funciones y los parámetros internos usados en la condiciones de transición
• detalles de la transición de estados
o estado actual
o estado siguiente
o condición de transición (predicado)
o acción que se realiza cuando ocurre la transición
6.5.6 Logic specification template (LST) (Plantilla de especificación lógica - LST)
El LST documenta las características interno-estáticas de una parte de un sistema de software. Describe la lógica interna de la parte,
usando pseudocódigo para explicar clara y concisamente su operación. Considere que la información del LST puede estar embebida
como comentarios en el código fuente del programa en lugar de utilizar un formato separado, siempre y cuando sea clara y
suficientemente detallada.
6.5.7 Template usage (Uso de la plantillas)
Las plantillas de diseño PSP pueden ser
• utilizadas para documentar un diseño producido a partir de diferentes técnicas de diseño
• utilizadas para documentar el diseño de un sistema de software existente, para apoyar su rediseño o verificación
• complementadas o sustituidas parcialmente por otras técnicas de documentación de diseño (ej. UML), siempre y cuando
información equivalente del diseño se registre en un formato fácilmente usable
• aplicado en diversos niveles de la jerarquía del diseño
Knowledge Area 6.6: Design Verification (Verificación del Diseño)
Para ser eficaz, la revisión de diseño debe ir más allá de la simple lectura a través de un documento de diseño. El PSP ofrece una serie
de técnicas de verificación de diseño que pueden ser utilizadas para identificar los errores y omisiones en los diseños de software.
6.6.1 Design standards (Estándares de diseño)
Los diseños de software se pueden verificar contra estándares que promuevan consistencia y calidad. Estos estándares pueden incluir
• convenciones de producto
• estándares de diseño de producto
• estándares de re-uso
6.6.2 Verification methods (Métodos de verificación)
Los métodos de verificación de software incluyen:
• verificación con tabla de ejecución
• verificación con tabla de rastreo
• verificación de máquina de estados
• verificación de ciclos
• otros métodos analíticos de verificación

34
6.6.3 Choosing the appropriate design verification method (Selección del método de verificación adecuado)
• Analice sus datos personales de defectos para determinar qué aspectos de diseño son más propensos a defectos. No es un
uso prudente del tiempo verificar aspectos de diseño donde se cometen pocos (o ningún) defectos.
• Evaluar la eficacia de los métodos de verificación actuales. Identificar un conjunto de técnicas eficaces y usarlas, incluso en
programas pequeños.
• Considere la economía de las técnicas de verificación actuales. Elija los métodos de verificación que sean más eficaces
personalmente y que apliquen mejor a las condiciones del diseño.
6.6.4 Using execution table verification (Uso de verificación con la tabla de ejecución)
• Identificar ciclos y rutinas complejas para la verificación.
• Elija la orden del análisis (ej. de arriba a abajo o de abajo para arriba).
• Construya una tabla de ejecución con los pasos del programa y valores relevantes de las variables, usando múltiples copias
para iteraciones de ciclos.
• Verificar los resultados de la ejecución con respecto a la especificación de requerimientos.
6.6.5 Using trace-table verification (Uso de verificación con la tabla de rastreo)
• Identifique los casos lógicos representativos para el análisis.
• Para cada caso lógico, verifique usando una tabla de ejecución.
6.6.6 Execution table verification vs. trace-table verification (Verificación con tabla de ejecución vs. Verificación con tabla de
rastreo)
Distinga entre la verificación con tabla de ejecución y verificación con tabla de rastreo, y sepa cuando utilizar cada una.
6.6.7 Using state-machine verification (Uso de la verificación de la máquina de estados)
• Revise la estructura de la máquina de estados para asegurarse que no tiene trampas o ciclos ocultos, usando un diagrama de
estado, si es práctico
• Examine cada estado y verifique que el conjunto de transiciones de ese estado es completo (definido para todos los posibles
valores de condiciones de transición).
• Examine cada estado y verifique que las transiciones asociadas del estado son ortogonales (solamente una transición definida
para cada conjunto de valores de la condición de la transición).
6.6.8 Using loop verification (Uso de la verificación de ciclos)
Verificar el inicio de ciclos, incremento, y terminación, utilizando los métodos de verificación apropiados al tipo de ciclo
• Verificación de ciclos for
• Verificación de ciclos while
• Verificación de ciclos repeat-until
Competency Area 7: Process Extensions and Customization (Extensión y adaptación del proceso)
El área de conocimiento extensión y adaptación del proceso describe las modificaciones al PSP que son requeridas cuando se escala
de pequeños a más grandes programas, al trabajar con situaciones o ambientes desconocidos, o al moverse al desarrollo basado en
equipo en lugar del trabajo en solitario. Las áreas de conocimiento principales que componen esta área de competencia son las
siguientes.
7.1 Defining a Customized Personal Process (Definiendo un proceso personal adaptado) – Un proceso definido no debe ser
considerado como “una solo talla que le queda a 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 (Evolución del Proceso) – Un proceso no se puede evolucionar para cubrir necesidades o situaciones
cambiantes hasta que el proceso actual represente exactamente lo que realmente se hace al usar ese proceso. Esta área de
conocimiento se refiere a las actividades relacionadas con la evolución incremental de un proceso inicial a uno que es una descripción
exacta y completa del proceso real.
7.3 Professional Responsibility (Responsabilidad profesional) – El trabajo excepcional requiere comportamiento responsable de
parte de un profesional. Esta área del conocimiento describe algunas de las prácticas de profesionales responsables.
Knowledge Area 7.1: Defining a Customized Personal Process (Definiendo un proceso personal adaptado)
Un proceso definido no debe ser considerado como “una solo talla que le queda a 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 customized process (Cuando definer un proceso nuevo o adaptado)
Diferentes situaciones requieren diferentes métodos: lo que funciona bien en un ambiente puede no ser eficaz en otro. Por ejemplo, las
tareas de programación simple pueden requerir poco o nada de tiempo de diseño. Sin embargo, sistemas más grandes o sistemas de
alta seguridad (independientemente de su tamaño), requieren un diseño robusto. Un proceso sin una etapa de diseño puede requerir
adecuación para incluir esta actividad a la hora de adaptar un proceso existente para cubrir una nueva situación, cuando la escalabilidad
del proceso cambia o los requerimientos de seguridad cambian.

35
7.1.2 How to define a new or customized process (Como definir un proceso nuevo o adaptado)
La definición de un proceso personal nuevo o la adaptación sigue los mismos principios que para el desarrollo de software: comenzar
con las necesidades del usuario y terminar con la prueba final y la liberación. Hay ocho pasos generales para la adaptación o la creación
de un proceso personal.
1. Determinar las necesidades y prioridades.
2. Definir los objetivos del proceso, las metas y los criterios de calidad.
3. Caracterizar el proceso actual.
4. Caracterizar el proceso esperado.
5. Establecer una estrategia de desarrollo de proceso.
6. Definir el proceso inicial.
7. Validar el proceso inicial.
8. Mejorar el proceso.
7.1.3 Using information mapping for documenting a new or customized process (Usando el mapero de la información para
documentar un proceso nuevo o adatpar un proceso)
Al adaptar un proceso existente (o desarrollo de scripts y formatos a partir de cero), siga los siguientes principios de mapeo de información
[Horn 90].
• Chunking (particionar): Organizar la información en grupos que son administrables para leer o realizar.
• Relevance (relevancia): Agrupar elementos que “se parecen” y excluir elementos no relacionados de cada parte.
• Labeling (etiquetamiento): Proveer a los usuarios con una etiqueta para cada parte de información.
• Consistency (consistencia): Use términos consistentes entre cada parte de la información, entre la parte y la etiqueta, en la
organización de la información y al definir el formato del documento o instrumento en el que la información es registrada.
• Integrate graphics (integrar gráficas): Usar tablas, ilustraciones y diagramas, como parte integral de la documentación.
• Accessible detail (detalle accesible): Escribir al nivel de detalle que haga el documento sea útil para todos los lectores.
• Hierarchy of chunking and labeling (Jerarquía de Etiquetamiento y particionamiento): Agrupar pequeñas partes en un elemento
relevante y dar a cada grupo una etiqueta.
Knowledge Area 7.2: Process Evolution (Evolución del Proceso)
Un proceso no se puede evolucionar para cubrir necesidades o situaciones cambiantes hasta que el proceso actual represente
exactamente lo que realmente se hace al usar ese proceso. Esta área de conocimiento se refiere a las actividades relacionadas con la
evolución incremental de un proceso inicial a uno que es una descripción exacta y completa del proceso real.
7.2.1 Initial process definition (Definición Inicial del proceso)
Las descripciones de proceso iniciales raramente son exactas, debido a un fenómeno análogo al principio de incertidumbre de
Heisenberg: el acto de definir un proceso cambia ese proceso. La descripción inicial del proceso contiene generalmente omisiones,
idealizaciones, y otras inexactitudes. El proceso de describir exactamente lo que realmente sucede, a menudo afecta al proceso durante
el acto mismo de definirlo.
7.2.2 Refining a personal process (Refinando un proceso personal)
1. Comenzar con una caracterización del proceso como se utilizan actualmente.
2. Definir el proceso objetivo o el ideal.
3. Definir los pasos necesarios para avanzar del proceso actual al proceso ideal.
4. Desarrollar los scripts necesarios, formas, estándares y métricas para el uso del proceso.
5. Revisar el proceso, ya que se está aplicando y corregir los errores identificados u omisiones.
Knowledge Area 7.3: Professional Responsibility (Responsabilidad profesional)
El trabajo excepcional requiere comportamiento responsable de parte de un profesional. Esta área del conocimiento describe algunas de
las prácticas de profesionales responsables.
7.3.1 Use effective methods in your work (Uso de métodos efectivos en el trabajo)
Las buenas prácticas son sencillas, pero muy pocas personas las utilizan consistentemente. El profesional dedicado encuentra métodos
efectivos para producir consistentemente trabajo de alta calidad y usa esos métodos.
7.3.2 Use data to discover your strengths and weaknesses (Uso de datos para descubrir sus debilidades y fortalezas)
Utilice el análisis post mortem de los datos personales para construir una comprensión de lo que se hace bien y de las áreas donde se
necesita mejorar. Céntrese en llevar a cabo pequeñas mejoras regularmente, y los cambios importantes vendrán por si solos.
7.3.3 Practice (Práctica)
La clave para mejorar la calidad del trabajo es practicar las habilidades en el trabajo en la mayor forma posible.

36
7.3.4 Learn from others, and pass on what you know (Aprenda de otros y enseñe lo que sabe)
Hable con sus colegas y revise la literatura para aprender nuevas técnicas y aprender de los errores de otros. A medida que aprenda,
comparta lo que ha aprendido con los demás. Saque provecho de los beneficios obtenidos y contribuya con lo que ha aprendido.
7.3.5 Find and learn new methods (Encuentre y aprenda nuevos métodos)
Esté atento a las innovaciones que sean pertinentes a sus necesidades personales. Asigne tiempo en su agenda para desarrollar sus
habilidades siempre que sea posible. Al mantenerse al día, el empleado se hace más atractivo para su empleador actual (y para los
futuros empleadores) como un profesional competente y deseable.

Pspbok español-2.0

Más contenido relacionado

Similar a Pspbok español-2.0 (20)

Último (20)

Pspbok español-2.0