PSPBOK - EspaÃ Ol-2.0

1
El Proceso Personal de SoftwareSM (PSPSM)

Cuerpo de Conocimiento, Versin 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.
Contenido
Competency Area 1: Foundational Knowledge (Fundamentos del Conocimiento) .................................................................................... 8
1.1 Process Definition (Definicin del Proceso) ..................................................................................................................................... 8
1.2 Process Elements (Elementos del Proceso) .................................................................................................................................... 8
1.3 Measurement Principles (Principios de Medicin) ........................................................................................................................... 8
1.4 Statistical Elements (Elementos de Estadstica) .............................................................................................................................. 8
Knowledge Area 1.1: Process Definition (Definicin 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 (Documentacin 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 (Patrn 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 (adaptacin de procesos)............................................................................................................................. 9
1.1.12 Process building and refining (definicin 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 (mtricas) ................................................................................................................................................................. 9
1.2.5 Standards (estndares) ............................................................................................................................................................ 9
Knowledge Area 1.3: Measurement Principles (Principios de medicin) ............................................................................................... 9
1.3.1 The need for measures (la necesidad de usar mtricas) ......................................................................................................... 10
1.3.2 Measurement types (tipos de mtricas) .................................................................................................................................. 10
1.3.3 Defined measures (mtricas definidas) ................................................................................................................................... 10
1.3.4 Precise and accurate measures (Mtricas precisas y exactas) ............................................................................................... 10
1.3.5 Meaningful measures (Mtricas significativas) ........................................................................................................................ 10
1.3.6 Uses of process measures (usos de las mtricas de proceso) ................................................................................................ 10
Knowledge Area 1.4: Statistical Elements (Elementos de Estadstica) ................................................................................................ 10
1.4.1 Distributions (distribucin) ....................................................................................................................................................... 10
1.4.2 Mean (Media) ......................................................................................................................................................................... 10
1.4.3 Variance (Varianza) ................................................................................................................................................................ 10
1.4.4 Standard deviation (Desviacin estndar) .............................................................................................................................. 10
1.4.5 Correlation (correlacin) ......................................................................................................................................................... 10
1.4.6 Significance of a correlation (Significancia de una correlacin) ............................................................................................... 10
1.4.7 Linear regression (Regresion Lineal) ...................................................................................................................................... 10
1.4.8 Prediction interval (Intervalo de prediccin) ............................................................................................................................ 11
1.4.9 Multiple regression (regression multiple) ................................................................................................................................. 11
1.4.10 Standard normal distribution (distribucin normal estndar) .................................................................................................. 11
1.4.11 Log-normal distribution (Distribucin logartmica normal) ...................................................................................................... 11
1.4.12 Degrees of freedom (Grados de libertad) .............................................................................................................................. 11
1.4.13 The t-distribution (la distribucin 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 planeacin) ....................................................................................... 12
Copyright Carnegie Mellon University.

Traduccin NO oficial para uso interno
Traduccin Inicial: Alexander Narvaez @narvaezberrio
Revisin y Actualizacin: SEONTI
3
2.1.5 Process fidelity and performance improvement (Adherencia al proceso y mejora del desempeo) ......................................... 12
Knowledge Area 2.2: Data Collection (Recoleccin de datos) ............................................................................................................. 12
2.2.1 Collecting data (recopilacin de datos) ................................................................................................................................... 12
2.2.2 Collecting useful data (Recoleccin de datos tiles) .............................................................................................................. 12
2.2.3 Collecting high-quality data (recopilacin 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 planificacin) ........................................................................ 12
Knowledge Area 2.3: Data Measures ................................................................................................................................................. 13
2.3.1 Basic PSP measures (Mtricas Bsicas de PSP) .................................................................................................................. 13
2.3.2 Time measures (Metricas de Tiempo) ..................................................................................................................................... 13
2.3.3 Size measures (mtricas de tamao) ...................................................................................................................................... 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 (mtricas de calendario) ......................................................................................................................... 13
2.3.7 Derived measures (mtricas derivadas) ................................................................................................................................. 14
Knowledge Area 2.4: Data Analysis (anlisis de datos) ...................................................................................................................... 14
2.4.1 Measurement framework and data analysis (marco de medicin y anlisis de datos) ............................................................. 14
2.4.2 Postmortem ............................................................................................................................................................................ 14
2.4.3 Performance measures (mtricas de desempeo) .................................................................................................................. 14
2.4.4 Performance baselines (lneas base de desempeo) .............................................................................................................. 14
2.4.5 Combined measures (mtricas combinadas) .......................................................................................................................... 14
2.4.6 Analyzing historical data (anlisis de datos histricos) ............................................................................................................ 14
2.4.7 Analyzing size-estimating accuracy (Anlisis de la precisin de la estimacin del tamao) ................................................... 14
2.4.8 Analyzing effort-estimating accuracy....................................................................................................................................... 14
2.4.9 Analyzing size and time relationships (anlisis entre la relacin de tamao 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 (Justificacin de la mejora de procesos) .......................................................................... 15
2.5.2 Scope for process improvement (mbito de aplicacin 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 histricos ......... 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 ms alto valor) ....................................... 16
2.5.7 Measure process changes (Mtricas de Cambios de proceso) ............................................................................................... 16
2.5.8 Monitor performance results (Monitor de resultados de desempeo) ...................................................................................... 16
2.5.9 Watch for improvement opportunities (Estar atento a las oportunidades de mejora) ............................................................... 16
Competency Area 3: Size Measuring and Estimating (Medicin del tamao y estimacin) .................................................................... 16
Knowledge Area 3.1: Size Measures (mtricas de tamao) ............................................................................................................... 17
3.1.1 Rationale for using size measures (Justificacin para el uso de medidas de tamao) ............................................................. 17
3.1.2 Types of measures (tipos de mtricas) ................................................................................................................................... 17
3.1.3 Criteria for size measures (Criterios para las mtricas de tamao) ......................................................................................... 17
3.1.4 Counting standards (estndares de conteo)........................................................................................................................... 17
3.1.5 Physical and logical size (tamao fsico y lgico) .................................................................................................................... 17
3.1.6 Size accounting (conteo de tamao) ....................................................................................................................................... 17
3.1.7 Using the size measure selection procedure (Uso del procedimiento de seleccin de la mtrica) .......................................... 17
Knowledge Area 3.2: Size Data (datos de tamao) ............................................................................................................................ 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 tamao son tiles para el seguimiento del esfuerzo de
desarrollo) ....................................................................................................................................................................................... 18
3.2.3 Size data help in assessing program quality (los datos de tamao ayudan a evaluar la calidad del programa) ....................... 18
Knowledge Area 3.3: Size Estimating Principles (principios de estimacin de tamao) ...................................................................... 18
4
3.3.1 Estimating is uncertain (la estimacin es incierta) ................................................................................................................... 18
3.3.2 Estimating is a learning process (la estimacin 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 mtodos definidos para hacer estimaciones) .......................................... 18
3.3.6 Estimates are subject to error (Las estimaciones estn sujetas a error) .................................................................................. 18
3.3.7 Estimate in detail (Estimacin a detalle).................................................................................................................................. 18
3.3.8 Use historical data to make estimates (utilizar datos histricos 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 mtrica de tamao) .............................................. 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 tamaos relativos) .............................................................................................. 19
3.4.4 Building a relative size table (construyendo tablas de tamaos relativos) ............................................................................... 19
3.4.5 Building a relative size table with the sort procedure (construyendo la tabla de tamaos relativos con el procedimiento del
ordenamiento) ................................................................................................................................................................................. 19
3.4.6 Building a relative size table with the standard deviation procedure (La construccin de una tabla de tamao relativo con .... 19
el procedimiento de la desviacin estndar)........................................................................................................................................ 19
Knowledge Area 3.5: The PROBE Estimating Method (el mtodo de estimacin PROBE) ................................................................. 19
3.5.1 What is PROBE? (Qu es PROBE?) .................................................................................................................................... 19
3.5.2 Conceptual design (diseo conceptual) .................................................................................................................................. 19
3.5.3 Formulate size estimates for proxies (Formular las estimaciones del tamao 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 mtodo PROBE adecuado) ............................................................... 20
3.5.6 Estimate program size (Estimar el tamao 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 (Definicin de intervalo de prediccin) ........................................................................................ 20
Knowledge Area 3.6: Combining Estimates (La combinacin 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 (Guas para la estimacin del tamao)................................................................... 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 planeacin) .......................................................................................... 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 Planificacin 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 planificacin de PSP) ..................................................................................................... 22
4.2.3 Requirements definition (1Definir los requerimientos) ............................................................................................................. 22
4.2.4 Produce the conceptual design (Generar el diseo conceptual) .............................................................................................. 22
4.2.5 Use PROBE for size and resource estimation (Utilizar PROBE para estimar tamao y recursos) ........................................... 22
4.2.6 Select the appropriate PROBE method for resource estimation (seleccione el mtodo PROBE adecuado para estimacin .... 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 (Distribucin de tiempo a travs de las fases) ....................................................................... 23
4.2.10 Schedule projection (proyeccin 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 desempeo del costo) ........................................................................................... 23
Knowledge Area 4.3: Software Size and Effort (tamao y esfuerzo del software) ............................................................................... 23
4.3.1 Size and effort correlation (correlacion de tamao con esfuerzo) ............................................................................................ 23
4.3.2 Productivity (productividad) ..................................................................................................................................................... 23
Knowledge Area 4.4: Task and Schedule Planning (planeacin de tareas y calendario) .................................................................... 23
4.4.1 Project plan characteristics (Caractersticas del plan de proyecto) .......................................................................................... 23
4.4.2 Period plans and project plans (Planes del perodo 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 mtricas 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 relacin 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 (Clculo del PV acumulado para un perodo 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 (Estimacin de la fecha de terminacin 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 (planeacin 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 economa 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 (mtricas 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 revisin)......................................................................................................................... 26
5.2.8 Percent appraisal cost of quality (COQ) (Porcentaje de costo de evaluacin 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 relacin de evaluacin / 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 (Clculo 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 revisin) ............................................................................................................................................. 28
5.2.18 Defect-removal leverage (DLR) (Apalancamiento de eliminacin de defectos).................................................................... 28
Knowledge Area 5.3: Quality Methods (Mtodos de Calidad) .............................................................................................................. 28
5.3.1 Personal reviews (revisiones personales) ............................................................................................................................... 28
5.3.2 Personal review principles (principios de revisin personal) .................................................................................................... 28
5.3.3 Inspections (inspecciones) ...................................................................................................................................................... 28
5.3.4 Walkthroughs (recorridos)....................................................................................................................................................... 28
5.3.5 Relationship between reviews and inspections (relacin 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 cdigo en PSP) .......................................................................................... 29
5.4.1 Code review checklist (checklist de revisin de cdigo) .......................................................................................................... 29
5.4.3 Code review strategy (estrategia de revisin de cdigo) ........................................................................................................ 29
5.4.4 Review against a coding standard (revisin contra un estndar de codificacin)..................................................................... 29
Knowledge Area 5.5: PSP Design Reviews (revisines de diseo PSP) ............................................................................................. 29
5.5.1 Design review principles (principios de revisin de diseo) .................................................................................................... 29
5.5.2 Design review checklist (checklist de revisin de diseo) ........................................................................................................ 29
5.5.3 PSP design reviews (revisions de diseo en PSP)................................................................................................................. 29
5.5.4 Design review strategy (estrategia de revisin de diseo) ....................................................................................................... 29
Knowledge Area 5.6: Review Issues (aspectos de la revision) ........................................................................................................... 29
5.6.1 Review efficiency (eficiencia en la revisin) ............................................................................................................................ 30
5.6.2 Reviewing before or after compiling (Revisar antes o despus de compilar) ........................................................................... 30
5.6.3 Review objectives (objetivos de la revisin) ............................................................................................................................ 30
Competency Area 6: Software Design (Diseo de Software) ................................................................................................................. 30
Knowledge Area 6.1: Software Design Principles (Principios de diseo de Software) ........................................................................ 30
6.1.1 Definition of software design (Definicin de Diseo de Software) ............................................................................................ 30
6.1.2 The design process (El proceso de diseo) ............................................................................................................................ 30
6.1.3 The role of design in the overall software development process (El role del diseo dentro del proceso general de desarrollo de
Software)......................................................................................................................................................................................... 30
6.1.4 The requirements uncertainty principle (El principio de incertidumbre del diseo) .............................................................. 30
6.1.5 The role of design in PSP (El rol de diseo en PSP) ............................................................................................................... 30
6.1.6 Design methodology in PSP (Metodologa de Diseo en PSP) ............................................................................................... 31
6.1.7 Design specification structure (Estructura de la epecificacin de diseo) ............................................................................... 31
6.1.8 Need for design precision (Necesidad de la precisin en el diseo) ........................................................................................ 31
Knowledge Area 6.2: Design Strategies (Estrategias de Diseo) ....................................................................................................... 31
6.2.1 The need for design strategies (La necesidad de estrategias de diseo) ................................................................................ 31
6.2.2 Nature of the design process (Naturaleza del proceso de diseo) ........................................................................................... 31
6.2.3 Design process guidelines (Guas del proceso de diseo) ..................................................................................................... 31
6.2.4 Types of design strategies (Tipos de estrategias de diseo) ................................................................................................... 31
Knowledge Area 6.3: Design Quality (Calidad en el Diseo) .............................................................................................................. 31
6.3.1 Design precision (Precisin del Diseo) ................................................................................................................................. 31
6.3.2 Design completeness (Completitud del Diseo) ...................................................................................................................... 31
6.3.3 Design usability (Usabilidad del diseo) ................................................................................................................................. 32
Knowledge Area 6.4: Design Documentation (Documentacin del Diseo) ........................................................................................ 32
6.4.1 The need for software design documentation (La necesidad de documentar el diseo) .......................................................... 32
6.4.2 Overall design documentation concerns (Preocupaciones generales sobre la documentacin del diseo) ............................. 32
6.4.3 Common types of design documentation (Tipos comunes de documentacin del diseo) ...................................................... 32
6.4.4 Design visibility (Visibilidad del diseo) ................................................................................................................................... 32
6.4.5 Design documentation practice (Practica de documentacin del diseo) ................................................................................ 32
Knowledge Area 6.5: Design Templates (Plantillas de Diseo) .......................................................................................................... 32
6.5.1 Design notation (Notacin de diseo) ..................................................................................................................................... 32
7
6.5.2 PSP design templates (Pantillas de diseo) ............................................................................................................................ 32
6.5.3 Operational specification template (OST) (Plantilla de especificacin operacional - OST) ...................................................... 33
6.5.4 Functional specification template (FST) (Plantilla de especificacin funcional - FST) .............................................................. 33
6.5.5 State specification template (SST) (Plantilla de especificacin de estados SST) .................................................................... 33
6.5.6 Logic specification template (LST) (Plantilla de especificacin lgica - LST) ........................................................................... 33
6.5.7 Template usage (Uso de la plantillas) ..................................................................................................................................... 33
Knowledge Area 6.6: Design Verification (Verificacin del Diseo) .................................................................................................... 33
6.6.1 Design standards (Estndares de diseo) .............................................................................................................................. 33
6.6.2 Verification methods (Mtodos de verificacin) ....................................................................................................................... 33
6.6.3 Choosing the appropriate design verification method (Seleccin del mtodo de verificacin adecuado) ................................. 34
6.6.4 Using execution table verification (Uso de verificacin con la tabla de ejecucin) ................................................................... 34
6.6.5 Using trace-table verification (Uso de verificacin con la tabla de rastreo) .............................................................................. 34
6.6.6 Execution table verification vs. trace-table verification (Verificacin con tabla de ejecucin vs. Verificacin con tabla de rastreo)
........................................................................................................................................................................................................ 34
6.6.7 Using state-machine verification (Uso de la verificacin de la mquina de estados) ............................................................... 34
6.6.8 Using loop verification (Uso de la verificacin de ciclos) ......................................................................................................... 34
Competency Area 7: Process Extensions and Customization (Extensin y adaptacin 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 informacin para documentar
un proceso nuevo o adatpar un proceso) ........................................................................................................................................ 35
Knowledge Area 7.2: Process Evolution (Evolucin del Proceso)....................................................................................................... 35
7.2.1 Initial process definition (Definicin 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 mtodos 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 (Prctica) .................................................................................................................................................................. 35
7.3.4 Learn from others, and pass on what you know (Aprenda de otros y ensee lo que sabe) ..................................................... 36
7.3.5 Find and learn new methods (Encuentre y aprenda nuevos mtodos) .................................................................................... 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 mtodos estadsticos
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 (Definicin del Proceso) Esta rea de conocimiento esboza los conceptos fundamentales y las habilidades
que permiten a los profesionales de la ingeniera de software crear, usar, y ajustar los procesos definidos que componen 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 Medicin) Esta rea de conocimiento describe las mtricas 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 Estadstica) Esta rea de conocimiento analiza las estadsticas que proveen una base para
la planificacin y el seguimiento de las metodologas utilizadas en el PSP, y que tambin proporcionan un medio objetivo de analizar y
mejorar los procesos personales.
Knowledge Area 1.1: Process Definition (Definicin del Proceso)
El PSP es una serie de procesos definidos que permiten a los profesionales de ingeniera (como los desarrolladores de software) construir
productos de alta calidad a tiempo y dentro del presupuesto. Esta rea de conocimiento esboza los conceptos y las habilidades necesarias
para crear, ajustar, y usar los procesos definidos.
1.1.1 Process (Proceso)
Un proceso describe la secuencia de pasos que un profesional calificado debe seguir para realizar una tarea determinada.
1.1.2 Defined process (Proceso Definido)
Un proceso definido es una secuencia documentada de los pasos necesarios para hacer un trabajo especfico. Los procesos se definen
habitualmente para los trabajos que se realizan en varias ocasiones y 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 planificacin, seguimiento y gestin del trabajo
una gua para hacer el trabajo correcta y completamente, con los pasos en el orden apropiado.
una base objetiva para medir el trabajo y dar seguimiento al progreso en la consecucin de metas, y para refinar el proceso en
futuras versiones
Una herramienta para la planificacin y la gestin de la calidad de los productos
Procedimientos acordados y entendidos por los miembros del equipo para usarlos para coordinar su trabajo y con ellos construir
un producto comn.
un mecanismo que permite a los miembros del equipo apoyarse mutuamente en el transcurso del proyecto
1.1.4 Process documentation (Documentacin del proceso)
Documentar un proceso es el acto de producir una representacin escrita y concreta de un proceso, los criterios de entrada y salida, las
fases del proceso, y los pasos del proceso para cada fase. La documentacin del proceso no debe contener tutoriales u otros materiales
explicativos generalmente requeridos por personas no calificadas o desinformadas, sino que slo debera facilitar la informacin
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 instanciacin especfica 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 (Patrn de procesos y procesos operativos)
Un Patrn de procesos (enactable process) define con precisin como hacer un proceso e incluye todos los elementos necesarios para
usar un proceso. Un Patrn de procesos (enactable process) consiste en una definicin del proceso, los insumos que requiere, los
agentes asignados, los recursos (por ejemplo, las personas, equipos, tiempo, dinero), y los criterios de salida. Un proceso operativo
define con precisin lo que se debe hacer mediante una lista de tareas necesarias, con el detalle suficiente para guiar a un profesional
con conocimiento para hacer la tarea. Los procesos operativos proporcionan una gua 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 patrn de proceso operativo.
1.1.8 Process phases (Fases del proceso)
Un proceso definido, consta de una serie de pasos, elementos o actividades que comnmente se llaman fases. Las fases de un proceso
simple consisten en pasos sin mayor sub-estructura. Los procesos ms 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 mnimo, cualquier proceso debe tener tres fases:
planificacin, desarrollo, y postmortem.
1.1.9 The PSP process phases (las fases del proceso PSP)
El proceso bsico PSP tiene tres fases.
9
1.
2.
3.
Planificacin: Elaborar un plan para hacer el trabajo.

Desarrollo: Realizar el trabajo.
a. definir los requerimientos (ver 4.2.2)
b. disear el programa
c. revisar el diseo y corregir todos los defectos
d. codificar el programa
e. revisar el cdigo y corregir todos los defectos
f.
construir o compilar y corregir todos los defectos
g. probar el programa y corregir todos los defectos
Postmortem: Comparar los resultados reales con el plan, registrar los datos histricos 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 estn disponibles [Humphrey 05a].
Con desarrollos incrementales a gran escala, los mtodos de PSP se usan ms eficazmente cuando cada incremento es de
alta calidad.
1.1.11 Process tailoring (adaptacin de procesos)
La adaptacin de procesos es el acto de personalizar la definicin de un proceso para soportar la adaptacin de ese proceso para un
propsito particular (ver 7.1).
1.1.12 Process building and refining (definicin 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 construccin de un producto. Los profesionales deben definir sus propios procesos para garantizar
que los procesos se ajusten a sus necesidades lo ms posible [Humphrey 95, p. 16]. Como el proceso est definido para diversos
proyectos, los usuarios del proceso deben procurar el perfeccionamiento y la mejora continua tanto en el proceso mismo como en la
calidad de los productos construidos con ese proceso.
Knowledge Area 1.2: Process Elements (Elementos del Proceso)
Esta rea de conocimiento describe los componentes que se incluyen en cualquier proceso personal y define un marco para organizar el
trabajo del proyecto.
1.2.1 Process elements (Elementos del Proceso)
Los elementos del proceso son los componentes de un proceso. El PSP contiene cuatro elementos bsicos: guiones (scripts), formas
(formatos), mtricas y estndares.
1.2.2 Guiones (Scripts)
Los guiones (Scripts) son descripciones a nivel experto que guan el uso de un proceso. Contienen referencias a las formas, estndares,
Listas de verificacin (checklists), sub-guiones (sub-scripts), y mtricas pertinentes. Un guion (script) puede estar definido a alto nivel
para todo un proceso o en un nivel ms detallado para una fase en particular de un proceso. Un guion (script) de proceso documenta
el propsito u objetivo del proceso
los criterios de entrada
directrices generales, consideraciones de uso, o restricciones
fases o etapas que deben realizarse
mtricas del proceso y criterios de calidad
condiciones de salida (como productos de trabajo definidos o datos requeridos del proceso)
1.2.3 Forms (formas, formatos)
Las formas proporcionan un marco adecuado y coherente para la recoleccin y registro de datos, especifican los datos requeridos y
donde registrarlos. Segn corresponda, las formas tambin definen los clculos necesarios y la definicin de datos. Se pueden utilizar
formas en papel si no se tienen herramientas automatizadas, fcilmente accesibles, para la recopilacin y el registro.
En PSP, los checklist (listas de verificacin) 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 ms comnmente ocurren y que se pueden encontrar con una revisin. Todo el producto es
revisado enfocndose 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 revisin.
1.2.4 Measures (mtricas)
Las mtricas cuantifican el proceso y el producto, la mtricas proporcionan datos de cmo est funcionando el proceso permitindole a
los usuarios
desarrollar perfiles de datos de proyectos anteriores que puedan ser usados para la planeacin y mejora de procesos
analizar un proceso para determinar la manera de mejorarlo
determinar la eficacia de las modificaciones al proceso
supervisar la ejecucin de sus procesos y tomar decisiones con respecto a los siguientes pasos
supervisar la capacidad para cumplir los compromisos y tomar acciones correctivas cuando sea necesario
1.2.5 Standards (estndares)
Los estndares proporcionan definiciones precisas y consistentes que guan el trabajo y la recopilacin y uso de datos. Los estndares
(como el de codificacin, conteo de lneas, y tipos de defectos) permiten que las mtricas se apliquen uniformemente en diversos
proyectos y que se usen de manera consistente. Los profesionales de PSP deberan ser capaces de reconocer las reas donde los
estndares podran ser tiles y elaborarlos cuando sea necesario.
Knowledge Area 1.3: Measurement Principles (Principios de medicin)
Esta rea de conocimiento describe la medicin del proceso y del producto, y explica por qu las mtricas son esenciales para producir
trabajo de alta calidad.
10
1.3.1 The need for measures (la necesidad de usar mtricas)

Las mtricas se utilizan en PSP de manera que los cambios al proceso pueden ser identificados, evaluados, lgicamente implementados,
y jugados como efectivos o inefectivos.
1.3.2 Measurement types (tipos de mtricas)
Para que sean tiles para la gestin de procesos, toda mtrica debe ser definida, precisa, exacta, y significativa. Hay dos tipos principales
de mtricas utilizadas en PSP: mtricas de producto (artefacto) y del proceso.
Las mtricas de producto se utilizan para cuantificar las caractersticas del producto, tales como el tamao del producto o los
defectos encontrados por elemento
Las mtricas del proceso describen o cuantifican el proceso de desarrollo o de correccin utilizado, y se clasifican como
mtricas histricas o actuales.
o
Las Mtricas histricas del proceso se utilizan despus de que el proceso se ha realizado para registrar los datos
reales, tales como el tiempo de inspeccin, el tiempo de pruebas, etc.
o
Las mtricas actuales del proceso se utilizan mientras el proceso se est ejecutando para registrar datos como la
duracin de las reuniones de inspeccin, el tiempo de revisin de cdigo como porcentaje del tiempo total de
codificacin, y similares.
Tanto las mtricas de producto (artefacto) como las de proceso pueden basarse en mtricas individuales o mltiples. La eleccin de
mtricas individuales o mltiples depende de la naturaleza de los datos y el uso que se le dar a cada una. Cuando se toman mtricas
mltiples, es necesario un procedimiento estadsticamente sensato para calcular los valores a ser utilizados a partir de estas mtricas.
1.3.3 Defined measures (mtricas definidas)
Una mtrica definida es aquella que tiene un significado explcito e inequvoco. Para las mtricas de proceso, se requiere que el proceso
est definido con precisin para incluir criterios de entrada y salida para todas las fases. Las propiedades que se miden en un proceso
tambin deben estar completa y explcitamente definidas.
1.3.4 Precise and accurate measures (Mtricas precisas y exactas)
Una mtrica precisa es la que especifica un valor a un nivel adecuado de precisin, como con un nmero determinado de dgitos despus
del punto decimal. Una mtrica exacta es la que mide correctamente la propiedad que se pretende medir. Las mtricas pueden ser
precisas y exactas, precisas pero inexactas, imprecisas pero exactas, o imprecisas e inexactas. En gestin de procesos, las mtricas
deben ser tan precisas y exactas como sea posible.
1.3.5 Meaningful measures (Mtricas significativas)
Para ser significativa, las mtricas deben representar realmente el verdadero valor de la propiedad del producto o proceso que se est
midiendo, lo que indica que la mtrica representa una caracterstica objetiva de un fenmeno real. La significancia de la mtrica aumenta
con el nmero y consistencia de las mtricas que se van tomando.
1.3.6 Uses of process measures (usos de las mtricas de proceso)
Las mtricas de proceso pueden ser utilizadas para evaluar las caractersticas del producto o proceso, para estimar elementos del
producto o del proceso, o para predecir los resultados futuros. Tambin 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 Estadstica)
La estadstica es el fundamento para la planeacin y las metodologas de seguimiento en PSP, adems proporcionan un medio objetivo
de analizar y mejorar los procesos personales. (Nota: Las definiciones especficas, interpretaciones o aplicaciones de trminos
estadsticos que hace PSP se mencionan en cada subseccin del rea de conocimiento aplicable.)
1.4.1 Distributions (distribucin)
Una distribucin es un conjunto de valores numricos que son generadas por un proceso comn (tamaos reales de las partes
desarrolladas o estimaciones del tamao de las partes).
1.4.2 Mean (Media)
La media es el valor promedio aritmtico de una distribucin. En PSP, la media es normalmente una estimacin de la media de la
distribucin, no es la media real.
1.4.3 Variance (Varianza)
La varianza es una medida de la difusin o estrechez de una distribucin alrededor de la media. En PSP, la varianza es normalmente
una estimacin de la varianza de la distribucin, en lugar de la varianza real.
1.4.4 Standard deviation (Desviacin estndar)
La desviacin estndar es la raz cuadrada de la varianza. A menudo se utiliza para caracterizar el rango esperado de la desviacin entre
una estimacin y un valor real. Por ejemplo, un mtodo en PSP utiliza la desviacin estndar para clasificar el tamao de software en
tablas de tamao relativo. La desviacin estndar tambin se utiliza como parte del clculo de los intervalos de prediccin.
1.4.5 Correlation (correlacin)
La correlacin mide como dos conjuntos de datos estn relacionados. En PSP la correlacin es medida entre el tamao estimado y real,
y entre el esfuerzo estimado y el real.
1.4.6 Significance of a correlation (Significancia de una correlacin)
La significancia mide la probabilidad de que dos conjuntos de datos tengan un alto grado de correlacin por casualidad. Las estimaciones
de tamao y esfuerzo en PSP son ms confiables cuando se basan en datos histricos que tienen un alto grado de correlacin que es
significativo.
1.4.7 Linear regression (Regresion Lineal)
La regresin lineal determina la lnea a travs de los datos que minimiza la varianza de los datos con respecto a dicha lnea. Por ejemplo,
cuando el tamao y el esfuerzo se relacionan linealmente, la regresin lineal puede utilizarse para obtener estimaciones de esfuerzo a
partir de las estimaciones de tamao.
11
1.4.8 Prediction interval (Intervalo de prediccin)

El intervalo de prediccin provee el rango alrededor de una estimacin hecha mediante regresin lineal en el que el valor real caer con
una cierta probabilidad. Por ejemplo, en PSP, el 70% de intervalo de prediccin de una estimacin de tamao o de tiempo implica un
0.7 de probabilidad de que el valor real de tamao o tiempo estar dentro del rango definido por el intervalo de prediccin.
1.4.9 Multiple regression (regression multiple)
La regresin mltiple se utiliza en PSP cuando las estimaciones de tamao o tiempo dependen de ms de una variable. Por ejemplo, si
las modificaciones de los programas requieren mucho ms tiempo que las adiciones, entonces aadir y modificar se pueden separar en
dos variables para el clculo de regresin.
1.4.10 Standard normal distribution (distribucin normal estndar)
La distribucin normal estndar es una distribucin normal que se ha convertido a una media de cero y una desviacin estndar de uno
La distribucin normal estndar se usa en PSP al construir una tabla de estimacin de tamao.
1.4.11 Log-normal distribution (Distribucin logartmica normal)
Muchas de las operaciones estadsticas asumen que los valores de los datos se distribuyen normalmente, pero algunas mtricas de PSP
no cumplen con este requisito. Por ejemplo, los valores de tamao no pueden ser negativos, pero pueden tener valores pequeos que
estn cerca de cero. Estas distribuciones tambin suelen tener probabilidades ms altas de tener valores grandes que una distribucin
normal. Cuando una transformacin logartmica se aplica a un conjunto de datos de este tipo, la distribucin resultante puede tener una
distribucin normal y por tanto ser adecuada para los anlisis estadsticos de datos que asumen una distribucin normal. Los parmetros
estadsticos de la distribucin normal se pueden calcular y luego transformarse de nuevo a la distribucin original. Los datos de tamao
en PSP generalmente tienen una distribucin logartmica normal, por lo que deben transformarse en una distribucin normal para la
construccin de una tabla de estimacin de tamao.
1.4.12 Degrees of freedom (Grados de libertad)
Los grados de libertad (df) miden el nmero de puntos de datos (n), en comparacin con el nmero de parmetros (p) que se utilizan
para representarlos. En la regresin lineal, dos parmetros (0 y 1) describen la lnea que se utiliza para aproximar los datos. Dado al
menos dos puntos son necesarios para determinar una lnea, el nmero de grados de libertad es n-2. En general, el nmero de grados
de libertad es n-p.
1.4.13 The t-distribution (la distribucin T)
La distribucin t permite la estimacin de la varianza de una distribucin normal cuando los verdaderos parmetros no son conocidos,
permitiendo as el clculo de los parmetros estadsticos basados en estimaciones de datos de una muestra. Como la distribucin normal,
la distribucin-t tiene forma de campana, pero vara dependiendo del nmero de puntos en la muestra. Para menos puntos de datos, la
distribucin es corta con cabos gruesos. Conforme aumenta el nmero de puntos de datos, la distribucin se hace ms alta, con pequeos
cabos y se aproxima a la distribucin normal. En PSP, la distribucin t es importante porque ayuda a determinar la significancia de una
correlacin y el intervalo de prediccin para la regresin, cada una de las cuales depende del nmero de puntos en el conjunto de datos
de la muestra.
Competency Area 2: Basic PSP Concepts
La segunda rea de conocimiento, presenta los conceptos bsicos de mejora de procesos y habilidades en las cuales PSP est
fundamentado. Las reas de conocimiento principales que componen esta rea de competencia son las siguientes:
2.1 Process Fidelity (Adherencia al proceso) - Esta rea de conocimiento introduce el concepto de adherencia al proceso y aborda el
efecto de la misma respecto a la calidad del proceso.
2.2 Data colecction (Recoleccin de Datos) - Esta rea de conocimiento aborda habilidades y conceptos relativos a la recoleccin y
utilizacin de datos del proceso.
2.4 Data Analysis (Anlisis de Datos) - Esta rea de conocimiento describen los conocimientos y aptitudes necesarios de los
profesionales PSP para analizar los datos que se 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 desempeo 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 creacin y el uso consistente de un proceso de alta calidad se
traducirn en la construccin de productos de alta calidad. La calidad del producto, a su vez, tiene un efecto directo sobre la capacidad
de los individuos para cumplir el calendario y los objetivos presupuestarios del producto.

12
2.1.4 Process fidelity and planning (Adherencia al proceso y planeacin)
Cuando un proyecto est planeado conforme a procesos eficaces y eficientes y se hacen estimaciones basadas en datos slidos, el
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 desempeo)
Un proceso bien definido y medido que se sigue fielmente permite a las personas seleccionar los mtodos que mejor se adaptan a sus
habilidades particulares 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 desempeo.
Knowledge Area 2.2: Data Collection (Recoleccin de datos)
Esta rea de conocimiento aborda las habilidades y conceptos relativos a la recoleccin y utilizacin de datos del proceso.
2.2.1 Collecting data (recopilacin de datos)
El PSP se basa en los datos ya que los individuos no pueden mejorar sus procesos de trabajo a menos que entiendan exactamente cmo
trabajan y exactamente que hacen. Los datos deben utilizarse para 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 recoleccin y anlisis de los datos se incluye:
el establecimiento de estndares para productos y procesos

determinar si un determinado producto o proceso cumple con los criterios definidos
controlar de manera precisa el trabajo de los individuos
generar indicadores de desempeo de los individuos
mejorar el rendimiento personal
gestionar la calidad de los productos producidos
estimar cuando se terminar el trabajo
planear, dar seguimiento y reportar de forma precisa el trabajo
2.2.2 Collecting useful data (Recoleccin de datos tiles)

Para ser ms tiles, los datos deben ser recolectados de acuerdo a las siguientes directrices:
El proceso de recoleccin de datos debe tener objetivos y planes especficos.

Los datos reales deben ser seleccionados por su relevancia en la aplicacin de un modelo o prueba de una hiptesis.
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 informacin precisa y relevante.
El proceso de recoleccin de datos debe incluir consideraciones sobre el impacto que tiene la recoleccin de datos en la
organizacin y su gente.
El plan de recoleccin de datos debe contar con el apoyo de la gerencia, la propia gerencia debe considerar la recoleccin de
datos como una inversin con alto retorno, en trminos de poder ser capaces de predecir con precisin los costos y calendario
de desarrollo de productos, as como proporcionar una base para mejorar la eficiencia de la organizacin y la calidad de sus
productos.
2.2.3 Collecting high-quality data (recopilacin de datos de alta calidad)

Los datos de software son altamente propensos a errores. La mejor manera de garantizar que los datos son de alta calidad es capacitar
a los individuos en mtodos adecuados para tomar mtricas del proceso y registrar los datos que recolecten. El uso de herramientas
automatizadas para la recoleccin 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 informacin de los procesos inmediatamente despus 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 informacin
en tiempo real (o lo ms pronto posible despus de que se generan los datos). Sin embargo, los individuos deben estar seguros que los
datos de su proceso personal no sern utilizados para evaluar su desempeo, si la gente teme que sus datos sean utilizados para
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 planificacin)
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 histricos semejantes (vase 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 ms productos, trabajos o proyectos de la misma naturaleza
previamente realizados.
Cuanto ms similares sean los esfuerzos previamente realizados al que se est planeando, ms probable ser que se llegue
a una estimacin exacta.
Entre ms datos histricos se utilicen al hacer una estimacin, es mayor la probabilidad que la estimacin sea exacta.

13
La estimacin de un trabajo grande o un proyecto completo como un compuesto de varios productos de trabajo o sub-proyectos
compuestos es ms precisa que la estimacin del proyecto como una gran unidad nica.
Knowledge Area 2.3: Data Measures

En esta rea de conocimiento se describen las cuatro mtricas bsicas de PSP.
2.3.1 Basic PSP measures (Mtricas Bsicas de PSP)
Las mtricas bsicas de PSP son tiempo, tamao, calidad (defectos), y datos de calendario.
2.3.2 Time measures (Metricas de Tiempo)
El tiempo se mide en minutos y se registra mientras se est haciendo el trabajo, porque los tiempos registrados despus tienen mayor
probabilidad de ser inexactos. Los componentes bsicos son start date (fecha de inicio), start time (tiempo de inicio), end date (fecha
de finalizacin), end time (tiempo de finalizacin), interrupt time (tiempo de interrupcin), 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 interrupcin) no se incluye en la medicin del tiempo para una tarea o fase del proceso. Si hay
una interrupcin durante el trabajo, ese tiempo se resta de la medicin del tiempo.
El off-task time (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 gestin y en reuniones administrativas, asistir a cursos
de formacin, lectura de correo electrnico, 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 perodo 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 interrupcin (interrupt time).
Los registros de tiempo son ms exactos cuando se recolectan con una herramienta automatizada, la herramienta debe ser capaz de
registrar el tiempo de inicio y finalizacin as como las fechas, calcular el tiempo transcurrido, y restar el tiempo de interrupcin al tiempo
transcurrido para calcular el delta time (tiempo delta). Cada entrada en el registro de tiempos debe tambin incluir los nombres de la fase
o paso del proceso, el producto y el elemento que se est trabajando, la tarea del proyecto que se est realizando y la persona que est
haciendo el trabajo.
2.3.3 Size measures (mtricas de tamao)
Una mtrica de tamao se utiliza para medir qu tan grande es un producto de trabajo. Las mtricas de tamao se seleccionan de manera
que sean apropiadas para el producto de trabajo, por ejemplo, la utilizacin de pginas (en vez de palabras o letras) como una mtrica
para documentos, o tomar en cuenta las tareas de programacin y el lenguaje para los componentes de software (ver el reas de
Conocimiento 3.1 y 3.2). Los datos de las mtricas de tamao deben recolectarse en tiempo real en la medida de lo posible porque los
datos recolectados despus de los hechos es ms probable que sean inexactos. La medicin de tamao se aplica no slo a los
componentes del producto final, sino tambin a los componentes y versiones intermedias de los productos.
Los datos de tamao son ms exactos cuando se recolectan utilizando una herramienta automtica en la que se registran tanto el tamao
planeado como el real de las diferentes partes del producto o componentes, usando las categoras de las mtricas de tamao descritas
en 3.1.6. La herramienta debe calcular los totales de los datos para cada categora de tamao 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 trminos de defectos. Un defecto es cualquier cosa en algn componente de software o del
producto que debe ser cambiado para que sea correctamente diseado, desarrollado, mantenido, fortalecido, o usado. Los defectos
pueden estar en el cdigo, diseo, requerimientos, especificaciones, u otra documentacin. 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 descripcin 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 correccin (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 correccin. El tiempo de
correccin se registra por separado para cada defecto.
2.3.5 Defect type standard (estandar de tipos de defectos)
El estndar define las categoras dentro de las cuales se pueden clasificar defectos similares. La asignacin coherente de los defectos
similares a la misma categora de tipo de defecto es fundamental para el anlisis del proceso.
2.3.6 Schedule measures (mtricas de calendario)
Las mtricas 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 ms 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 cuestin, 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 informacin de las fechas de terminacin de las tareas, ya que esta es la manera
de obtener el earned value (valor ganado) (EV) que permite a los individuos el seguimiento de su progreso en relacin con el calendario
planeado (ver 4.5).
2.3.7 Derived measures (mtricas derivadas)
PSP ofrece un conjunto de mtricas de desempeo y calidad para ayudar a las personas a aplicar y mejorar sus procesos personales.
Las mtricas derivadas especficas se revisan en reas de conocimiento posteriores.
Knowledge Area 2.4: Data Analysis (anlisis de datos)
Esta rea de conocimiento describe los conocimientos y habilidades necesarias para los profesionales de PSP que les permitan analizar
los datos que recolectan del proceso.
2.4.1 Measurement framework and data analysis (marco de medicin y anlisis de datos)
Todas las mtricas en PSP estn relacionadas. Las personas deben entender cmo cada mtrica se relaciona con las dems y cmo
pueden ser utilizadas para derivar las mtricas que proporcionan informacin sobre la eficacia del proceso.
2.4.2 Postmortem
Un anlisis postmortem sobre el trabajo realizado en una fase o proyecto proporciona informacin valiosa, incluida
datos actualizados del proyecto para tiempo, tamao, defectos y calendario (real, a la fecha, y porcentaje (%) a la fecha)
los clculos actualizados de datos para calidad y desempeo
una revisin del desempeo contra lo planeado
base de datos histricos actualizado para el tamao 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 revisin de diseo o cdigo sealados por los defectos que se escaparon de alguna fase, etc.)
2.4.3 Performance measures (mtricas de desempeo)

Las mtricas clave del desempeo del proceso personal son
capacidad para cumplir los compromisos de calendario para la entrega de los componentes prometidos
calidad de los elementos entregados
mtricas especficas de proyecto
2.4.4 Performance baselines (lneas base de desempeo)

Antes de que las personas puedan mejorar su desempeo, primero tienen que entender el nivel de su desempeo actual. Despus de
recolectar suficientes datos del proyecto que proporcione una cantidad significativa de informacin para el anlisis, las personas deben
realizar un anlisis de lnea base de su desempeo a la fecha y formular cambios adecuados en los procesos para mejorar su desempeo
en las reas problemticas.
2.4.5 Combined measures (mtricas combinadas)
Las mtricas se pueden combinar para proporcionar datos tiles para los planes de futuros proyectos y mejoras en los procesos. Por
ejemplo, las mtricas de varios proyectos pueden ser combinadas para crear un grfico que muestra las tendencias en el tamao
estimado frente a tamao real, para proporcionar datos para las futuras estimaciones de tamao.
2.4.6 Analyzing historical data (anlisis de datos histricos)
Los datos deben ser examinados para determinar si son adecuados para el anlisis. Por ejemplo, los datos de los proyectos basados en
el lenguaje C# pueden no proporcionar una correlacin adecuada para el anlisis de proyectos basados en el lenguaje C ++. Los datos
histricos tambin deben ser examinados para determinar si la correlacin es adecuada y significativa como base para los procesos de
medicin y anlisis del proyecto.
2.4.7 Analyzing size-estimating accuracy (Anlisis de la precisin de la estimacin del tamao)
Los datos Histricos del tamao estimado frente a tamao real tomados del proceso personal pueden ser analizados para determinar las
posibles causas de malas estimaciones. Considere las siguientes preguntas.
Con qu frecuencia est lo estimado contra lo real dentro del 70% del intervalo de prediccin?
Hay una tendencia a omitir partes en el diseo conceptual?
Qu podra hacerse para mejorar las estimaciones?
Estn las estimaciones de tamao sesgadas de alguna manera?
Existe una tendencia a juzgar mal los tamaos relativos de las partes?
Las estimaciones de tamao mejoran con el tiempo?
2.4.8 Analyzing effort-estimating accuracy

Los datos histricos de las estimaciones de esfuerzo estimado vs esfuerzo real del proceso personal pueden ser analizados para
determinar las posibles causas de malas estimaciones.
Con qu frecuencia est lo estimado contra lo real dentro del 70% del intervalo de prediccin?
Los errores de estimacin de tamao correlacionan con los errores de estimacin del esfuerzo?

15
los proyectos subestimados correlacionan con un mayor porcentaje de re-trabajo?

Estn mejorando las estimaciones de esfuerzo?
Qu podra hacerse para mejorar la exactitud de la estimacin?
2.4.9 Analyzing size and time relationships (anlisis entre la relacin de tamao y tiempo)
Los datos histricos del proceso personal pueden ser analizados para determinar cualquier relacin entre tamao y esfuerzo. Considere
las siguientes preguntas.
La productividad es estable? Por qu o por qu no?

Existen diferencias cuantitativas entre los proyectos de mayor y menor productividad? Si es as, cmo se
podran explicar estas diferencias cuantitativas?
2.4.10 Analyzing phase yields (analizando los yields de las fases)

Los datos histricos del yield (rendimiento) por fase del proceso personal pueden ser analizados para identificar problemas y generar
PIPs para posibles mejoras. Considere las siguientes preguntas.
Existe una relacin entre el yield y la tasa de revisin (tamao revisado por hora) para las revisiones de diseo y de cdigo?
Se encuentran suficientes defectos en las fases adecuadas?
Las revisiones se estn llevando a cabo de manera efectiva?
Cules son los apalancamientos (leverages) de eliminacin de defectos personales para las diversas combinaciones de las
fases de evaluacin/falla?, cmo se pueden mejorar estos apalancamientos (leverages)?
2.4.11 Analyzing defects injected per phase (analizando los defectos inyectados por fase)
Un anlisis 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 ms frecuencia.

Determinar qu tipos de defectos tardan ms en encontrarse y corregirse.
Analizar las tendencias por fase y generales de los defectos inyectado por unidad de tamao.
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 anlisis.
Determinar el porcentaje de tiempo del proyecto PSP que tomar hacer una prueba libre de defectos.
Determinar cunto tiempo toman las pruebas para los proyectos de PSP.
Determinar qu tipos de defectos son los ms costosos para encontrar y corregir en trminos de tiempo (por fase y por
proyecto).
Determinar los tipos de defectos ms comnmente encontrados en la compilacin y las pruebas personales.
Determinar los tipos de defectos ms comnmente encontrados en las pruebas de producto y en el producto entregado.
Generar un anlisis de 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 (Justificacin de la mejora de procesos)
La implementacin 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 aplicacin del proceso de mejora)
Muchos tipos de procesos pueden y deben ser utilizados, incluidos los personales, de equipo, y los procesos de la organizacin.
Aunque las personas implicadas en la mejora del proceso vara en funcin del tipo de proceso, los principios y mtodos son
idnticos para todos los tipos de proceso.
Las personas que deben realizar 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 estn 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 pequeos cambios pueden hacerse cada vez que un proceso se utiliza.
2.5.3 Benchmarks for process improvement (Puntos de referencia para la mejora de procesos)
Los puntos de referencia pueden ayudar a las personas a motivar y orientar sus esfuerzos a la mejora de procesos. La estrategia general
para obtener y utilizar puntos de referencia de proceso es la siguiente.
Identifique a uno o ms proyectos que realicen un trabajo similar.
Establecer convenios de evaluacin 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 disposicin a la divulgacin
o entrega de datos y/o publicacin
o gestin de las revisiones y supervisin
16
Seleccionar los puntos de referencia mejores de su clase, entre los proyectos de colaboracin.
Peridicamente establecer y actualizar objetivos de referencia para el costo, fechas, y el desempeo de calidad.
2.5.4 Set performance improvement goals based on data (establecer las metas de mejora con base en los datos histricos)
Antes de implementar cualquier cambio al proceso, los profesionales de PSP deben analizar los datos histricos del proceso para
determinar las causas originales de los pasados problemas en desempeo. La ejecucin de un anlisis a fondo en las lneas base del
desempeo debe ayudar a los individuos a determinar las reas ms 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 cundo 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 ms alto valor)
El anlisis de datos personales genera muchas PIPs. Los profesionales deben optar por la aplicacin de las PIPs que ofrecen el mayor
potencial de mejora en comparacin con el esfuerzo requerido para hacer los cambios.
2.5.7 Measure process changes (Mtricas de Cambios de proceso)
Debido a que los profesionales de PSP utilizan procesos personales como base para hacer su trabajo, deben entender la forma de
actualizar sus procesos para reflejar los cambios realizados a esos procesos. Deben tambin ser conscientes del impacto que los cambios
pueden tener en la aplicabilidad de sus datos histricos para el trabajo futuro que se realizar con el proceso modificado.
2.5.8 Monitor performance results (Monitor de resultados de desempeo)
Para determinar si las mejoras de proceso ejecutadas han sido eficaces, los profesionales de PSP peridicamente debe repetir los pasos
para generar la lnea 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 opinin 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 debera evitar el bolstering.
Clutching (agarrarse) es la tendencia a un mal desempeo cuando se est bajo presin o cuando un buen resultado es
especialmente crtico, negando as el desempeo exitoso de los proyectos anteriores utilizando los mismos procesos.
Siguiendo procesos establecidos y usando datos (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 problemticas y ser conscientes de
ideas para la mejora continua.
Competency Area 3: Size Measuring and Estimating (Medicin del tamao y estimacin)
En esta rea de competencia se describen los conceptos de medicin del tamao y estimacin en que se basa PSP. Los elementos
esenciales de la medicin y estimacin de tamao son la capacidad de definir las mtricas de tamao adecuadas y utilizar mtodos
disciplinados y datos histricos para estimar el tamao. Las reas de conocimiento principales que componen esta rea de competencia
son las siguientes:
3.1 Size Measures (mtricas de tamao) Esta rea de conocimiento bosqueja los objetivos para medir el tamao, los criterios para la
seleccin de una mtrica de tamao y el sistema de conteo de tamao de PSP.
3.2 Size Data (datos de tamao) Esta rea de conocimiento describe las principales formas en que los datos de tamao se utilizan en
PSP.
3.3 Size Estimating Principles (principios de estimacin de tamao) En esta rea de conocimiento se revisan los principios sobre
los cuales se basa el proceso de estimacin de tamao de PSP. El PSP apoya muchos mtodos de estimacin de tamao, pero todos
los mtodos deben adherirse a estos principios.
3.4 Proxies (sustitutos) Esta rea de conocimiento se describe la seleccin y organizacin de los datos de proxy.
3.5 The PROBE Estimating Method (el mtodo de estimacin PROBE) PSP utiliza un proceso de estimacin definido llamado
Estimacin basada en proxies (PROBE PROxy Based Estimating). Este mtodo se utiliza para estimar tanto el tamao como el
esfuerzo. Esta rea de conocimiento define cmo se realizan las estimaciones del tamao mediante el mtodo PROBE.
3.6 Combining Estimates (combinacin de estimaciones) Esta rea de conocimiento describe las distintas maneras en que las
estimaciones pueden ser combinadas
3.7 Size Estimation Guidelines (guias de estimacin de tamao) Esta rea de conocimiento se mencionan las limitaciones de la
estimacin de tamao.
17
Knowledge Area 3.1: Size Measures (mtricas de tamao)

En esta rea de conocimiento se bosquejan los objetivos para medir el tamao, los criterios para la seleccin de una mtrica de tamao,
y el sistema de conteo de tamao de PSP.
3.1.1 Rationale for using size measures (Justificacin para el uso de medidas de tamao)
Entre los objetivos para utilizar mtricas de tamao se incluyen
lograr consistencia en la descripcin de tamao
normalizar los datos de tiempos y defectos
lograr mejores estimaciones de tamao y mejores planes

3.1.2 Types of measures (tipos de mtricas)
Las mtricas pueden clasificarse como:
absolutas o relativas
explicitas o derivadas
objetivas o subjetivas
dinmicas o estticas
predictivas o explicativas
3.1.3 Criteria for size measures (Criterios para las mtricas de tamao)
Las buenas mtricas de tamao deben ser
relacionadas con el esfuerzo de desarrollo

o el tamao del producto correlaciona estadsticamente 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 precisin

directamente contables
adecuadas para la planificacin temprana
3.1.4 Counting standards (estndares de conteo)

Los estndares de conteo proveen una gua que es
precisa sobre lo que debe contar

especfica para el lenguaje y el tipo de aplicacin
invariable, que da el mismo resultado cada vez que el estndar se aplica
3.1.5 Physical and logical size (tamao fsico y lgico)

Una mtrica de tamao fsico proporciona informacin acerca del tamao de una entidad fsica (el nmero real de ocurrencias de un
elemento en algn producto). Una mtrica de tamao lgico tambin proporciona informacin sobre el tamao, pero se basa en el conteo
de las agrupaciones de entidades fsicas que se pueden agrupar lgicamente. La mtrica lgica del tamao de una entidad fsica no
corresponde necesariamente a la mtrica fsica del tamao de esa misma entidad, dependiendo del estndar de conteo definido para la
mtrica lgica.
3.1.6 Size accounting (conteo de tamao)
Los mtodos de conteo de tamao de PSP para el tamao planeado, actual, y a la fecha definen mtricas para
base (B): la parte no modificada del programa a la que se aaden mejoras posteriores
added (A): (agregadas) cdigo que se agrega al cdigo base
modified (M): (modificadas) la parte del cdigo base se cambia
deleted (D): (borradas la parte del cdigo 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 cdigo aadido y modificado
new reusable (NR): (nuevo re-uso) una parte o elemento que se desarrolla con la intencin de volverlo a utilizar despus
total (T): el tamao del programa completo
3.1.7 Using the size measure selection procedure (Uso del procedimiento de seleccin de la mtrica)
Los pasos para la seleccin de mtricas de tamao son los siguientes.
1. Recolectar datos sobre el desarrollo de productos (recursos necesarios, mtricas de las caractersticas del producto, cualquier
condicin especial de desarrollo, etc.)
2.
Ordenar los productos con base en los recursos necesarios.
3.
Identificar las caractersticas que distinguen a los productos que requirieron el mayor esfuerzo de los que requirieron el menor
esfuerzo.
4.
Seleccionar una mtrica o mtricas de tamao. Para las mtricas de tamao viables determinar la correlacin entre el tamao
y los recursos necesarios. Si no hay una correlacin, repita los pasos 3 y 4 para las otras mtricas de tamao viables.
Algunas mtricas tpicas de tamao incluyen
elementos de base de datos: un conteo de los campos, consultas, o de otros elementos de uso comn en un producto de base
de datos.
18
lneas de cdigo (LOC): un conteo de las lneas lgicas de cdigo en un producto.

elementos de la pantalla: un conteo de los elementos de una interfaz de usuario o GUI (interfaz grfica de usuario) del producto.
tamao del documento: un conteo de las pginas, lneas, palabras o caracteres del documento.
tamao del diseo: un conteo de las clases, definiciones de datos, especificaciones de interface, o caractersticas definidas de
interfaz grfica de usuario.
tamao de los requerimientos: un conteo de pginas de requerimientos, narrativas o puntos de funcin.
Knowledge Area 3.2: Size Data (datos de tamao)

Esta rea de conocimiento describe las principales formas en que los datos de tamao se utilizan en PSP.
3.2.1 Size data help to make better plans (los datos ayudan a hacer mejores planes)
El tamao y el tiempo a menudo tienen correlacin, y cuando eso ocurre, las estimaciones de tamao se pueden utilizar para estimar el
esfuerzo. Los planes pueden ser creados con base en las estimaciones de tamao y esfuerzo.
3.2.2 Size data are useful for tracking development effort (los datos de tamao son tiles para el seguimiento del esfuerzo de
desarrollo)
El tamao y el tiempo a menudo tienen correlacin, y cuando la tienen, las estimaciones de tamao se pueden utilizar para dar
seguimiento al esfuerzo.
3.2.3 Size data help in assessing program quality (los datos de tamao ayudan a evaluar la calidad del programa)
La normalizacin de los datos de los defectos basndose en el tamao permite determinar
la 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 estimacin de tamao)
En esta rea de conocimiento se revisan los principios sobre los cuales se basa el proceso de estimacin de tamao de PSP. El PSP
apoya muchos mtodos de estimacin de tamao, pero todos los mtodos deben adherirse a estos principios.
3.3.1 Estimating is uncertain (la estimacin es incierta)
Nadie sabe cun grande ser el producto, y mientras ms temprano en el proceso se hace la estimacin 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 estimacin es un proceso de aprendizaje)
La estimacin de mejora con la experiencia y con los datos.
3.3.3 Estimating is a skill (Estimar es una habilidad)
Algunas personas pueden ser mejores estimando que otras. La mayora de las personas mejoran en la estimacin mediante la prctica.
3.3.4 Strive for consistency (Esforzarse por la coherencia)
El objetivo del proceso de estimacin del tamao 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 mtodos definidos para hacer estimaciones)
Utilizar un proceso definido de estimacin de tamao facilita el aprendizaje, proporciona una estructura para el uso de datos histricos,
establece una lnea de referencia contra la cual se puede medir la mejora y ayuda a eliminar el sesgo en el proceso.
3.3.6 Estimates are subject to error (Las estimaciones estn sujetas a error)
La exactitud de estimaciones fluctuar alrededor de una media. Las estimaciones pueden tambin tener cierto sesgo.
3.3.7 Estimate in detail (Estimacin 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 estimacin a detalle tambin ayuda a asegurar que la estimacin est completa.
3.3.8 Use historical data to make estimates (utilizar datos histricos para hacer estimaciones)
Al hacer las estimaciones de tamao, encontrar una manera de utilizar cualquier dato histrico disponible.
Knowledge Area 3.4: Proxies (Sustitutos)
Esta rea de conocimiento describe la seleccin y organizacin de los datos de los proxies.
3.4.1 Using proxies instead of a size measure (Usando proxies en lugar de una mtrica de tamao)
La mayora de las mtricas de tamao que cumplen los criterios necesarios no estn disponibles durante la planeacin. Un proxy es una
mtrica sustituta que relaciona el tamao del producto con la funcionalidad planeada y proporciona un medio en la fase de planeacin
para juzgar (y por lo tanto, estimar) el tamao 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 tamao de la mtrica 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 fcil 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 implementacin que afectan el costo o el esfuerzo.
3.4.3 Using relative size tables (usando tablas de tamaos relativos)
Las tablas de tamao relativo se utilizan para organizar los datos de los proxies para que los datos histricos puedan ser utilizados para
estimar el tamao de partes nuevas semejantes.
3.4.4 Building a relative size table (construyendo tablas de tamaos relativos)
PSP establece dos procedimientos para la creacin de una tabla de datos histricos de tamaos relativos: el mtodo del ordenamiento
(sort) y el mtodo de la desviacin estndar. Otros mtodos pueden ser utilizados, pero deben cumplir con los principios de estimacin
de tamao.
3.4.5 Building a relative size table with the sort procedure (construyendo la tabla de tamaos relativos con el procedimiento
del ordenamiento)
Cuando se utiliza el procedimiento del ordenamiento para la construccin de una tabla del tamao relativo, las partes son separadas en
categoras funcionales, tales como clculo, texto, datos, etc. La tabla se llena completando los siguientes pasos para cada categora:
1.
2.
3.
4.
5.
Ordenar los datos de tamao.

Elija el valor ms pequeo como muy pequeo (VS).
Elija el valor ms grande como muy grande (VL).
Escoja el valor mediano como medio (M).
Para grande (L) y pequeo (S), elegir el punto medio entre M y VL, y M y VS, respectivamente.
3.4.6 Building a relative size table with the standard deviation procedure (La construccin de una tabla de tamao relativo con
el procedimiento de la desviacin estndar)
Cuando se utiliza el procedimiento de la desviacin estndar para la construccin de una tabla del tamao relativo, las partes son
separadas en categoras funcionales, tales como clculo, texto, datos, etc. La tabla se llena completando los siguientes pasos para cada
categora:
1. Si los datos tienen una distribucin logartmica normal (como es comn para el caso de los datos de tamao de programa), transformar
los datos en una distribucin normal mediante el clculo del logaritmo natural de cada dato, de no ser as saltarse este pas.
2. Calcular la media (avg) y la desviacin estndar () del conjunto de datos.

3. Calcular los rangos de tamao a travs de VS = avg2; S = avg ; M = avg; L = avg+ ; VL = avg+2 .
4. Si los datos originales tenan una distribucin logartmica normal, aplicar la transformacin inversa mediante el clculo 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 mtodo de estimacin PROBE)
PSP utiliza un proceso de estimacin definido llamado Estimacin basada en proxies (PROBE PROxy Based Estimating). Este mtodo
se utiliza para estimar tanto el tamao como el esfuerzo. Esta rea de conocimiento define cmo se realizan las estimaciones del tamao
mediante el mtodo PROBE.
3.5.1 What is PROBE? (Qu es PROBE?)
PROBE es un procedimiento para estimar el tamao y el esfuerzo. El procedimiento general es el siguiente.
1.
2.
3.
4.
5.
Definir el diseo conceptual (ver 3.5.2).

Identificar y darle tamao a los proxies.
Estimar los otros elementos.
Estimar el tamao del programa. (Seleccione el mtodo PROBE apropiado, como se describe en 3.3.5.)
Calcular los intervalos de prediccin (solamente para los mtodos A y B) (ver 3.5.8).
3.5.2 Conceptual design (diseo conceptual)

El diseo conceptual es una representacin de alto nivel de los elementos del producto y de sus funciones. El diseo conceptual divide
un producto deseado en sus partes principales. El diseo conceptual se utiliza nicamente como una base para construir la estimacin
de tamao y esfuerzo (ver 4.2.4) y no necesariamente refleja cmo el producto real ser diseado y construido.
3.5.3 Formulate size estimates for proxies (Formular las estimaciones del tamao de los proxies)
Compare el tamao de las piezas nuevas en el diseo conceptual contra las partes similares en la base de datos histrica para evaluar
el tipo y tamao relativo. Utilice el nmero de elementos por parte y los datos histricos de tamao por parte para estimar el tamao 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 tamao base (B).

Estimar las Modificaciones (M).

20
Estimar las Eliminaciones (D).

Estimar las Adiciones a la base (BA).
Estimar la Partes Aadidas (PA).
Estimar el Re-uso (R).
Estimar el nuevo re-uso planeado (NR).
3.5.5 Select the appropriate PROBE method (seleccionar el mtodo PROBE adecuado)
1. Compruebe si el mtodo A puede ser utilizado asegurando que los datos cumplen los criterios de abajo, y evaluando la
correlacin de, 0, y 1.
Hay tres o ms puntos de datos (estimados E y reales A&M) que correlacionan.
El valor absoluto de 0 es menor al 25% del tamao esperado del nuevo programa.
1 se encuentra entre 0,5 y 2.
Si el mtodo PROBE A se puede utilizar, entonces calcular el tamao proyectado como y = 0 + 1(E), donde
y = tamao proyectado de adicionadas y modificadas
E = tamao estimado proxy
0 y 1 se calculan utilizando el tamao estimado proxy y el tamao real de adicionadas y modificadas
2. Si el mtodo A no puede ser usado, verifique si el mtodo B se puede utilizar.
Hay tres o ms puntos de datos (A&M planeadas y A&M reales) que correlacionan.
El valor absoluto de 0 es menor al 25% del tamao esperado del nuevo programa.
1 se encuentra entre 0,5 y 2.
Si el mtodo PROBE B se puede utilizar, entonces, calcular el tamao proyectado como y = 0 + 1(E), donde
y = tamao proyectado de adicionadas y modificadas
0 y 1 se calculan utilizando el tamao planeado de adicionadas y modificadas y el tamao real de

adicionadas y modificadas
3. Si los mtodos A y B no puede ser utilizados y se tiene datos histricos, utilice el mtodo C. Calcular el tamao del
proyecto como y = 0 + 1 (E), donde
y = tamao proyectado de modificaciones y adiciones
0 = 0
1 = ActualTotalAdded&ModifiedSizeToDate (Tamao total real a la fecha de adicionadas y modificadas) /

PlanTotalAdded&ModifiedSizeToDate (Tamao total planeado a la fecha de adicionadas y modificadas)
4. Si no hay datos histricos, utilice el mtodo D, que consiste en utilizar el juicio para estimar el tamao de adicionadas y
modificadas.
3.5.6 Estimate program size (Estimar el tamao del programa)
Calcular el tamao del proxy estimado, E = BA + PA + M.
Calcular el tamao proyectado de A&M, P = 0 + 1 (E), para los mtodos A, B, y C. Para el mtodo D, P = juicio profesional
Calcular el tamao de adicionadas planeado, A = A&M M.

Calcular el tamao 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 tamao real del proxy, E = BA+PA+M.
Contar el tamao total real, T.
Calcular el tamao real de adicionadas, A = T-B+D-R.
Calcular el tamao actual de adicionadas y modificadas, A&M = A+M.
Contar el tamao real del nuevo re-uso, NR.
3.5.8 Prediction interval definition (Definicin de intervalo de prediccin)

El intervalo de prediccin se utiliza en los mtodos PROBE A y B. Un intervalo de prediccin es
el rango en que el tamao real es probable que caiga el 70% de las veces
no es un pronstico
aplicable solamente si la estimacin se comporta como los datos histricos
Knowledge Area 3.6: Combining Estimates (La combinacin de estimaciones)

Esta rea de conocimiento describe las distintas maneras en que las estimaciones pueden ser combinadas.
3.6.1 Combine independent estimates (combinar estimaciones independientes)
Utilice este mtodo de combinar estimaciones independientes.
1. Hacer proyecciones de regresin lineal separadas.
21
2. Sumar los tamaos proyectados.

3. Sumar los cuadrados de los rangos individuales y calcule la raz cuadrada para calcular el intervalo de prediccin.
3.6.2 Use multiple proxies (utilizar multiples proxies)
Utilice regresin mltiple cuando hay (a) correlacin entre el tiempo de desarrollo y cada proxy, y (b) los proxies no tienen datos de
tamao por tiempo separados.
1. Identifique y clasifique cada proxy.

2. Utilice regresin mltiple para proyectar el tamao del programa
y = 0 + x11 + x22 + . . . xmm
3. Calcule los intervalos de prediccin.

UPI = projected size + range (70%) (tamao proyectado + rango(70%))
LPI = projected size range (70%)
(tamao proyectado - rango(70%))
Knowledge Area 3.7: Size Estimation Guidelines (Guas para la estimacin del tamao)
Esta rea de conocimiento describe las limitaciones de la estimacin de tamao.
3.7.1 Clustered or grouped data (datos amontonados o agrupados)
Para datos amontonados o agrupados las estimaciones de tamao pueden no ser muy tiles para estimar esfuerzo. Sin embargo, la
estimacin de tamao an puede ser til en el clculo del esfuerzo promedio.
3.7.2 Extreme data points (Puntos de datos extremos)
Puntos extremos de datos pueden llevar a valores errneos de 0 y 1, incluso habiendo alta correlacin. Estimaciones hechas con
puntos fuera de rango de los datos utilizados para calcular 0 y 1 probablemente estarn seriamente equivocadas.
3.7.3 Unprecedented products (Productos sin precedentes)
Resstase a hacer una estimacin antes de terminar un estudio de viabilidad y un desarrollo de prototipos. No confunda el hacer una
estimacin 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 estarn 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 estimacin de tamao del software para planear y dar seguimiento a un
proyecto de software. Partes esenciales de la planificacin del proyecto son la capacidad de construir un calendario, definir tareas,
planear las tareas de conformidad al calendario, y hacer un seguimiento de finalizacin de tareas contra lo planeado. Las reas de
conocimiento principales que componen el rea de competencia son las siguientes:
4.1 PSP Planning Principles (principios de planeacin) Esta rea de conocimiento enuncia los principios sobre los que se basa el
marco de planificacin de PSP.
4.2 The PSP Planning Framework (marco de planificacin de PSP) Esta rea de conocimiento delinea el marco que integra las
tareas de planificacin de PSP, bases de datos histricos, y el seguimiento de las actividades. Tambin incluye el uso de PROBE para
generar estimaciones generales de recursos.
4.3 Software Size and Effort (tamao del software y esfuerzo) La planificacin de proyectos requiere una estimacin del tamao del
software (ver el rea de Competencia 3). En esta rea de conocimiento se describe la relacin entre el tamao y esfuerzo.
4.4 Task and Schedule Planning (planeacin de tareas y calendario) Esta rea de conocimiento describe cmo utilizar una
estimacin general de los recursos para crear un calendario que define las tareas que deben completarse y la fecha esperada de
finalizacin.
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 clculo de EV, usando
el EV para determinar el progreso del trabajo contra el plan y revisar el calendario previsto, con base en el EV promedio obtenido a la
fecha en el proyecto.
4.6 Planning and Tracking Issues (Asuntos con respecto a planeacin y seguimiento) A la administracin se le debe mantener
informada del estatus de proyecto. Los proyectos que no sern terminados a tiempo deben ser re-planeados.
Knowledge Area 4.1: PSP Planning Principles (principios de planeacin)
Esta rea de conocimiento enuncia los principios sobre los que se basa el marco de planificacin de PSP.
4.1.1 Plan your work (planea tu trabajo)
Las personas que hacen el trabajo son los ms adecuados para planificar.
Las personas siempre deben desarrollar un plan de trabajo antes de comprometerse o iniciar un proyecto. Cuando las personas
estn involucradas en el desarrollo del plan, es ms probable que se comprometan con ese plan.
Los planes deben basarse en un proceso definido y datos histricos, y estar hechos con un nivel de detalle apropiado para el
trabajo a realizar.
Cuando es difcil 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 cmo se har

es una base para un acuerdo sobre el costo, calendario y los recursos para un proyecto
es una estructura de organizacin para hacer el trabajo
es un marco para la obtencin 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 ms precisos, proporcionan mtricas ms precisas, y dan una mejor orientacin que los planes de alto nivel. Los planes
detallados tambin permiten que las personas puedan hacer proyecciones precisas y compromisos realistas, ser ms productivos, hacer
un trabajo de ms alta calidad, y mantener su motivacin para alcanzar los objetivos del plan.
Knowledge Area 4.2: The PSP Planning Framework (El Marco de Planificacin de PSP)
Esta rea de conocimiento delinea el marco que integra las tareas de planificacin de PSP, bases de datos histricos, y el seguimiento
de las actividades. Tambin 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 tamao del proyecto: Qu tan grande es el proyecto y cunto tiempo se necesitar para realizar el proyecto completo?
Estructura del proyecto: Cmo se llevar a cabo el trabajo? Cmo deben ser secuenciadas las tareas?
Estado del proyecto: Cul es el estado del proyecto en un momento determinado? Cmo puede estimarse la fecha de
finalizacin?
Evaluacin: Comparar los datos reales contra los estimados. Qu tan bueno fue el plan? Cmo se puede mejorar el plan la
prxima vez?
4.2.2 PSP planning framework (Marco de planificacin de PSP)

El marco de planificacin de PSP consiste en siete tareas bsicas.
1. Definir los requerimientos (ver 4.2.3).
2.
3.
4.
5.
6.
7.
Generar el diseo conceptual (ver 4.2.4).

Generar la estimacin de tamao del producto (ver 3.5.5).
Generar la estimacin de recursos (ver 4.2.6).
Generar el calendario (ver 4.2.10 y 4.5).
Desarrollar el producto (ver 4.2.11).
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 precisin del plan depende de cunto sepan las personas
acerca de la labor a realizar en el momento en que se est planificando.
4.2.4 Produce the conceptual design (Generar el diseo conceptual)
El diseo conceptual (ver 3.5.2) es un acercamiento preliminar al producto, nombra los objetos previstos y sus funciones. Al hacer un
diseo conceptual, varios acercamientos alternativos se pueden considerar para elegir el acercamiento ptimo para hacer el trabajo de
desarrollo. Para productos grandes, varios pasos pueden ser necesarios para generar un diseo conceptual.
Generar una lista preliminar de objetos del producto y sus funciones esperadas.
o
Comience con un diseo 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
histrica (si las hay).
Utilice el mtodo PROBE adecuado para generar estimaciones de recursos y de tamao.

Totalice la estimacin de los elementos para generar la estimacin del producto.
4.2.5 Use PROBE for size and resource estimation (Utilizar PROBE para estimar tamao y recursos)
El mtodo PROBE se utiliza para estimar el tamao del producto y el tiempo necesario para hacer el trabajo (vase 3.5.5 y 4.2.6).
4.2.6 Select the appropriate PROBE method for resource estimation (seleccione el mtodo PROBE adecuado para estimacin
de recursos)
Compruebe si el mtodo A puede ser utilizado.

o
Se tienen tres o ms puntos de datos (E estimada y tiempo real de desarrollo) que correlacionan.
El valor absoluto de 0 es cercano a 0.
1 est dentro del 50% de 1/(productividad histrica).
Si el mtodo A no puede ser usado, revise para ver si el mtodo B se puede utilizar.
o
Se tienen tres o ms puntos de datos (A&M planeadas y tiempo real de desarrollo) que correlacionan.
o
El valor absoluto de 0 es cercano a 0.
1 est dentro del 50% de 1/(productividad histrica).

23
Si el mtodo B no puede ser utilizado y hay datos histricos, utilice el mtodo C.

Si no hay datos histricos, utilice el mtodo 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 ms el tiempo a la fecha
de esa fase en el los proyectos histricos.
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 (Distribucin de tiempo a travs de las fases)
El tiempo planeado se distribuye a travs de fases usando el porcentaje de tiempo histrico a la fecha en fase.
4.2.10 Schedule projection (proyeccin de calendario)
Un calendario de valor ganado proporciona una proyeccin de la fecha de terminacin del proyecto (ver 4.5).
4.2.11 Product development (desarrollo del producto)
El desarrollo de productos es 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 desempeo del costo)
El ndice de desempeo 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 (tamao y esfuerzo del software)
La planificacin de proyectos requiere una estimacin del tamao del software (ver el rea de Competencia 3). En esta rea de
conocimiento se describe la relacin entre el tamao y esfuerzo.
4.3.1 Size and effort correlation (correlacion de tamao con esfuerzo)
Proyectos ms grandes de programacin requieren mayor esfuerzo. Estimar con precisin el esfuerzo de programacin requiere el uso
de una mtrica de tamao que tenga una correlacin significativa con el esfuerzo. Los datos de tamao son adecuados para la
planificacin si el valor de r es ms grande que 0.5 y si y si el rea de la cola en el clculo de la significancia es <= 0,05.
4.3.2 Productivity (productividad)
La productividad es la relacin del tamao de un producto contra el tiempo dedicado a desarrollar este producto, por lo general se es
medida como tamao por hora.
Knowledge Area 4.4: Task and Schedule Planning (planeacin de tareas y calendario)
Esta rea de conocimiento describe cmo utilizar una estimacin general de los recursos para crear un calendario que define las tareas
que deben completarse y la fecha esperada de finalizacin.
4.4.1 Project plan characteristics (Caractersticas del plan de proyecto)
Un plan de proyecto debe ser
accesible: fcil de localizar y de referenciar

claro: concreto y fcil de leer
especfico: responsabilidades y costos identificados
preciso: nivel apropiado de precisin
exacto: basado en datos relevantes y con un proceso de estimacin no prejuiciado
4.4.2 Period plans and project plans (Planes del perodo y planes del proyecto)
Un plan del perodo cubre una unidad de tiempo especfica, tal como una semana o un mes. Un plan del proyecto describe todos los
esfuerzos y 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 tambin 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 terminacin pueden ser estimadas para poder dar
seguimiento del progreso respecto a ellas y los riesgos para su terminacin 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 completarn
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 terminacin.
Las interdependencias de las tareas deben estar definidas.
4.4.7 Estimated task time (tiempo estimado de las tareas)
El tiempo necesario para completar la tarea se estima en una de varias maneras, mediante:
el tamao del producto desarrollado por la tarea y los datos histricos de productos de tareas similares
una estimacin total basada en datos de porcentaje a la fecha de procesos similares terminados
la tcnica de estimacin 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 perodo 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 duracin 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.
2.
3.
4.
Estimar el tiempo de tareas en horas (ver 4.4.7).

Calcular la suma del total de horas planeadas.
Calcular el plazo del plan en el cual cada tarea definida ser terminada, basado en el calendario planeado (vase 4.4.8).
Calcular la fecha planeada para la finalizacin del proyecto.
Knowledge Area 4.5: Schedule Tracking with Earned Value (seguimiento al calendario con valor ganado )
El sistema de Valor Ganado (EV) de PSP se usa para rastrear el progreso del trabajo realizado contra el plan. Esta rea de conocimiento
describe el clculo de EV, usando el EV para determinar el progreso del trabajo contra el plan y revisar el calendario previsto, con base
en el EV 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 tendra un PV de 10.
4.5.2 Earned value (EV) (valor ganado)
El valor ganado es un mtodo 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 mtricas de valor ganado)
Cuando se utiliza EV, tenga en cuenta estas limitaciones.
El mtodo EV supone que la tasa de finalizacin de las tareas en el futuro ser aproximadamente la misma que en el pasado.
Si este no es el caso, la proyeccin de EV no ser exacta.
El mtodo de EV mide el avance con respecto el plan. Si el plan es inexacto, las proyecciones de EV tambin es probable
sern inexactas.
El mtodo de EV asume que los recursos del proyecto son uniformes. Si el nivel de personal aumenta, las proyecciones de EV
sern pesimistas, y si disminuye el personal, las proyecciones sern optimistas.
4.5.4 EV as a measure of actual progress relative to planned progress (EV como una forma de medir el progreso real en
relacin con 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 comparacin 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 ms 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 planificacin, el PV total de las tareas del proyecto se puede calcular para cada perodo de tiempo. Del mismo modo, sumando
los EVs de las tareas terminadas en cualquier perodo 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 (Clculo del PV acumulado para un perodo de tiempo determinado)
El PV acumulado a la fecha para un perodo de tiempo determinado se calcula sumando los PVs 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 perodo de tiempo determinado y el EV acumulado para ese mismo perodo 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 (Estimacin de la fecha de terminacin del proyecto)
La fecha estimada de terminacin del proyecto se puede calcular mediante el clculo del EV promedio por semana a la fecha, y a
continuacin utiliza el valor promedio de EV por semana para calcular el tiempo necesario para completar el valor planeado restante.
Esto asume que el proyecto contina ganando la tasa promedio de EV como antes.
Knowledge Area 4.6: Planning and Tracking Issues (Planeacion y seguimiento de Issues)
A la administracin se le debe mantener informada del estatus de proyecto. Los proyectos que no sern 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 anlisis de valor ganado e infrmeles 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 mtodos 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 problemticas porque las horas de tareas (task hours) se dividen entre varios proyectos. El
cambio frecuente entre las tareas hace difcil el trabajo en cualquier tarea y obstaculiza la coordinacin con otros miembros de equipo en
un proyecto.
Competency Area 5: Planning and Tracking Software Quality (planeacin y seguimiento a la calidad del software)
Esta rea de competencia describe la necesidad de construir productos que satisfagan las necesidades de los usuarios, las formas de
medir el grado de satisfaccin de las necesidades del usuario, y las 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 (mtricas de calidad) Los datos de PSP permiten la determinacin de mtricas de calidad de producto y del
proceso as como de la eficacia del proceso en la eliminacin de defectos.
5.3 Quality Methods (Mtodos de Calidad) Las revisiones personales son una manera eficaz y efectiva de mejorar la calidad del
producto y la productividad individual. Los diversos mtodos de revisin son eficaces en diversas situaciones.
5.4 PSP Code Reviews (revisiones de codigo) Las revisiones de cdigo deben seguir un proceso definido y usar checklists (listas de
verificacin) basados en los datos de defectos personales. La consistencia en el seguimiento de una estrategia de revisin basada en
la experiencia puede hacer las revisiones ms eficientes y eficaces.
5.5 PSP Design Reviews (revisiones de diseo) Las revisiones de diseo deben seguir un proceso definido de revisin incluyendo
anlisis de diseo apropiado y usando checklists (listas de verificacin) basados en principios de diseo slidos. La consistencia en el
seguimiento de una estrategia de revisin basada en experiencia medida, puede hacer revisiones ms 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 gestin de su tiempo personal, y mantener la calidad como la mxima prioridad.
5.1.2 The economics of quality (la economa de la calidad)
Es menos costoso encontrar y corregir los defectos antes en un proceso, que despus.
Cuanto ms tiempo permanece un defecto en un producto, mayor ser el costo para extraerlo.
Las pruebas son una manera ineficiente e ineficaz para eliminar defectos.
Es ms eficiente prevenir los defectos que encontrarlos y corregirlos
La manera correcta es siempre la manera ms rpida y ms barata de producir un resultado de alta calidad.
Las revisiones son fundamentalmente ms eficientes que las pruebas para encontrar y corregir defectos.
5.1.3 Product quality (La calidad del producto)

Un producto de calidad es aquel que satisface al cliente. Este producto debe satisfacer un umbral mnimo de funcionalidad y utilidad. El
producto tambin debe satisfacer las expectativas del usuario con respecto a algunos otros criterios.
El producto debe funcionar, es decir, desempearse con una coherencia razonable. Si este objetivo no se logra, nada ms
importa. Inquietudes adicionales de los usuarios podran incluir
o
o
o
o
o
rendimiento
seguridad
invulnerabilidad
usabilidad
funcionalidad
El producto debe proporcionar la funcionalidad que el usuario necesita y en el momento que la necesita. En muchos proyectos
de desarrollo, la percepcin de calidad de los usuarios es con frecuencia pasada por alto ya que los individuos pasan la mayor
parte de su tiempo encontrando y eliminando los defectos.
5.1.4 Process quality (calidad del proceso)

Un proceso de calidad debe satisfacer las necesidades de sus usuarios para construir productos de calidad de manera eficiente. Un
proceso de calidad debe
construir productos de calidad consistentemente

ser utilizable y eficiente
ser fcil de aprender y adaptarse a las nuevas circunstancias
Knowledge Area 5.2: Quality Measures (mtricas de calidad)

Los datos de PSP permiten la determinacin de mtricas de calidad de producto y del proceso as como de la eficacia del proceso en la
eliminacin de defectos.
5.2.1 Personal defect data (datos personales de defectos)
Los datos personales de defectos son tiles para comprender y refinar el proceso personal. El anlisis de estos datos proporciona un
recurso valioso para la construccin de Listas de verificacin (checklists) personales de revisin.
5.2.2 To-date defects injected and removed (defectos insertados y removidos a la fecha)
Los defectos insertados y removidos a la fecha son la suma de los defectos reales inyectados y removidos para cada fase del proyecto,
ms los defectos insertados y removidos a la fecha por fase de los proyectos histricos.
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 mtrica 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 compilacin (o antes de entrar a pruebas de
unidad si no hay fase de compilacin).
5.2.7 Review Yield (yield (rendimiento) de revisin)
Yield de revisin es el porcentaje de defectos en el programa encontrados durante la revisin.

27
5.2.8 Percent appraisal cost of quality (COQ) (Porcentaje de costo de evaluacin de la calidad COQ)
Porcentaje de costo de evaluacin de la calidad COQ es el porcentaje de tiempo de desarrollo empleado en revisin de diseo y de
cdigo.
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 evaluacin y correccin. COQ define los asuntos relativos a
la calidad en trminos de gerencia y del negocio. Las principales mtricas de COQ son:
performance costs: los costos de hacer el trabajo en primer lugar

appraisal costs: el costo de examinar un producto para determinar su calidad
failure costs: los costos de la correccin de un producto defectuoso, incluyendo todos los costos derivados de las deficiencias
del producto.
prevention costs: los costos de la elaboracin e implementacin de acciones para prevenir fallas
5.2.11 COQ appraisal to failure ratio (COQ A/FR) (COQ relacin de evaluacin / fallas)
COQ A/FR es la proporcin de tiempo invertido en tareas de evaluacin con respecto al tiempo invertido en tareas de correccin de fallas.
5.2.12 Defect Density (densidad de defectos)
Densidad de defectos es el nmero de defectos detectados por medida de tamao. Se normaliza al tamao del producto para permitir
la comparacin de diversos productos y procesos que los construyeron.
5.2.13 Process Quality Index (PQI) (ndice de calidad del proceso)
El ndice de calidad del proceso (PQI) es una mtrica derivada que caracteriza la calidad de un proceso de desarrollo del software. El
valor de PQI es el producto de cinco valores de componentes de perfil de la calidad.
1.
2.
3.
4.
5.
Calidad de diseo se expresa como la proporcin del tiempo de diseo entre el tiempo de codificacin.
Calidad de revisin del diseo es la proporcin de tiempo de revisin de diseo entre el tiempo de diseo.
Calidad de revisin de cdigo es la proporcin del tiempo de revisin de cdigo entre el tiempo de codificacin.
Calidad de codificacin es la proporcin de defectos de compilacin entre medida de tamao.
Calidad del programa es la proporcin de defectos en pruebas de unidad entre una medida de tamao.
Los componentes PQI se normalizan a [0, 1] tal que el cero representa una mala prctica y el uno representa la prctica deseada. Las
proporciones se representan en los ejes de un pentgono con la escala [0, 1]. El polgono resultante puede ser comparado con el
pentgono que lo contiene para determinar la calidad del proceso. Los valores recomendados para cada componente PQI son los
siguientes.
Calidad del diseo es el mnimo de 1,0 o el tiempo empleado en hacer diseo detallado, dividido entre el tiempo empleado en
codificacin.
Calidad de revisin de diseo es el mnimo de 1,0 o dos veces el tiempo empleado en la revisin del diseo detallado dividido
entre el tiempo empleado en el diseo detallado.
Calidad de revisin de Cdigo es el mnimo de 1,0 o dos veces el tiempo empleado en la revisin de cdigo dividido entre el
tiempo empleado en la codificacin.
Calidad de la revisin de cdigo es el mnimo de 1,0 o dos veces el tiempo empleado en la revisin de cdigo dividido por el
tiempo empleado en la codificacin.
Calidad del cdigo es el mnimo de 1,0 o 20/(10 + Defectos/KLOC en compilacin).

Calidad del programa es el mnimo de 1,0 o 10/(5 + Defectos/ KLOC en pruebas de unidad).
5.2.14 Calculating values for the PQI components (Clculo de los valores de los componentes PQI)
Para calcular e interpretar los valores PQI:
Multiplicar las cinco mtricas de elementos PQI juntas para dar un nmero entre 0,0 y 1,0.
Los valores inferiores a 0,5 indican que el producto es probable que sea de mala calidad. Cuanto menor sea el valor, ms
pobre probablemente ser la calidad.
5.2.15 Composite PQI (PQI Compuesto)
Una mtrica PQI compuesta representa la calidad del proceso global para un proyecto que construy mltiples programas. Este PQI
compuesto se puede calcular de tres formas, cada uno de los cuales tiene ventajas y desventajas.
1.
2.
La mtrica del PQI del producto se calcula tomando el producto de todos los PQI de los componentes del programa.
a.
Ventaja: Esta medida indicar rpidamente 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 gestin de calidad del
sistema.
La mtrica 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 sera la suma de los tiempos de

28
revisin para todos los elementos de programa y los defectos de pruebas de unidad seran la densidad total de defectos para
todos los programas combinados.
a.
Ventaja: Esta mtrica tiene la ventaja de ser fcil de calcular y proporcionar un indicador general de la calidad global del
producto.
b.
Desventaja: Algunos pocos componentes de mala calidad podrn ser escondidos por un gran nmero de componentes
de alta calidad.
3.
La medida mnima de PQI se calcula utilizando el valor de PQI para el componente de programa que tenga el valor de PQI
mnimo.
a.
Ventaja: Esta medida tiene la ventaja de la rpida localizacin 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 mtrica compuesta para todos los propsitos, las mtricas 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 correccin de defectos de la fase es el nmero de defectos encontrados por hora en esa fase.
5.2.17 Review Rate (tasa de revisin)
La tasa de revisin se refiere al tamao del producto revisado por hora. Esta tasa se calcula tanto para la fase de revisin como de
inspeccin (ver 5.3.3).
5.2.18 Defect-removal leverage (DLR) (Apalancamiento de eliminacin de defectos)
Defect-removal leverage es una medida de la eficacia relativa de la eliminacin de defectos entre dos fases cualquiera del proceso. Por
ejemplo, el DRL para la revisin del diseo con respecto a las pruebas de unidad se define como DRL (DR / UT) = defectos por hora en
revisin del diseo dividido entre defectos por hora en la prueba de la unidad.
Knowledge Area 5.3: Quality Methods (Mtodos de Calidad)
Las revisiones personales son una manera eficaz y efectiva de mejorar la calidad del producto y la productividad individual. Los diversos
mtodos de revisin son eficaces en diversas situaciones.
5.3.1 Personal reviews (revisiones personales)
Una revisin 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 (codificacin, compilacin,
prueba, inspeccin, etc.).
5.3.2 Personal review principles (principios de revisin 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 verificacin) derivado de los datos personales de defectos.
Siga un proceso estructurado de revisin.
Siga prcticas solidas de revisin.
Mida las revisiones.
Use los datos para mejorar las revisiones
Construya productos revisables.
Utilice datos para identificar dnde 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 inspeccin es una revisin estructurada en equipo de un componente o producto. El objeto de una inspeccin es identificar problemas
en el producto. Las inspecciones se conducen segn un procedimiento definido en que los asistentes desempean roles establecidos.
En una inspeccin realizada correctamente, los participantes no discuten los problemas identificados ni intentan solucionarlos.
5.3.4 Walkthroughs (recorridos)
Un walkthrough es menos formal que una inspeccin. Un producto, como un diseo o un segmento de cdigo, se presenta a una audiencia
que plantea posibles problemas y hace preguntas.
5.3.5 Relationship between reviews and inspections (relacin entre las revisiones y las inspecciones)
Una revisin personal debe preceder a cualquier inspeccin. Una revisin antes de la inspeccin asegura que los inspectores buscan
cuestiones finas, en lugar de errores evidentes.
5.3.6 Conducting effective personal reviews (conducir revisiones personales efectivas)
Para lograr revisiones eficaces y eficientes, estas prcticas deben ser seguidas.
Tmese un descanso entre el trabajo y la revisin.
Haga la revisin de productos en forma impresa, y no en medios electrnicos.
Marque cada punto cuando se vaya completando.

29
Actualice los checklists de revisin peridicamente para reaccionar a los cambios en los datos personales.
Construya y utilice un checklist diferente para cada mtodo de diseo, lenguaje de programacin o tipo de producto.
Analice y verifique a conciencia cada construccin no trivial del diseo (ver 6.6).
Knowledge Area 5.4: PSP Code Reviews (revisiones de cdigo en PSP)

Las revisiones de cdigo deben seguir un proceso definido y usar checklists (listas de verificacin) basados en los datos de defectos
personales. La consistencia en el seguimiento de una estrategia de revisin basada en la experiencia puede hacer las revisiones ms
eficientes y eficaces.
5.4.1 Code review checklist (checklist de revisin de cdigo)
Un checklist de revisin de cdigo es especfico para el proceso de codificacin de un individuo. Este checklist lista las categoras de los
defectos que han causado problemas en el pasado, para que estos defectos sean verificados durante la revisin.
5.4.2 PSP code review process (proceso de revisin de cdigo en PSP)
El proceso de la revisin de cdigo en PSP es como sigue.
1. Obtenga el checklist de revisin de cdigo, estndar de codificacin, y estndar de defectos.
2.
Imprima una copia del cdigo para ser revisado.
3.
Para cada categora de defecto en el checklist, hacer una pasada completa sobre el cdigo y marque cada punto a medida
que se va completando.
4.
Corregir todos los defectos y comprobar cada correccin de defectos para asegurar sea correcta.
5.4.3 Code review strategy (estrategia de revisin de cdigo)

Una estrategia de revisin deber basarse en datos que muestran que la estrategia sea eficaz. Una estrategia inicial consiste en examinar
primero los mdulos de bajo nivel de tal manera que las abstracciones procedurales sean revisadas y entendidas antes que las de ms
alto nivel. Despus 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 diseo, diversas estrategias de revisin pueden ser apropiadas.
5.4.4 Review against a coding standard (revisin contra un estndar de codificacin)
Las revisiones de cdigo deben verificar el cumplimiento de estndares de codificacin. Los estndares aplicables de codificacin deben
referenciarse en los checklist de revisin de cdigo.
Knowledge Area 5.5: PSP Design Reviews (revisines de diseo PSP)
Las revisiones de diseo deben seguir un proceso definido de revisin incluyendo anlisis de diseo apropiado y usando checklists (listas
de verificacin) basados en principios de diseo slidos. La consistencia en el seguimiento de una estrategia de revisin basada en
experiencia medida, puede hacer revisiones ms eficientes y eficaces.
5.5.1 Design review principles (principios de revisin de diseo)
Produzca diseos que puedan ser revisados

Siga una estrategia de revisin explicita.
Revise el diseo en etapas.
Compruebe que la lgica implementa correctamente los requerimientos.
Revise asuntos de vulnerabilidad y seguridad.
5.5.2 Design review checklist (checklist de revisin de diseo)

Un checklist de revisin de diseo es especfico para el proceso de codificacin de un individuo. El checklist se basa en datos de defectos
personales y lista las categoras de los defectos que han causado problemas en el pasado, para que estos defectos sean verificados
durante la revisin.
5.5.3 PSP design reviews (revisions de diseo en PSP)
El proceso de revisin del diseo en PSP es el siguiente.
1.
Obtenga el checklist de revision de diseo y los estndares de diseo y de defectos.
2.
3.
Imprima una copia del diseo a ser revisado, si es pertinente.

Para cada categora de defecto en la lista, hacer una pasada completa sobre el diseo y marque cada punto a medida que se
va completando.
4.
Corregir todos los defectos y comprobar cada correccin de defecto para asegurar sea correcta.
5.
Analice todas las construcciones complejas del diseo para verificar sean correctas (ver 6.6).
5.5.4 Design review strategy (estrategia de revisin de diseo)

Una estrategia de revisin deber basarse en datos que muestren que la estrategia es eficaz. Despus de que una estrategia ha
determinado ser eficaz, debe ser seguida 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 revisin)
Las revisiones del diseo y de cdigo encuentran defectos directamente, ayudando al revisor a generar una imagen mental del
comportamiento previsto del programa. En procesos de desarrollo de grandes sistemas, las revisiones del diseo y de cdigo son
especialmente importantes porque los mtodos incrementales de PSP requieren que todos los incrementos sean de alta calidad. Para
garantizar que los sistemas de gran escala alcancen la misma alta calidad que los sistemas ms pequeos, los scripts de PSP deben
seguirse, y cada mdulo y/o incremento debe ser sometido a revisiones de diseo, revisiones de cdigo, y pruebas de regresin para
garantizar que los nuevos incrementos no causen problemas con mdulos funcionales previamente probados y aceptados.
5.6.2 Reviewing before or after compiling (Revisar antes o despus de compilar)
Muchos entornos de desarrollo utilizan analizadores automticos de cdigo y/o compiladores que son muy tiles, su uso no se
desincentiva. Sin embargo, para ser ms eficaz, la revisin debera ser realizada antes de usar el analizador de cdigo o el compilador.
Las revisiones de cdigo deben realizarse antes de las pruebas.
5.6.3 Review objectives (objetivos de la revisin)
Las revisiones de cdigo 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 revisin probablemente ser ineficaz. Las
personas cuyo objetivo es comenzar a probar lo antes posible, rara vez realizan revisiones de cdigo o las hacen tan mal que son una
prdida de tiempo.
Competency Area 6: Software Design (Diseo de Software)

El rea de competencia de diseo de software describe la capacidad de incorporar el diseo y las actividades de verificacin de diseo
en un proceso personal de desarrollo de software. Las reas de conocimiento principales que componen esta rea de competencia son
las siguientes:
6.1 Software Design Principles (Principios de diseo de Software) Esta rea de conocimiento se describen los principios de diseo
de software incorporados en PSP.
6.2 Design Strategies (Estrategias de Diseo) Esta rea de conocimiento aborda las estrategias de diseo utilizadas en PSP.
6.3 Design Quality (Calidad en el Diseo) Esta rea de conocimiento describe las caractersticas clave que se pueden utilizar para
evaluar la calidad de un diseo de software.
6.4 Design Documentation (Documentacin del Diseo) Los diseos de software se deben documentar, junto con los requerimientos
relacionados, las limitaciones, y las justificaciones. Esta rea de conocimiento describe la documentacin de diseo que es
responsabilidad de la persona.
6.5 Design Templates (Plantillas de Diseo) El PSP no especifica tcnicas de diseo, pero proporciona a un conjunto de plantillas
como marco para la documentacin del diseo. Las plantillas ayudan a asegurar que un sistema y sus mdulos estn completa y
precisamente implementados.
6.6 Design Verification (Verificacin del Diseo) Para ser eficaz, la revisin de diseo debe ir ms all de la simple lectura a travs
de un documento de diseo. El PSP ofrece una serie de tcnicas de verificacin de diseo que pueden ser utilizadas para identificar los
errores y omisiones en los diseos de software.
Knowledge Area 6.1: Software Design Principles (Principios de diseo de Software)
Esta rea de conocimiento describe los principios de diseo de software incorporado en PSP.
6.1.1 Definition of software design (Definicin de Diseo de Software)
Un diseo de software transforma un requerimiento dbilmente definido en una especificacin de producto realizable.
6.1.2 The design process (El proceso de diseo)
Un proceso de diseo es el conjunto de pasos que se utilizan dentro de una metodologa para crear un diseo. El proceso de diseo
debe dar lugar a una visin global de la solucin del requerimiento, que es clarificada con los detalles de bajo nivel de la implementacin.
No construye la solucin sino explora el espacio de solucin potencial y toma decisiones sobre la estructura y el comportamiento del
producto previsto.
6.1.3 The role of design in the overall software development process (El role del diseo dentro del proceso general de
desarrollo de Software)
El diseo de software conecta los requisitos de un sistema a su implementacin. Con el uso apropiado de la abstraccin, maneja la
complejidad y se asegura de que los componentes de sistema trabajen juntos para producir los resultados deseados.
6.1.4 The requirements uncertainty principle (El principio de incertidumbre del diseo)
Debido a que un nuevo sistema afecta a los usuarios y cambia sus necesidades, los requisitos para un sistema informtico a menudo no
se conocen completamente hasta despus que el producto terminado se pone en uso. El proceso de diseo debe proporcionar a una
base estable para esta evolucin continua.
6.1.5 The role of design in PSP (El rol de diseo en PSP)
Los componentes bien diseados son crticos para el xito de los sistemas ms grandes que los usan. Los individuos deben emplear
prcticas de diseo que puedan satisfacer las exigencias de la compleja y dinmica evolucin de los sistemas.
31
6.1.6 Design methodology in PSP (Metodologa de Diseo en PSP)

El PSP no prescribe el uso de alguna metodologa especfica de diseo, pero s define los requisitos para la documentacin de diseo.
6.1.7 Design specification structure (Estructura de la epecificacin de diseo)
Los elementos de un diseo completo se pueden especificar usando la siguiente estructura de especificacin.
externa- esttica (herencia, estructura de clases)

externa- dinmica (servicios, mensajes)
interna-esttica (atributos, estructura del programa, lgica)
interna-dinmica (mquina de estado)
6.1.8 Need for design precision (Necesidad de la precisin en el diseo)

Una especificacin de diseo debe ser precisa. La falta de un diseo preciso es la fuente de muchos errores de implementacin. Para
obtener mejor precisin del diseo, especifique y documente las decisiones de diseo antes de entrar a la fase de codificacin del
proceso.
Knowledge Area 6.2: Design Strategies (Estrategias de Diseo)
Esta rea de conocimiento aborda las estrategias de diseo utilizadas en PSP.
6.2.1 The need for design strategies (La necesidad de estrategias de diseo)
El diseo es un proceso intelectual complejo que no puede ser automatizado, reducido a un procedimiento rutinario, o precisamente
controlado ni pronosticado; sin embargo, algunas guas y estrategias pueden ser aprovechadas en la separacin de actividades rutinarias
y creativas, para asegurarse de que el trabajo de diseo es realizado correctamente y para identificar herramientas y mtodos de diseo
eficaces.
6.2.2 Nature of the design process (Naturaleza del proceso de diseo)
El diseo es un proceso de aprendizaje que requiere comnmente moverse entre niveles de diseo y de una parte del sistema a otra.
6.2.3 Design process guidelines (Guas del proceso de diseo)
Cuando sea prctico, termine los diseos de alto nivel primero.

Registrar todos los supuestos, cuestiones pendientes, preguntas y problemas.
Cuando sea apropiado, use prototipos o experimentacin para reducir la incertidumbre antes de disear.
No considere un diseo como terminado hasta que los diseos de todos los componentes interdependientes tambin se
terminen.
Documente todo el diseo (ver 6.6).
6.2.4 Types of design strategies (Tipos de estrategias de diseo)

Las estrategias de diseo pueden incluir las siguientes:
Progresiva (progressive)
Expansin funcional (Functional enhancement)
Camino Rpido (fast-path)
Simulacin (dummy)
Knowledge Area 6.3: Design Quality (Calidad en el Diseo)

Esta rea de conocimiento describe las caractersticas clave que se pueden utilizar para evaluar la calidad de un diseo de software.
6.3.1 Design precision (Precisin del Diseo)
Los diseos deben ser consistentes y sin ambigedades. El diseo debe contener suficiente detalle para todos los usos previstos de la
documentacin de diseo.
6.3.2 Design completeness (Completitud del Diseo)
Todos los detalles relevantes deben ser incluidos, sin redundancia innecesaria.

32
La documentacin de diseo no debe limitarse a los diseos de componentes individuales, sino que tambin debera
documentar el sistema en su conjunto y las consideraciones emergentes.
Es til incluir la justificacin de las decisiones de diseo; es a menudo provechoso documentar las alternativas que no fueron
elegidas.
6.3.3 Design usability (Usabilidad del diseo)

El diseo debe ser accesible y comprensible por todos sus usuarios.
Knowledge Area 6.4: Design Documentation (Documentacin del Diseo)
Los diseos de software se deben documentar, junto con los requerimientos relacionados, las limitaciones, y las justificaciones. Esta rea
de conocimiento describe la documentacin de diseo que es responsabilidad de la persona.
6.4.1 The need for software design documentation (La necesidad de documentar el diseo)
Los diseos de software se deben documentar, junto con los requerimientos relacionados, las limitaciones, y las justificaciones, debido
a que el diseo, a menos de que se trate de programas pequeos, es necesario para las personas que estarn involucradas con los
productos consiguientes. Algunos ejemplos a continuacin.
El individuo: para facilitar implementacin, verificacin, prueba del programa
Los miembros del equipo: para permitir las inspecciones de diseo y la coordinacin de diseo
Testers: para permitir la planeacin de las pruebas.
Administradores: para facilitar la ampliacin y las correcciones del producto

Documentadores y usuarios: para que otros puedan entender lo que el producto hace y cmo funciona
6.4.2 Overall design documentation concerns (Preocupaciones generales sobre la documentacin del diseo)
Para garantizar que la documentacin de diseo siga representando el producto, la documentacin de diseo debe ser auto consistente,
y los cambios deben ser administrados y debidamente documentados.
6.4.3 Common types of design documentation (Tipos comunes de documentacin del diseo)
El individuo produce documentacin de diseo que cubre
el contexto del programa

la estructura del programa
componentes relacionados
variables externas, llamadas y referencias
descripcin detallada de la lgica de programacin para las decisiones de diseo, es a menudo provechoso documentar las
alternativas que no fueron elegidas
6.4.4 Design visibility (Visibilidad del diseo)

La documentacin del diseo proporciona la representacin visible de un diseo, usada para las revisiones y verificaciones. El diseo se
registra usando una notacin apropiada de diseo (ver 6.5.1).
6.4.5 Design documentation practice (Practica de documentacin del diseo)
Una prctica til en la implementacin de un diseo es comenzar con el diseo del programa completo y conforme cada seccin del
diseo es implementada, encapsular ese segmento de diseo en un comentario inmediatamente antes de la implementacin.
Knowledge Area 6.5: Design Templates (Plantillas de Diseo)
El PSP no especifica tcnicas de diseo, pero proporciona a un conjunto de plantillas como marco para la documentacin del diseo.
Las plantillas ayudan a asegurar que un sistema y sus mdulos estn completa y precisamente implementados.
6.5.1 Design notation (Notacin de diseo)
Una notacin basada en lgica matemtica puede ayudar en la generacin de documentacin de diseo, concisa y sin ambigedades.
Ejemplos de ello son seudocdigo y Zed. Los siguientes criterios deben seguirse cuando se selecciona una notacin de diseo adecuada.
La notacin de diseo debe ser capaz de representar de manera precisa y completa el diseo.
Debe ser comprensible y til para la gente que va a usar y/o implementar el diseo.
Debe ayudar a los diseadores para producir un diseo de alta calidad.
Debe ser compatible con el lenguaje de implementacin que se utilizar.
Debe permitir rangos variables de dependencia en la implementacin

6.5.2 PSP design templates (Pantillas de diseo)
Las plantillas de diseo de PSP representan la estructura esttica y el comportamiento dinmico de un sistema informtico, capturando
tanto las caractersticas externamente visibles como los detalles internos (ver 6.1.6). Un diseo completo en PSP debera contener las
siguientes cuatro categoras o elementos de diseo
externa-dinmica: Use la plantilla de especificacin operacional (OST) y la plantilla de especificacin funcional (FST) para
registrar esta informacin (ver 6.5.3 y 6.5.4).
externa-esttica: Use la plantilla de especificacin funcional (FST) para registrar esta informacin (ver 6.5.4).

33
interna-dinmica: Use la plantilla de especificacin de estados (SST) para registrar esta informacin (ver 6.5.5).
interna-esttica: Use la plantilla de especificacin lgica (LST) para registrar esta informacin (ver 6.5.6).
6.5.3 Operational specification template (OST) (Plantilla de especificacin operacional - OST)

El OST documenta las caractersticas externa-dinmicas de una parte de un sistema informtico. Describe uno o ms escenarios que
involucran a la parte y los actores (ej. usuarios de otros sistema) que interactan 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
accin
comentarios
6.5.4 Functional specification template (FST) (Plantilla de especificacin funcional - FST)

El FST documenta una parte (ej. una clase) de un sistema de software, sus relaciones externa-estticas, y sus atributos externos visibles.
El FST tambin documenta las caractersticas externas-dinmicas de una parte. Describe las acciones (ej., mtodos de una clase) que
la parte pone disponibles para uso externo, esta descripcin incluye la interfaz definida para cada accin, incluyendo argumentos,
restricciones y resultados devueltos.
6.5.5 State specification template (SST) (Plantilla de especificacin de estados SST)
El SST documenta el comportamiento interno-dinmico 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 grficamente los estados, las condiciones de la transicin, y las
acciones. Un SST contiene
nombre y descripcin de los estados

las funciones y los parmetros internos usados en la condiciones de transicin
detalles de la transicin de estados
o
estado actual
o
estado siguiente
o
condicin de transicin (predicado)
o
accin que se realiza cuando ocurre la transicin
6.5.6 Logic specification template (LST) (Plantilla de especificacin lgica - LST)

El LST documenta las caractersticas interno-estticas de una parte de un sistema de software. Describe la lgica interna de la parte,
usando pseudocdigo para explicar clara y concisamente su operacin. Considere que la informacin del LST puede estar embebida
como comentarios en el cdigo 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 diseo PSP pueden ser
utilizadas para documentar un diseo producido a partir de diferentes tcnicas de diseo

utilizadas para documentar el diseo de un sistema de software existente, para apoyar su rediseo o verificacin
complementadas o sustituidas parcialmente por otras tcnicas de documentacin de diseo (ej. UML), siempre y cuando
informacin equivalente del diseo se registre en un formato fcilmente usable
aplicado en diversos niveles de la jerarqua del diseo
Knowledge Area 6.6: Design Verification (Verificacin del Diseo)

Para ser eficaz, la revisin de diseo debe ir ms all de la simple lectura a travs de un documento de diseo. El PSP ofrece una serie
de tcnicas de verificacin de diseo que pueden ser utilizadas para identificar los errores y omisiones en los diseos de software.
6.6.1 Design standards (Estndares de diseo)
Los diseos de software se pueden verificar contra estndares que promuevan consistencia y calidad. Estos estndares pueden incluir
convenciones de producto
estndares de diseo de producto
estndares de re-uso
6.6.2 Verification methods (Mtodos de verificacin)

Los mtodos de verificacin de software incluyen:
verificacin con tabla de ejecucin

verificacin con tabla de rastreo
verificacin de mquina de estados
verificacin de ciclos
otros mtodos analticos de verificacin

34
6.6.3 Choosing the appropriate design verification method (Seleccin del mtodo de verificacin adecuado)
Analice sus datos personales de defectos para determinar qu aspectos de diseo son ms propensos a defectos. No es un
uso prudente del tiempo verificar aspectos de diseo donde se cometen pocos (o ningn) defectos.
Evaluar la eficacia de los mtodos de verificacin actuales. Identificar un conjunto de tcnicas eficaces y usarlas, incluso en
programas pequeos.
Considere la economa de las tcnicas de verificacin actuales. Elija los mtodos de verificacin que sean ms eficaces
personalmente y que apliquen mejor a las condiciones del diseo.
6.6.4 Using execution table verification (Uso de verificacin con la tabla de ejecucin)
Identificar ciclos y rutinas complejas para la verificacin.

Elija la orden del anlisis (ej. de arriba a abajo o de abajo para arriba).
Construya una tabla de ejecucin con los pasos del programa y valores relevantes de las variables, usando mltiples copias
para iteraciones de ciclos.
Verificar los resultados de la ejecucin con respecto a la especificacin de requerimientos.
6.6.5 Using trace-table verification (Uso de verificacin con la tabla de rastreo)
Identifique los casos lgicos representativos para el anlisis.

Para cada caso lgico, verifique usando una tabla de ejecucin.
6.6.6 Execution table verification vs. trace-table verification (Verificacin con tabla de ejecucin vs. Verificacin con tabla de
rastreo)
Distinga entre la verificacin con tabla de ejecucin y verificacin con tabla de rastreo, y sepa cuando utilizar cada una.
6.6.7 Using state-machine verification (Uso de la verificacin de la mquina de estados)
Revise la estructura de la mquina de estados para asegurarse que no tiene trampas o ciclos ocultos, usando un diagrama de
estado, si es prctico
Examine cada estado y verifique que el conjunto de transiciones de ese estado es completo (definido para todos los posibles
valores de condiciones de transicin).
Examine cada estado y verifique que las transiciones asociadas del estado son ortogonales (solamente una transicin definida
para cada conjunto de valores de la condicin de la transicin).
6.6.8 Using loop verification (Uso de la verificacin de ciclos)

Verificar el inicio de ciclos, incremento, y terminacin, utilizando los mtodos de verificacin apropiados al tipo de ciclo
Verificacin de ciclos for

Verificacin de ciclos while
Verificacin de ciclos repeat-until
Competency Area 7: Process Extensions and Customization (Extensin y adaptacin del proceso)
El rea de conocimiento extensin y adaptacin del proceso describe las modificaciones al PSP que son requeridas cuando se escala
de pequeos a ms 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 (Evolucin 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 evolucin incremental de un proceso inicial a uno que es una descripcin
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 prcticas 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 mtodos: lo que funciona bien en un ambiente puede no ser eficaz en otro. Por ejemplo, las
tareas de programacin simple pueden requerir poco o nada de tiempo de diseo. Sin embargo, sistemas ms grandes o sistemas de
alta seguridad (independientemente de su tamao), requieren un diseo robusto. Un proceso sin una etapa de diseo puede requerir
adecuacin para incluir esta actividad a la hora de adaptar un proceso existente para cubrir una nueva situacin, 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 definicin de un proceso personal nuevo o la adaptacin sigue los mismos principios que para el desarrollo de software: comenzar
con las necesidades del usuario y terminar con la prueba final y la liberacin. Hay ocho pasos generales para la adaptacin o la creacin
de un proceso personal.
1.
2.
Determinar las necesidades y prioridades.

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 informacin 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 informacin
[Horn 90].
Chunking (particionar): Organizar la informacin 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 informacin.
Consistency (consistencia): Use trminos consistentes entre cada parte de la informacin, entre la parte y la etiqueta, en la
organizacin de la informacin y al definir el formato del documento o instrumento en el que la informacin es registrada.
Integrate graphics (integrar grficas): Usar tablas, ilustraciones y diagramas, como parte integral de la documentacin.
Accessible detail (detalle accesible): Escribir al nivel de detalle que haga el documento sea til para todos los lectores.
Hierarchy of chunking and labeling (Jerarqua de Etiquetamiento y particionamiento): Agrupar pequeas partes en un elemento
relevante y dar a cada grupo una etiqueta.
Knowledge Area 7.2: Process Evolution (Evolucin 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
evolucin incremental de un proceso inicial a uno que es una descripcin exacta y completa del proceso real.
7.2.1 Initial process definition (Definicin Inicial del proceso)
Las descripciones de proceso iniciales raramente son exactas, debido a un fenmeno anlogo al principio de incertidumbre de
Heisenberg: el acto de definir un proceso cambia ese proceso. La descripcin inicial del proceso contiene generalmente omisiones,
idealizaciones, y otras inexactitudes. El proceso de describir exactamente 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 caracterizacin 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, estndares y mtricas 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 prcticas de profesionales responsables.
7.3.1 Use effective methods in your work (Uso de mtodos efectivos en el trabajo)
Las buenas prcticas son sencillas, pero muy pocas personas las utilizan consistentemente. El profesional dedicado encuentra mtodos
efectivos para producir consistentemente trabajo de alta calidad y usa esos mtodos.
7.3.2 Use data to discover your strengths and weaknesses (Uso de datos para descubrir sus debilidades y fortalezas)
Utilice el anlisis post mortem de los datos personales para construir una comprensin de lo que se hace bien y de las reas donde se
necesita mejorar. Cntrese en llevar a cabo pequeas mejoras regularmente, y los cambios importantes vendrn por si solos.
7.3.3 Practice (Prctica)
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 ensee lo que sabe)
Hable con sus colegas y revise la literatura para aprender nuevas tcnicas y aprender de los errores de otros. A medida que aprenda,
comparta lo que ha aprendido con los dems. 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 mtodos)
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 da, el empleado se hace ms atractivo para su empleador actual (y para los
futuros empleadores) como un profesional competente y deseable.


PSPBOK - EspaÃ Ol-2.0

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PSPBOK - EspaÃ Ol-2.0

Transféré par

Droits d'auteur :

Formats disponibles

1

El Proceso Personal de SoftwareSM (PSPSM)

Copyright 2009 Carnegie Mellon University.

Copyright Carnegie Mellon University.

Copyright Carnegie Mellon University.

Copyright Carnegie Mellon University.

Copyright Carnegie Mellon University.

un marco claramente delineado para la planificacin, seguimiento y gestin del trabajo

Una herramienta para la planificacin y la gestin de la calidad de los productos

Planificacin: Elaborar un plan para hacer el trabajo.

1.1.10 Incremental development (desarrollo incremental)

Varios procesos de desarrollo incremental PSP estn disponibles [Humphrey 05a].

el propsito u objetivo del proceso

los criterios de entrada

directrices generales, consideraciones de uso, o restricciones

fases o etapas que deben realizarse

mtricas del proceso y criterios de calidad

analizar un proceso para determinar la manera de mejorarlo

determinar la eficacia de las modificaciones al proceso

1.3.1 The need for measures (la necesidad de usar mtricas)

1.4.8 Prediction interval (Intervalo de prediccin)

Copyright Carnegie Mellon University.

el establecimiento de estndares para productos y procesos

2.2.2 Collecting useful data (Recoleccin de datos tiles)

El proceso de recoleccin de datos debe tener objetivos y planes especficos.

2.2.3 Collecting high-quality data (recopilacin de datos de alta calidad)

Copyright Carnegie Mellon University.

Knowledge Area 2.3: Data Measures

2.4.3 Performance measures (mtricas de desempeo)

2.4.4 Performance baselines (lneas base de desempeo)

2.4.8 Analyzing effort-estimating accuracy

Copyright Carnegie Mellon University.

los proyectos subestimados correlacionan con un mayor porcentaje de re-trabajo?

La productividad es estable? Por qu o por qu no?

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

Determinar qu tipos de defectos se presentan con ms frecuencia.

2.4.12 Determining the cost of rework (determinar el costo del re-trabajo)

Knowledge Area 2.5: Process Improvement (mejora de procesos)

Identifique a uno o ms proyectos que realicen un trabajo similar.

Knowledge Area 3.1: Size Measures (mtricas de tamao)

lograr consistencia en la descripcin de tamao

normalizar los datos de tiempos y defectos

lograr mejores estimaciones de tamao y mejores planes

relacionadas con el esfuerzo de desarrollo

definidas con precisin

3.1.4 Counting standards (estndares de conteo)

precisa sobre lo que debe contar

3.1.5 Physical and logical size (tamao fsico y lgico)

Ordenar los productos con base en los recursos necesarios.

Algunas mtricas tpicas de tamao incluyen

lneas de cdigo (LOC): un conteo de las lneas lgicas de cdigo en un producto.

tamao de los requerimientos: un conteo de pginas de requerimientos, narrativas o puntos de funcin.

Knowledge Area 3.2: Size Data (datos de tamao)

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

Copyright Carnegie Mellon University.

El contenido de proxies en un producto se debe poder contar directamente.

El proxy debe ser fcil de visualizar al inicio de un proyecto.

El proxy debe ser adaptable a las necesidades de cada proyecto e individuo

Ordenar los datos de tamao.

2. Calcular la media (avg) y la desviacin estndar () del conjunto de datos.