Prerequisitos

- Instalar el Access Runtime 2007.

http://www.microsoft.com/en-us/download/details.aspx?id=4438

- Instalar FUNDAMENTALS PSP STUDENT WORKBOOK.

PSP – Personal Software Process
PSP: Es una serie de procesos definidos que
permiten a los profesionales de ingeniería
construir productos de alta calidad a tiempo y
dentro del presupuesto.

En
Producción Sin metodologías

TSP: En términos generales consiste en aplicar

PSP a un equipo de trabajo.
 PSP es personal
Cada ingeniero es diferente; para ser más eficiente, debe
planificar su trabajo basándose en datos tomados de su
propia trayectoria profesional.
Mejora con el uso de PSP/TSP

Fuente: Intergraphic Design

PSP y CMMI
Economía de la calidad en PSP
1 Es menos costoso encontrar y corregir los defectos antes en un proceso, que
después.

2 Cuanto más tiempo permanece un defecto en un producto, mayor será el

costo para extraerlo.

3 Las pruebas son una manera ineficiente e ineficaz para eliminar defectos.
www.gridshore.nl

Algunas disciplinas
PSP
se enfocan aquí
Economía de la calidad en PSP
4 Es más eficiente prevenir los defectos que encontrarlos y corregirlos

5 Las revisiones son fundamentalmente más eficientes que las pruebas para
encontrar y corregir defectos.

6 La manera correcta es siempre la manera más rápida y más barata de

producir un resultado de alta calidad.
www.gridshore.nl

Algunas disciplinas
PSP
se enfocan aquí

Calidad
Fases de un proceso en PSP
1 Planeación Elaborar un plan para hacer el trabajo

2 Desarrollo Realizar el trabajo.

Diseño detallado

Revisión del diseño

Codificación

Revisión de código

Compilación

Pruebas

Datos reales vs planeados, registrar datos históricos, elaborar

3 Postmortem un informe resumen, y documentar ideas de mejora (PIP).
Elementos del proceso

• Scripts (Guiones): Descripciones que guían

una fase.

• Formatos: Para recopilar y guardar datos

recolectados.

• Métricas: Cuantifican el proceso y producto.

Son: Tiempo, esfuerzo (min), Tamaño,
Calendario.

• Estándares: Definiciones precisas que sirven

como guía.
Scripts
Formatos
Fases de PSP

TSP
Team software
process Team software process
 PSP 0
Cuenta con 4 formularios:

• Project Plan Summary – resume tiempos planeados

y actuales y defectos por fase.

• Time Recording Log – Bitácora de tiempo

• Defect Recording Log – Bitácora de defectos

• Defect Type Standard – Usado para definir tipos de

defectos estándares
Estándar de Tipos de defectos

Las filas que la consulta

va a retornar. Definidas
por el WHERE

Las columnas que la

consulta va a retornar
 PSP 0.1

En este nivel se determinan las métricas del proceso,

basado en la unidad de medida de tamaño de PSP (por
ej: líneas de código - LOC).

Además de los formatos usados en PSP 0, en esta etapa

se definen estándares de codificación, tipos de
tamaños, estándares de conteo de líneas y mejoras al
proceso mediante el formato de propuesta de mejora
45 min del proceso (Process Improvement Proposal o PIP)

30 min Ejercicio: Estándar de codificación para SQL

 Programa 1
Crear un sp que calcule la desviación estándar de una
lista de números que va a estar guardado en una tabla
(Recibe como parámetro el nombre de la tabla y de la
columna). http://es.wikipedia.org/wiki/Desviación_típica
Ejemplo: para este conjunto { 4, 1, 11, 13, 2, 7 }
1. Calcular el promedio:

60 min
 PSP1 – Método PROBE
En la construcción de un edificio de oficinas cómo se calcularía el costo?

En total son 30 oficinas y 10 garajes

- 4 de 10 mts2 (Verysmall – VS)
- 6 de 12 mts2 (Small – S)
- 7 de 15 mts2 (Medium – M)
- 8 de 20 mts2 (Large – L)
- 5 de 25 mts2 (Verylarge – VL)

Costos
- VS = 60 millones
- S = 70 millones
- M = 85 millones
- L = 100 millones
- VL = 120 millones
 PSP1 – Método PROBE
Método de estimación PROBE (Proxy Based Estimating)
Se utiliza para estimar el tamaño, y con base en este, el tiempo que
toma realizar un producto de software. Consiste en que los
ingenieros deben determinar primero los objetos que se requieren
para construir el producto descrito en el diseño conceptual. A estos
objetos se les llama PROXY’s. Un proxy es un objeto que representa
un elemento a nivel conceptual (clases, reportes, formularios,
Procedimientos almacenados, etc).

Ejercicio: Crear una aplicación que cuente la cantidad de clases que

60 min
tiene un programa, las líneas de código de cada clase, y la cantidad
de ítems (métodos). Estos datos los debe imprimir.

1) Abrir archivo del script.

PSP1 – Método PROBE

Programa base Nuevo programa

New
Nuevas
Reusable Agregadas y
reusables
modificadas
Modified
Modificadas Added
Agregadas
LOC
Deleted
Borradas No tocadas
Untouched Reusadas
Reused
 PSP1 – Método PROBE

Archivo
InfoPrograma
Diseño conceptual

InfoClase
- BuscarArchivos
- ContarLineas - ContarMetodos
- MostrarInfo

Impresión
Principal
- Imprimir
- EjecutarPrograma
PSP1 – Método PROBE con SQL
1. Estándar de codificación (Formato)
SELECT C.Name
,E.NameLast
,E.NameFirst
,E.Number
,ISNULL(I.Description,'NA') AS Description
FROM tblCompany AS C
INNER JOIN tblEmployee AS E
ON C.CompanyID = E.CompanyID
LEFT JOIN tblCoverage AS V
ON E.EmployeeID = V.EmployeeID
LEFT JOIN tblInsurance AS I
ON V.InsuranceID = I.InsuranceID
WHERE C.Name LIKE @Name
AND V.CreateDate > CONVERT(smalldatetime, '01/01/2000')
ORDER BY C.Name
,E.NameLast
,E.NameFirst
,E.Number
,ISNULL(I.Description,'NA')
PSP1 – Método PROBE con SQL
2. Proxies
Los Proxies o partes serán las principales sentencias SQL:
INSERT, SELECT, UPDATE, DELETE, EXECUTE, DECLARE.
Estas abarcan el 80% de las que se utilizan en un SP.

3. Tabla de tamaños relativos

Se crea con base en el histórico de nuestros SPs
PSP1 – Método PROBE con SQL
4. Estándar de tipos de defectos

 Documentación
 Sintáxis
 Archivos de Script
 Campos a retornar
 Joins
 Filtros (Where, Having)
 Asignación (Set)
 Datos
 Función
 Sistema
 Entorno
 Método PROBE con SQL
Suponga que recibe el siguiente requerimiento para cambiar un
reporte de inventario:
- Adicionar una nueva columna para la descripción por Tipo de
parte
Ejemplo

- Actualizar el cálculo de inventario con el estándar A234

- Eliminar del reporte la sección de partes que no se han vendido
en más de un año.

Diseño Conceptual:

- Nueva columna para el Tipo de parte

Necesitaría 1 SELECT (Small) de la tabla TipoParte
- Actualizar forma de calcular inventario
1 UPDATE (Medium)
- Eliminar sección de partes no vendidas > 1 año
1 INSERT (Medium) – hacia una tabla temporal
1 DELETE (Large) – de la tabla actual
Ejemplo Método PROBE con SQL
 Método PROBE con SQL
Ejercicio práctico con BD Northwind
Utilizando el Método PROBE, estimar el tamaño del siguiente requerimiento (pensar en un SP):

1) Ingresar tres variedades de quesos adicionales: “Queso Mozarela”, “Queso Campesino”, “Queso
parmesano”, con las mismas especificaciones del “Queso Cabrales”.

2) Actualizar las tres variedades de queso anteriores con el precio unitario: 22, 20 y 25
respectivamente; sin unidades ordenadas (pedidas) para todos, y 25 unidades en existencia para los
dos primeros y 20 para el último.

3) Eliminar las ordenes que no se han entregado y que iban con destino a un determinado país, el
cual será paramétrico.

4) Crear un reporte que muestre:

- Que productos proporciona cada proveedor y qué categoría tienen
- Los 10 productos más vendidos, qué cantidad se ha vendido y su categoría
- Los 10 clientes que más compran y el valor total de lo que han comprado
- Los 10 empleados más vendedores
Método PROBE con SQL
Usando lo que hemos aprendido de la metodología,
cómo se empezaría?

1. Siguiendo el Script
PSP 1.1 Planeación de proyectos
El método del valor ganado nos permite revisar el
Método del valor ganado

avance del proyecto.

Se basa en dos conceptos:

1) Valor Planeado (Planed Value - PV). Corresponde al

porcentaje del tiempo que se planeo para una tarea
con relación al tiempo total del proyecto.

2) Valor Ganado (Earn Value - EV). Corresponde al

mismo valor planeado, pero solo se asigna cuando
la tarea se completó al 100%.
PSP 1.1 Planeación de proyectos
1. Usando el método PROBE se estima el tamaño y luego el tiempo del
Método del valor ganado

proyecto
2. Con base en el tiempo a la fecha (To-Date%) por fase, distribuye el
tiempo total en cada una de las fases

Detailed level design  La columna To-Date%

Revisión de diseño det.  representa la distribución del
Revisión de código  tiempo acumulado total en
Unit tests (pruebas unit.) 
cada una de las fases
Postmortem 

3. Se definen tareas por fase, si es necesario

4. Se definen las actividades a realizar en cada una de las fases
5. Se estima el tiempo de cada tarea
6. Se define el Valor planeado de cada tarea
PSP 1.1 Planeación de proyectos
Método del valor ganado

Tip: Es conveniente tener actividades de no más de

12 horas

Ejemplo
PSP 2 Calidad en el Software
Para construir productos de calidad consistentemente,
los individuos deben ser disciplinados en el desarrollo y
seguimiento de planes, en el seguimiento y la gestión de
su tiempo personal, y mantener la calidad como la
máxima prioridad.
Ver diapositiva “Economía de la calidad”

Nivel CMMI Defectos / KLOC Defectos / MLOC

1 7,5 7.500
2 6,24 6.240
3 4,73 4.730
4 2,28 2.280
5 1,05 1.050
PSP 2 Calidad en el Software
PSP se enfoca en detectar y corregir los defectos en
fases tempranas del desarrollo.
Planeación

Desarrollo

Diseño detallado
• En las revisiones se encuentran de
Revisión del diseño
2 a 5 veces más defectos por hora
Codificación
que en la fase de pruebas
Revisión de código

Compilación
• Los expertos en revisiones pueden
Pruebas
encontrar 70% o más de los
Postmortem defectos de un producto
PSP 2 Calidad en el Software
Para mejorar la calidad se necesita
medir la calidad
Medidas de la calidad del trabajo:

• Yield (Remoción de defectos)

• Costo de calidad
• Tasas de revisión
• Tasas de tiempo empleado por fase
• PQI - Process Quality Index (Indice de
Calidad del Proceso)
 PSP 2 Calidad en el Software
Yield (Remoción de defectos)

1) El Yield de fase: es el porcentaje de defectos que se

removieron en dicha fase.
(Defectos removidos / Defectos Totales) * 100
Ejemplo:
Defects at
Phase Def. Injected Def. Removed Yield de la fase Phase Entry

Detailed Design 26 0 0
Design Review 0 11 11/26 = 42.3% 26
Code 39 0 15
Code Review 0 28 28/(26+39-11) = 51.9% 54
Compile 0 12 12/((26+39)-(11+28))=46.2% 26
Unit Test 0 7 50.0% 14
After Unit Test 0 7 7
Total 65 65
 PSP 2 Calidad en el Software
2) El Yield del proceso: es el porcentaje de defectos que se
removieron antes de las fases de compilación y pruebas.
Defects at
Phase Def. Injected Def. Removed Yield de la fase Phase Entry

Detailed Design 26 0 0
Design Review 0 11 42.3% 26
Code 39 0 15
Code Review 0 28 51.9% 54
Compile 0 12 46.2% 26
Unit Test 0 7 50.0% 14
After Unit Test 0 7 7
Total 65 65

Yield del proceso = ((11+28) / (26 + 39)) * 100 = 60%

Tip: Un Yield de proceso bueno es ≥ 70%, es decir, haber
corregido al menos el 70% de los defectos antes de hacer pruebas
 PSP 2 Calidad en el Software
COQ (Cost of Quality)
También se entiende como el costo de tener una baja calidad. “Representa los costos en
los que incide una organización al tener que repetir un proceso para realizar el trabajo
correctamente” (L. Lazic, A. Kolasinac, and D. Avdic)

Para PSP, el COQ tiene dos componentes:

1. Failure costs - COQF (Costos de fallas): Tiempo invertido en compilar y probar.
COQF = 100 * (Tiempo compilación + Tiempo pruebas) / (Tiempo total desarrollo)

2. Appraisal costs - COQE (Costos de evaluación): El tiempo total invertido en las

revisiones de diseño y código, y en las inspecciones.
COQE = 100*(Tiempo revisión diseño + Tiempo revisión código)/(Tiempo total desarrollo)

COQ Total = COQF + COQE

Tip: COQE / COQF debe ser cercano a 2.0 (doble tiempo en revisiones con relación a
compilación y pruebas)
 PSP 2 Calidad en el Software
Time in Phase (min.) Plan Actual To Date To Date %
Planning 644 457 457 27%
Ejemplo Cost of Quality

Design (DLD) 258 312 312 18%

Design Review (DLDR) 130 155 155 9%
Code 320 390 390 23%
Code Review (CR) 160 180 180 11%
Compile 5 12 12 1%
Test (UT) 215 192 192 11%
Total 1732 1698 1698 100%

COQF = 100*(T. comp + T. pruebas)/(T. total) = 100*(12+192)/1698 = 12.01%

COQE = 100*(T. DLDR + T. CR)/(T. total) = 100 * (155 + 180) / 1698 = 19.73%

COQ Total = COQF + COQE = 12.01 % + 19.73% = 31.74

PSP 2 Calidad en el Software
Tasas de revisión
Se refiere a la velocidad con la cuál se realizan
las revisiones de diseño y de código.

Tip: Para las revisiones de código se recomienda

que sea máximo de 200 LOC / hora.

Se ha observado que cuando la tasa es mayor el

yield de proceso tiende a ser menor a 70% y
viceversa.
PSP 2 Calidad en el Software
Tasas de tiempo por fase
1) Tiempo Diseño / Tiempo Codificación
Se recomienda que esta relación sea ≥ 1, es decir que el
tiempo de diseño sea por lo menos igual al tiempo de
codificación.

2) Tiempo revisión diseño / Tiempo de diseño

Se recomienda que esta relación sea ≥ 0.5, es decir que
el tiempo de revisión de diseño sea por lo menos la
mitad del tiempo de diseño, igual para CR y Codificación.

Tip: Se pueden tener fases de revisión para otras etapas

como requerimientos.
 PSP 2 Calidad en el Software
PQI. Process Quality Index (Índice de Calidad del Proceso)
Indica la calidad que tendrá un producto
T. diseño ≥ T. codificación T. = Tiempo
(T. diseño / T. codificación) D. = Defectos
KLOC = Mil líneas de código

T. revisión diseño ≥ 50% T. diseño T. revisión código ≥ 50% T. codificación

T. revisión diseño / (0.5 * T. diseño) T. revisión código / (0.5 * T. codificación)

D. compilación < 10 D. KLOC D. pruebas < 5 D. KLOC

20 / (10 + D. compilación KLOC) 10 / (5 + D. Pruebas KLOC)

Resulta de multiplicar los elementos de la figura. Un valor > 0.4 es

bueno, aunque lo ideal es que sea lo más cercano a 1. Un valor ≤ 0.4
indica un producto de baja calidad.
PSP 2 Calidad en el Software
PQI. Process Quality Index (Ejemplo)
 PSP 2 Calidad en el Software
Revisiones de código y de diseño
1) Listas de chequeo para revisión de código y diseño
• Cada persona debe realizar su propia lista
• Se divide en secciones o categorías (Por ej. los tipos de defectos)
• Se actualiza periódicamente con base en los defectos

Ejemplo. Listas de chequeo para revisión de código y diseño en C#:

PSP 2 Calidad en el Software
Taller
Complementar la siguiente lista de chequeo para SQL
con base en sus errores más frecuentes al programar.
 PSP 2.1 Diseño de Software
Plantillas de diseño
Dinámica Estática
- Plantilla de Especificación
Operacional (Interacción entorno) - Plantilla de Especificación
Externa - Plantilla de Especificación Funcional
Funcional (Clases y métodos)

- Plantilla de Especificación de - Plantilla de Especificación Lógica

Interna Estados (Pseudocódigo)
 PSP 2.1 Diseño de Software
Plantilla de Especificación Operacional
(Interacción entorno)

Student J.D. Veloper Date 10/26

Program LogIn Program #
Instructor Humphrey Language C++

Scenario Number 1 User Objective To log onto the system

Scenario Objective To illustrate normal LogIn operation
Source Step Action Comments
User 1 Call the system
System 2 Request UserId Check for timeout
User 3 Supplies UserId Check for data errors; user supplies
valid ID
System 4 Request UserPW Check for timeout
User 5 Supplies UserPW Check for data errors; user supplies
valid PW
System 6 LogInUser Log user onto system, stop
PSP 2.1 Diseño de Software
Plantilla de Especificación Operacional
(Interacción entorno)
 PSP 2.1 Diseño de Software
Student J.D. Veloper Date 10/26
Plantilla de Especificación Funcional

Program LogIn Program #

Instructor Humphrey Language C++

Class Name LogIn

Parent Class

Attributes
(Clases y Métodos)

Declaration Description
MaxTime: Integer, minutes Maximum time-out minutes - adjustable
n: Integer Count of user ID and password errors
nMax: Integer Maximum of n error count
ValidIdSet Set of valid user IDs with passwords

Items
Declaration
Void LogIn.Start(n: Int)
Int LogIn.GetId(ID: String)
Int LogIn.CheckId(ID: String)
Int LogIn.GetPW(PW: String)
Int LogIn.CheckPW(PW: String)
Void LogIn.LogInUser(ID: String, n: Int)
Description
Initialize system
Handle LogIn transaction, error count, and time-
outs
Get UserId and check it for problems.
Return true for an acceptable string, false for
timeout or an unacceptable string
UserId  ValidIdSet  Valid ID
UserId  ValidIdSet  !Valid ID
Get password and check for problems.
Return true for an acceptable string, false for
timeout or an unacceptable string
PW = UserId.PW  Valid PW
PW ≠ UserId.PW  !Valid PW
n >= nMax  Reject user, deactivate ID
Valid ID  Valid PW  Log in user
 PSP 2.1 Diseño de Software
Plantilla de Especificación de Estados

Student J.D. Veloper Date 10/27

Program LogIn Program #
Instructor Humphrey Language C++

State Name Description

Start Start condition for system
CheckID The state of the system after a user ID is requested
CheckPW The state of the system after a user password is requested
(Cambio de estados)

End The final state: LogIn either logs in or cuts off the user.
Function/Parameter Description
ID User identification: ID is valid or !Valid
PW User password: PW is valid or !valid
n Integer count of ID and password errors
nMax Maximum value of ID and password errors: n >= nMax is rejected.
Fail Indicator of error count or timeout error: Fail = true is failure, Fail = false is ok.
States/Next States Transition Condition Action
Start
Start No transitions from Start to Start
CheckID True Get ID, n := 0; ID and PW !Valid
CheckPW No transitions from Start to CheckPW
End No transitions from Start to End
CheckID
Start No transitions from CheckID to Start
CheckID No transitions from CheckID to CheckID
CheckPW Valid ID Get password
CheckPW !Valid ID Get password
End Timeout Fail := true
CheckPW
Start No transitions from CheckPW to Start
CheckID (!Valid PW  !Valid ID)  n < nMax  Get ID, n := n + 1; ID and PW
!Timeout !Valid
CheckPW No transitions from CheckPW to
CheckPW
End Valid PW  Valid ID  !Timeout Fail := false, login user
End n >= nMax  Timeout Fail := true, cut off user
End
No transitions from End to any state
 PSP 2.1 Diseño de Software
Student J.D. Veloper Date 10/27
Program LogIn Program #
Plantilla de Especificación Lógica

Instructor Humphrey Language C++

Design Operational Specification – page 259

References Functional Specification – page 262
State Specification – page 266
(Pseudocódigo)

Parameters n : the error counter, maximum value nMax

ID : Boolean indicator of ID Valid and ID !Valid
PW : Boolean indicator of PW Valid and PW !Valid
Fail: Boolean indicator of failure condition, end session

Log a user onto the system.

Start by initializing the n error counter, set ID: = !Valid, PW := !Valid, and Fail := false.
Get user ID.
Repeat the main loop until a valid ID and password or Fail.
Check ID for validity. {CheckID state}
If no ID response in MaxTime, set Fail := true.
Get password and check for validity. {CheckPW state}
If no password response in MaxTime, set Fail := true.
If PW !Valid or ID !Valid, step the n counter.
If n exceeds nMax, set Fail := true.
Until ID and PW Valid or Fail = true.
Otherwise, repeat the main loop.
If Fail = true, cut off user, otherwise, log in the user. {End state}
 TSP
Qué es TSP
- Framework que hace un balanceado énfasis entre procesos,
productos y trabajo en equipo.

- Presenta los conceptos para la conformación eficiente de

equipos de trabajo.

- Define un proceso de construcción de proyectos de mediana

escala con un grupo de trabajo y capitaliza la experiencia en
planeación y control de proyectos.
Diseño del proceso TSP
 TSP
Qué se necesita para iniciarse en TSP

- Miembros del grupo entrenados en PSP.

- Conocimiento previo en diseño de software y

manejo de requerimientos.

- Conocimiento en administración de la
configuración, manejo de proyectos y pruebas de
software.
 TSP
Roles

- Líder
- Líder de Desarrollo
- Líder de Planeación
- Líder de Calidad
- Líder de Soporte

Descripción, Metas (M) y Actividades (A) de cada Rol

 Bibliografía
• Personal Software Process in the Database Course. http://crpit.com/confpapers/CRPITV30Bullers.pdf
(Table 2: PSP and SQL Defect Type Standard)

• PROxy Based Estimation (PROBE) for Structured Query Language (SQL). http://goo.gl/6Dm8Bq

• Base de datos Northwind . http://goo.gl/6qXNdF

• OpenCourseWare. Principios de Ingeniería Informática. http://goo.gl/52jYBN

• Introduciendo Calidad a las Organizaciones de Software. http://goo.gl/e7KYLl

• Lista de chequeo para SQL. http://goo.gl/K2S1WX

• ETL Code Review CheckList. http://goo.gl/e5xb30

• Lista de Chequeo para la revisión de diseño de un Data Warehouse. http://goo.gl/6j3m3n

• PSP for Engineers: Part II. Software Design I. http://goo.gl/xjGd93