INFORME DE INVESTIGACIÓN DEL PROCESO PERSONAL DE SOFTWARE

Universidad Privada Del Norte

Ingeniería de Sistemas Computacionales
Trujillo – Perú
José Alberto Gómez Ávila

1er Autor 2do Autor

Jiménez Azabache Jorge Alexander García Leyva Alexei Leonel
999 007 682 950610523
alez_jiaz@outlook.com alexeilgl@gmail.com

Facultad de Ingeniería Semestre 2018-2

Ing. de Sistemas Computacionales Fecha: 29/08/2018
INDICE
1. Introducción ............................................................................................................................... 1
2. Definiciones ............................................................................................................................... 2
2.1. Personal Software Process (PSP) ....................................................................................... 2
2.2. Calidad ............................................................................................................................... 2
2.3. Procesos de Software ......................................................................................................... 3
2.3.1. Proceso de medición personal .................................................................................... 3
2.3.2. Proceso de planificación personal .............................................................................. 3
2.3.3. Administración de calidad personal ........................................................................... 3
2.4. Estrategia de PSP ............................................................................................................... 4
2.5. Herramientas de apoyo para PSP ....................................................................................... 5
2.5.1. Primera Generación .................................................................................................... 5
2.5.2. Segunda Generación ................................................................................................... 5
2.5.3. Tercera Generación .................................................................................................... 5
2.6. Modelo de Aseguramiento de Calidad ............................................................................... 7
3. Flujo - Actividades ..................................................................................................................... 8
3.1. ¿Cuándo se aplica? ............................................................................................................. 8
3.1.1. Beneficios personales: ................................................................................................ 8
3.1.2. Nivel de la organización ............................................................................................. 9
3.2. Estructura del proceso PSP ................................................................................................ 9
3.3. Niveles de Mejora PSP..................................................................................................... 12
3.3.1. Línea Base – PSP0 y PSP0.1 .................................................................................... 12
3.3.3. Gestión de la Calidad personal – PSP2 y PSP2.1..................................................... 14
3.3.4. Proceso Cíclico Personal – PSP3 ............................................................................. 15
4. Ejemplos y Aplicaciones .......................................................................................................... 17
4.1. Aplicación de PSP ........................................................................................................ 17
4.2. Ejemplo: Elaboración de software: .............................................................................. 18
5. Conclusiones. ........................................................................................................................... 52
6. Bibliografía. ............................................................................................................................. 53
1. Introducción

La producción de software es un factor fundamental para fortalecer la economía regional y

proyectarse a nivel internacional. Para lograr este objetivo es necesario articular la educación

tecnológica y profesional con estándares reconocidos a nivel mundial, que garanticen la

inclusión de los egresados en el ámbito productivo y así consolidar una cultura de calidad en los

procesos asociados al desarrollo del software.

Para consolidar esta cultura de software es preciso contar con procesos bien definidos y un

personal competente, entrenado en una disciplina personal y de trabajo en equipo. El Proceso

de Software Personal (PSP) contribuye a alcanzar disciplina en el trabajo individual.

El PSP es un proceso individual cuyo objetivo es ayudar a los ingenieros en software a medir y

mejorar su productividad personal. El PSP suele enseñarse exclusivamente a profesionales, no

obstante, éste ha comenzado a incluirse como parte de cursos universitarios.

Palabras Clave. Proceso de Software Personal, PSP, calidad, Procesos

1
2. Definiciones

2.1. Personal Software Process (PSP)

El Proceso Software Personal (PSP) fue diseñado para ayudar a los ingenieros del

software a hacer bien su trabajo. Muestra cómo aplicar métodos avanzados de ingeniería

a sus tareas diarias. Proporciona métodos detallados de planificación y estimación,

muestra a los ingenieros cómo controlar su rendimiento frente a estos planes y explica

cómo los procesos definidos guían su trabajo. Humphrey (2001).

La disciplina del PSP provee un marco estructurado para desarrollar habilidades

personales y métodos que se necesitarán más adelante para ir forjando al ingeniero de

software. Es importante que la calidad del software desarrollado abarque hasta el más

mínimo detalle, por muy pequeño que éste sea, ya que, si no se hace así, puede dañar el

sistema entero.

Los principales objetivos del PSP son:

1. Mejorar las estimaciones.

2. Mejorar la planeación y acompañamiento de cronogramas.

3. Proteger contra el exceso de compromisos.

4. Crear un compromiso personal con la calidad.

5. Compromiso del desarrollador en la mejora continua del proceso de desarrollo.

6. Aumento de la calidad a través de la reducción de la incidencia de errores.

7. Mayor precisión en las estimaciones de tamaño del software y tiempo de desarrollo.

2.2. Calidad

Es un conjunto de propiedades y de características de un producto o servicio,

que le confieren aptitud para satisfacer unas necesidades explicitas o implícitas.

(ISO 8402).

2
2.3. Calidad de Software

La totalidad de características de un producto de software que tienen como

habilidad, satisfacer necesidades explícitas o implícitas. (ISO/IEC DEC 9126)

2.4. Procesos de PSP

Se diseñaron para ayudar a los ingenieros de software a hacer bien su trabajo,

por tanto, nos permite aplicar métodos avanzados de ingeniería a nuestras tareas

diarias. Los procesos del PSP son:

2.4.1. Proceso de medición personal

Proceso que permite recoger sobre el trabajo (tiempo gastado,

cantidad de defectos, etc.), establecer una base que incluye mediciones y

formatos de reportes para medir progreso y definir los cimientos de

mejora.

2.4.2. Proceso de planificación personal

Proceso que facilita las estimaciones de tamaño y recursos,

cronograma y seguimiento del proyecto, y enseña a realizar compromisos

que se pueden cumplir.

2.4.3. Administración de calidad personal

Proceso para mejorar la habilidad del ingeniero para producir

software de calidad de manera natural y consciente y explotar habilidades

inherentes y capacidades.

3
2.5. Estrategia de PSP

El modelo PSP está dividido en niveles, implantados de manera incremental.

Los niveles superiores adicionan características a los niveles ya implantados lo

que minimiza el impacto de los cambios en los hábitos del desarrollador. Este

deberá tan sólo adaptar nuevas técnicas a las ya existentes y conocidas.

Lo más importante en el proceso de aprendizaje son los datos recogidos

después de cada fase, pues con base en los resultados obtenidos en la fase actual

se propone mejorar el desempeño personal para la siguiente fase. Los niveles de

mejoramiento de PSP se muestran en la siguiente tabla

Nivel Nombre Actividad

Registro de tiempo.
PSP0 Medición personal
Registro de defectos.
Patrón de tipos de defectos.
Patrón de codificación.
PSP0.1 Registro de defectos
Medida de tamaño.
Propuesta de mejoramiento de procesos.
Estimación de tamaño.
Informe de pruebas.
PSP1 Planeamiento personal
Planeamiento de tareas.
Cronogramas.
Revisiones de código.
PSP2 Gerenciamiento de la calidad personal Revisiones de proyecto.
Patrones de proyecto.
PSP3 Proceso Personal cíclico Desarrollo cíclico.
Tabla 1: Niveles de mejoramiento de PSP

4
2.6. Herramientas de apoyo para PSP

Las herramientas que soportan PSP pueden dividirse en tres generaciones.

2.6.1. Primera Generación

En la primera generación los desarrolladores imprimían los

formularios y los completaban manualmente junto con los registros de

tamaño, esfuerzo y defectos. Adicionalmente utilizaban formularios de

datos para estimar el proyecto y asegurar la calidad. Este enfoque

presenta un substancial gasto de tiempo para completar los formularios.

2.6.2. Segunda Generación

Durante la segunda generación se utilizan herramientas

automatizadas para apoyar PSP como por ejemplo LEAP, PSP Studio,

PSP Dashboard y PSP Tool. Estas herramientas tienen el mismo enfoque

de interacción con el usuario. Muestran los campos de entrada donde

registran el esfuerzo, tamaño y la información de defectos. También

presentan varias herramientas de análisis si son requeridas por el usuario,

alivianando su trabajo. Debido a que esta perspectiva no elimina la

continua necesidad de cambio de contexto entre el desarrollo del

producto y el registro del proceso, no fue ampliamente adoptada.

2.6.3. Tercera Generación

Finalmente se presenta una tercera generación en donde se busca

recolectar el mayor grado de información posible de forma automática y

discreta. El primer representante fue el desarrollo de Hackystat, el cual

puede recolectar métricas de forma automática, aunque no se encuentra

enfocado en el Proceso Personal de Software.

5
 La recolección de datos en forma manual es poco confiable y su uso

requiere por parte de los desarrolladores continuos cambios de contexto

entre el desarrollo del producto y el registro del proceso. Por lo tanto, se

hace necesario una herramienta que sea lo más completamente

automatizada posible y no invasiva, relacionada con la recolección de

datos y su posterior análisis. Los datos a recolectar se pueden dividir en

primarios; como lo son el tiempo, el tamaño y los datos de defectos; y

secundarios que son los derivados de los primeros, como, por ejemplo:

defectos removidos y la eficiencia a la fecha en porcentaje.

Junto a Hackystat, se encuentran herramientas como PROM,

PSP.NET y PSPA, las que presentan una arquitectura parecida, puesto

que cada sistema cuenta con un servidor central que recolecta la

información que es enviada por extensiones agregadas a un IDE

(Integrated Development Environment) particular. Uno de los

principales inconvenientes que presentan algunas de estas herramientas

es que su uso se encuentra limitado a las instituciones donde éstas fueron

desarrolladas, por lo que su diseño y principales componentes no han sido

descritos ni detallados fuera de este ámbito.

6
 Caracteristicas Principales Hackystat PROM PSP.NET PSPA
Enfoque centrado en PSP No No Sí Sí
Recolección automática de datos Sí Sí Sí Sí
Privacidad de datos Sí No Sí Sí
Generación de reportes PSP No No Sí Sí
Portabilidad Sí Sí No No
Control real del tiempo y defectos No No No No
Privacidad en los datos transmitidos Sí No No No
Flexibilidad en la recolección de datos Sí Sí sí No
Facilidades para extender su uso Sí sí Sí No
Tabla 2: Principales características de las herramientas de apoyo a PSP

2.7. Modelo de Aseguramiento de Calidad

El modelo propuesto tiene como propósito asegurar la calidad en el proceso

de desarrollo de software con un enfoque en el talento humano. Considera que las

personas que realizan las actividades deben comprometerse con el trabajo y con

la calidad. (Espejo Chavarría, Bayona Oré, & Pastor, 2016)

Figura 1: Modelo de aseguramiento de Calidad

7
3. Flujo - Actividades

3.1. ¿Cuándo se aplica?

El PSP puede ser aplicado en cualquier parte del proceso de desarrollo de

software, como por ejemplo desarrollos de pequeños programas, definición de

requerimientos, documentación, aseguramiento de calidad y mantenimiento de

software.

La adopción de PSP es eficaz cuando existe un compromiso por parte de

toda la organización, o al menos de un grupo de la misma. Inicialmente implica

cambiar los hábitos de trabajo, recopilar datos, realizar planes, escribir reportes y

realizar otras actividades que aquellos que no están familiarizados con el proceso

podrían considerar como una pérdida de tiempo. Además, la organización que está

desarrollando el proyecto debe dar apoyo para formar la base de datos y llevar a

cabo el análisis de los datos recolectados. Por lo tanto, es importante que los

desarrolladores y administradores entiendan los beneficios que ofrece PSP y

colaboren para que el personal se capacite y defina su propio proceso.

Se requiere de mucha disciplina para usar un proceso, autoevaluarse y

detectar aquellas áreas en las que se puede mejorar. Una vez detectadas las

oportunidades de mejoras, se deben establecer objetivos y las medidas que lleven

a alcanzar esos objetivos.

Los beneficios son muchos, tanto a nivel personal como a nivel de la

organización.

3.1.1. Beneficios personales:

El desarrollador puede conocer y entender sus propias fortalezas y

debilidades, y aprovechar las primeras y buscar superar las últimas.

8
 Además, define su propio proceso sobre el que tiene control, y está en

condiciones de mejorarlo continuamente y en consecuencia mejorar su

desempeño. Cuenta con datos para hacer planes más certeros. Con estos

planes puede hacer seguimientos sobre su trabajo, lo cual le permite

administrarlo mejor.

3.1.2. Nivel de la organización

Si PSP es adoptado por todos los programadores, éstos pueden definir un

proceso de desarrollo en equipo de mejor calidad. Cada miembro del

equipo puede hacer su trabajo sin depender tanto del desempeño de sus

compañeros. La organización puede hacer planes más certeros y tener

más elementos para negociar con sus clientes: puede planear el tamaño

del producto que va a entregar, la calidad del mismo, el tiempo que

requiere para su desarrollo y la cantidad de personas que asigna para

trabajar en el proyecto.

3.2. Estructura del proceso PSP

PSP establece un número de técnicas y métodos para lograr las mejoras en

el desempeño individual. La estructura del proceso PSP es mostrada en la

siguiente Figura. A partir de una especificación de requisitos, el primer paso es la

planeación. PSP presenta un script de Planeación que guía el trabajo y un Resumen

del Plan para registrar los datos de planeación. Dentro de su estructura los Scripts,

por medio de los cuales el desarrollador conoce las fases, y tareas propias de cada

una de las etapas necesarias para desarrollar un producto: Planeación, Diseño,

Revisión del diseño, Codificación, Revisión del código, Compilación, Pruebas y

9
Postmortem. Mientras el desarrollador hace su trabajo, va registrando los datos de

tiempos y defectos en las bitácoras o logs de defectos y tiempos, miden el tamaño

del programa, e introducen esos datos en el formato de Resumen del Plan.

Finalmente, entregan el producto con el formato de Resumen de Plan diligenciado.

Figura 2: Estructura del proceso de PSP

El proceso PSP tiene métodos numéricos que generalmente no han sido

utilizados por los ingenieros, desde que los métodos han sido introducidos en una

serie de 7 versiones. Estas versiones se han etiquetado desde PSP0 a PSP3 y cada

versión tiene un juego similar de logs, formas, scripts y estándares.

10
 Figura 3: Elementos del proceso PSP

 Guías (scripts): son una descripción de nivel-experto para guiar el proceso.

Contienen el propósito u objetivo del proceso, el criterio de entrada, cualquier

guía general, consideraciones de uso o limitaciones, fases o pasos a efectuar,

medidas de proceso, criterios de calidad y condiciones de finalización.

 Formularios (formas): proveen un conveniente y consistente marco de

trabajo para recolectar y retener datos. Especifican los datos requeridos y

donde estos deben ser registrados.

 Medidas (logs): son las medidas de cuantificación del proceso y el producto.

 Estándares: entregan una precisa y consistente definición que guía el trabajo,

junto con la recopilación y uso de datos. Permiten aplicar mediciones

uniformes a través de múltiples proyectos y comparaciones entre unos y otros.

11
3.3. Niveles de Mejora PSP

Estos niveles de mejora se explican a continuación:

Figura 4: Versiones del proceso PSP (adaptado de Humphrey [2005])

3.3.1. Línea Base – PSP0 y PSP0.1

Esta línea base provee una introducción a PSP y establece una base inicial

de tamaño histórico, tiempo y datos de defectos.

12
 Paso Fase Descripción
1 Planear Planear el trabajo y documentar el plan
2 Diseñar Diseñar el programa
3 Codificar Implementar el diseño
Compilar el programa y arreglar los defectos
4 Compilar
encontrados.
Probar el programa y arreglar los defectos
5 Probar
encontrados.
6 Postmortem Registrar el tiempo, defectos y tamaños reales.
Tabla 3: Fases propuestas de la Línea base de PSP

3.3.2. Gestión de proyectos personales – PSP1 y PSP1.1

Estos niveles se enfocan en técnicas de gestión de proyectos,

introduciendo estimación de esfuerzo y tamaño, programación de la

planeación, y métodos de seguimiento de la programación. La estimación

de tamaño y esfuerzo se obtiene usando el método PROBE (Proxy-Based

Estimating). Los proxies usados pueden ser objetos y métodos (lenguajes

orientados a objetos), o funciones y procedimientos (lenguajes

procidementales). A partir de dichos proxies se hacen estimaciones

iniciales y usando datos históricos, se convierte del tamaño relativo del

proxy a líneas de código (LOC) y finalmente estimar el esfuerzo. Otros

ejemplos de proxies pueden ser pantallas, objetos de pantalla, scripts,

reportes y páginas de documentos. Usar PROBE permite ver los objetos

que deben ser desarrollados.

Tipo de caso de prueba Pequeño Mediano Grande

Interfaz de usuario 12 (pasos de prueba) 16 21
Lógica de negocio 10 15 23
Base de datos 8 17 36
Tabla 4: Tamaño en pasos de prueba por tipo de caso de prueba

13
 En términos de productividad:

Tipo de caso de prueba Pasos de prueba / hora

Interfaz de usuario 2.95
Lógica de negocio 8.52
Base de datos 5.68
Tabla 5: Productividad según tipo de caso de prueba

A partir de las tablas anteriores se tendría.

Tamaño Tamaño Esfuerzo

Tipo de CP # CP Productividad
relativo estimado estimado (horas)
Interfaz de usuario 5 M (16) 80 2.95 27.1
Interfaz de usuario 3 G (21) 63 2.95 21.4
Interfaz de usuario 2 P (12) 24 2.95 8.1
Lógica de negocio 4 G (23) 92 8.52 10.8
Lógica de negocio 6 M (15) 90 8.52 10.6
Lógica de negocio 2 P (10) 20 8.52 2.3
Base de datos 10 G (36) 360 5.68 63.4
Base de datos 20 M (17) 340 5.68 59.9
Base de datos 12 P (8) 96 5.68 16.9
TOTAL 1165 220.5
Tabla 6: Estimación del esfuerzo y tamaño. Fuente: Adaptado Material Curso TSP

3.3.3. Gestión de la Calidad personal – PSP2 y PSP2.1

En este nivel se añaden métodos de gestión de la calidad: revisiones

personales de diseño y código, una notación de diseño, plantillas de

diseño, técnicas de verificación del diseño, y métricas para gestionar la

calidad del producto y del proceso. La meta es encontrar y remover todos

los defectos antes de compilar. La métrica asociada con esta meta es el

14
 Rendimiento (Yield). Con suficiente experiencia el desarrollador logra

eliminar entre el 60% y 70% de los defectos inyectados antes de la

primera compilación.

3.3.4. Proceso Cíclico Personal – PSP3

Este nivel se enfoca en la necesidad de escalar la eficiencia obtenida con

PSP a proyectos más grandes sin sacrificar productividad y calidad. Para

apoyar esta aproximación PSP3 introduce diseño de alto nivel, revisión

del diseño de alto nivel, planeación cíclica y ciclos de desarrollo basados

en los procesos de PSP2.1.

Figura 5: Proceso PSP3

15
 Los materiales provistos por PSP para cada nivel son diferentes de acuerdo

a la siguiente tabla:

Tipo de CP PSP0 PSP0.1 PSP1 PSP1.1 PSP2 PSP2.1

Script de Proceso PSP X X X X X X
Script de Planeación PSP X X X X X X
Script de Desarrollo PSP X X X X X X
Script de Revisión de Diseño PSP X X
Script de Revisión de Código PSP X X
Script de Postmortem PSP X X X X X X
Instrucciones y Resumen del Plan de
X X X X X X
proyecto
Script de Estimación PROBE X X X X
Tabla 7: Scripts y resúmenes por nivel de PSP

Formatos, Plantillas, estándares e

PSP0 PSP0.1 PSP1 PSP1.1 PSP2 PSP2.1
instrucciones
Log de Registro de tiempos X X X X X X
Log de Registro de defectos X X X X X X
PIP X X X X X
Estándar de Codificación X X X X X
Plantillas de reporte de Pruebas X X X X
Plantilla de estimación de Tamaño X X X X
Plantilla de Planeación de Tareas X X X
Plantillas de Planeación de Cronograma X X X
Lista de chequeo de Revisión de Diseño X1 X2
Lista de chequeo de Revisión de Código X X
Plantilla de Especificación de Casos de Uso X
Plantilla de Especificación Funcional X
Plantilla de Especificación de estado X
Plantilla de Especificación lógica X
Tabla 8: Entregables por versión

16
4. Ejemplos y Aplicaciones

4.1. Aplicación de PSP

Figura 6: Combinación de RUP y PSP

17
4.2. Ejemplo: Elaboración de software:

Software para la gestión de un inventario para el almacén de una tienda de

Galletas y Fideos que actualmente controla sus datos de venta y compra en un

programa sencillo de registro de datos, sin contar con consultas que son necesarias

y útiles para un mejor control.

El Ing. X no ve mayor dificultad en la aplicación a desarrollar y con la

empresa acordaron en un plazo de entrega de aproximadamente 1 mes, X procede

a una programación de actividades en un diagrama de Gantt de las actividades que

tiene que realizar. Si bien sus programaciones no serán exactas, con la experiencia

se tendrá que mejorar las mismas.

Figura 7: Diagrama de Gantt de actividades

1) Requisitos:

El Ing. X comenzó reuniéndose con el propietario para ir aprendiendo sobre el

funcionamiento de la empresa e ir obteniendo los requisitos explícitos al igual

que los implícitos. A partir de los requerimientos del cliente, X identifico que

eran necesarios los siguientes módulos:

18
 Funciones

Introducir datos de Fideos y Galletas

Modificar datos de Fideos y Galletas

Eliminar Datos de Fideos y Galletas

Consultas

Consulta de Productos por Marcas,

Consulta de Productos por Precio.

Consulta de Cantidad de Productos en Stock.

Consultas Estadísticas

Base de datos necesaria:

Fideos (Id_Fideo, Tipo, Marca, PrecioPaquete, PesoPaquete,

CantidadPaquetesStock)

Galletas (Id_Galleta, Nombre, Sabor, Marca, PrecioPaquete,

CantidadPaquete, CantidadPaquetesStock)

A partir de los requerimientos, X estudia sobre las herramientas, lenguaje, y

gestor de datos que se adaptarían mejor a dichos requisitos, y llega a la

conclusión que el desarrollo se debe realizar con Delphi 5 y MySQL

2) Estimación del Software:

La siguiente actividad que se debe realizar, es la planificación del proyecto,

que corresponde a llenar los valores estimados del formulario Resumen del

Plan del Proyecto. Como el Ing. X está usando por primera vez este formulario

del PSP, no dispone de muchos datos para hacer la estimación de varias

19
secciones. Sin embargo, X considerará datos según su criterio, que usará para

la estimación del Resumen del plan. En un uso continuado de PSP, X será capaz

de completar todas las estimaciones que el formulario requiera.

X asume que programa aproximadamente 30 LOC en 60 minutos (Esta

aproximación debe incluir el diseño lógico, revisión y pruebas)

Minutos/LOC = 60 / 30 LOC = 2 min.

LOC / Hora = 60 / (Minutos/LOC) = 60 / 2 = 30 LOC

Para el Tamaño del programa, es posible estimar Total Nuevo y Cambiado, por

el momento X aún no tiene registrado un historial de funciones que ayuden a

estimar las LOC necesarias para cada tipo de función, y basándose en la

experiencia el X estima un total de:

Función de Introducción de datos Tabla Galletas = 42 LOC

Función de Modificación de datos Tabla Galletas = 62 LOC

Función de Eliminación de datos Tabla Galletas = 42 LOC

Función de Introducción de datos Tabla Fideos = 40 LOC

Función de Modificación de datos Tabla Fideos = 60 LOC

Función de Eliminación de datos Tabla Fideos = 40 LOC

Función de Búsqueda de un Producto = 60 LOC

Función de consultar sobre Marcas de Productos = 30

Función de consultar sobre Precio de los Productos = 30

20
Función de consultar sobre Cantidad en Stock de los productos = 30

Función de consultar sobre Estadísticas = 120

LOC Nuevas y Cambiadas = 556 LOC

El tamaño Máximo y mínimo deberá ser a criterio. En este caso +50 y -50

Para el total de tiempo por fase = LOC Nuevas * (Minutos/LOC) = 556 * 2 =

1112 min.

Para el máximo de tiempo por fase = 606 * 2 = 1212 min.

Para el mínimo de tiempo por fase = 506 * 2 = 1012 min.

Figura 8: Plan del proyecto - Tamaño del programa

21
Figura 9: Plan del proyecto - Tiempo máximo y mínimo por fase

Figura 10: Plan del proyecto - Defectos eliminados por fase

22
 Ahora llega el momento de ir anotando los tiempos de las actividades que X

realiza en el Cuaderno de Registro de Tiempos. Para empezar X anota el tiempo

de planificación y estimación.

Figura 11: Registro de tiempos

3) Diseño:

Continua con la elaboración del diseño de los distintos módulos que X había

identificado, y expresando los diseños en Diagramas de Flujo, y anota el tiempo

empleado en el cuaderno de registro de tiempos a continuación del anterior

registro.

Figura 12: Registro de tiempos en la fase de diseño

23
4) Codificación:

El siguiente paso es codificar los diseños, para lo cual X necesita tener o

elaborar un estándar de codificación. Debido a que empieza a usar por primera

vez un estándar, toma como guía uno general y corto, como el siguiente:

ESTANDAR DE CODIFICACION EN DELPHI

Formato de encabezado: Deben ser como el siguiente:

{********************************************* }

{ Programa: ___________________ }

{ Autor: _______________________ }

{ Fecha ______________________ }

{ Versión: ____________________ }

{ Descripción: _________________ }

{********************************************* }

Uso y reúso de una función. Describir al máximo el uso de una función. Ej.

{*************************************************************

****************** }

{ Función: ____Factorial______________________________ }

{ Autor: ____Ing. X __________________________________ }

{ Fecha: ___09 / 01 / 08______________________________ }

{ Versión: ____1.0 __________________________________ }

{ Descripción: Esta rutina obtiene el factorial de un numero ___ }

{ entero cuyo resultado devuelve en un entero largo. El número }

24
{ ingresado debe ser menor a 150, se debe comprobar este __ }

{ valor antes de llamar a esta función. }

{*************************************************************

****************** }

Function Factorial ( Numero : int ) : Longint;

Var

Resultado, Contador: Longint;

Begin

Resultado := 1;

For Contador := 1 to Numero Do

Resultado := Resultado * Contador;

Factorial := Resultado;

End;

Identificación de variables. Utilizar siempre nombres descriptivos para todas

las variables, nombres de funciones, constantes u otros. Evitar variables de una

letra o silaba. Ej.

var

cantidad_alumnos: integer; //Aceptado en Estandar

ca: integer //Evitar este tipo de declaraciones

25
Comentarios. Deben tener el siguiente formato y ser explícitos:

Aceptado en estándar:

while (contador_alumno < num_alumno) do // ¿Faltan procesar

// registros de alumnos?

No aceptado:

while (contador_alumno < num_alumno) do // Compara si contador alumno

// es menor a num_alumno

Poner la descripción de las secciones principales en bloque de comentarios.

{Esta sección del programa, obtendrá los contenidos del array notas, además

calculara el promedio de la clase }

Procedimientos, funciones. Se deben considerar formatos de salida y entrada

de las funciones, como por ej. si el resultado de una función es verdad o falso

se deben usar datos booleanos en lugar de 0 y 1.

Espacios en blancos. Escribir los programas con los suficientes espacios en

blanco para facilitar la lectura. Se debe sangrar cada nivel begin end, estando

alineados el inicio y final. Ej.

26
while ( contador_alumno < cantidad_alumno) do

begin

if (array_alumno[contador_alumno] > mayor_nota )

begin

mayor_nota = array_alumno[contador_alumno]

end

contador_alumno = contador_alumno + 1;

end

Fin Estándar.

Para cada codificación del diseño, X tiene que anotar el tiempo dedicado en el

cuaderno de registro de tiempos.

27
 Figura 13: Registro de tiempos de cada codificación

5) Revisión de Código:

Una vez terminada la codificación, ahora corresponde realizar la revisión del

código, mediante una la lista de comprobación, siempre antes de compilar. Por

el momento X utilizará una lista de comprobación general, con el tiempo tendrá

que definir una lista personalizada de acuerdo a los errores que comete.

28
También necesita una clasificación de defectos, por lo que usará la que propone

el PSP.

Figura 14: Clasificación de defectos propuestas por PSP

Para cada defecto que se encuentra, se compara con el tipo de error y se registra

inmediatamente en el cuaderno de registro de defectos y en la tabla de Análisis

de Errores, esta última tabla será necesaria para completar el Resumen del Plan

del proyecto.

29
LISTA DE VERIFICACIÓN PARA REVISIÓN DE CÓDIGO.

30
Figura 15: Lista de verificación para revisión de código

31
ANÁLISIS DE ERRORES.

Figura 16: Análisis de errores

Al finalizar la revisión de las 11 funciones que X está desarrollando, obtiene

un total de 20 defectos encontrados antes de la primera compilación. Los

porcentajes nos indicarán donde es que tenemos más defectos, y sobre ello

debemos idear la forma de reducirlos. También se anota los tiempos en el

cuaderno de registro de tiempos.

32
 Figura 17: Registro de tiempos de las revisiones

6) Compilación

Luego se procede a la compilación del código, se registra cada defecto en el

cuaderno de defectos y en la tabla de análisis de errores y el tiempo dedicado

también en el cuaderno de registro de tiempos.

33
 Figura 18: Análisis de errores en fase Compilación

Figura 19: Registro de tiempos de la fase Compilación

34
7) Pruebas:

El Ing. X llego a la parte de las pruebas, donde cada módulo se probará con

distintos valores, y se registrará en el reporte de pruebas que sugiere PSP. Para

este caso solo se probará para las primeras 3 funciones, se probará que la

función insertar adicione datos a la Base De Datos correctamente, y que la

modificación y la eliminación sean exitosas.

Figura 20: Registro de prueba Función “Insertar Galleta”

Figura 21: Registro de prueba Función “Modificar Galleta”

35
 Figura 22: Registro de prueba Función “Eliminar Galleta”

De esta manera completamos las pruebas de las 11 funciones.

Completamos el análisis de errores con los defectos de las pruebas.

Figura 23: Análisis de errores de los defectos de las pruebas

36
Registrar en el Cuaderno de registro de tiempos el tiempo de las pruebas:

Figura 24: Registro de tiempos de la fase pruebas

37
El cuaderno de registro de defectos debería tener la siguiente forma.

38
 Figura 25: Registro de defectos

En este punto cada quien debe hacer un análisis de los defectos que comete, y

pensar en estrategias de cómo debemos dejar de cometer esos errores. Si

nuestras ideas dan resultados, estos defectos empezaran a disminuir al mínimo,

y estaremos seguros de que nuestro proceso mejora.

8) Resultados:

Analizando los resultados vemos que el Ing. X logro terminar el desarrollo del

proyecto el 11 de mayo, mientras que en el diagrama de Gantt había estimado

el desarrollo hasta antes del 3 de mayo, por lo que tuvo un retraso de algo más

de una semana. Para el Ing. X, tal vez este retraso no significa mucho, pero no

sucede lo mismo en proyectos grandes donde implique más 10000 LOC, donde

los errores de etapas superiores provocan efectos dominó.

39
 En cuanto al Rendimiento que dio el resultado de 55.6%, advierte que aún

estamos eliminando pocos errores en las revisiones, por lo que significa más

tiempo en las pruebas. Se debe apuntar como objetivo obtener arriba del 75%.

Sobre el valor de Valoración/Fallo de 0.52 indican que estamos gastando

mucho tiempo en las pruebas y compilación, por lo que debemos mejorar

nuestra forma de eliminar defectos en las revisiones. Se recomienda llegar a

valores de V/F superiores a 2.

El tiempo por fase nos indica el porcentaje que requerimos para cada fase dado

un tiempo total de desarrollo. De igual manera los defectos Introducidos y

Eliminados indican el porcentaje de defectos que se introduce y elimina en

ciertas fases del desarrollo, estos datos son útiles para nuevas estimaciones.

9) Postmortem:

Hasta aquí X habría completado el software de la empresa de Galletas y Fideos.

Lo único que falta es la fase de PostMorten, que corresponde al completado del

Resumen del plan del proyecto con los valores reales. Debemos registrar un

tiempo de postmorten estimado en el cuaderno de registro de tiempos.

Figura 26: Registro de tiempos en la fase de postmortem

40
Defectos/KLOC = 1000 * Defectos Introducidos / LOC Nuevas = 1000 * 45 /

730 = 61.6

Rendimiento = 100 * (Defectos eliminados antes de compilar) / (Defectos

Introducidos antes de compilar) = 100 * 25 / 45 = 55.6

Valoración/Fallo = Tiempo Revisión / (tiempo compilación + tiempo pruebas)

= 374 / (80+636) = 374 / 716 = 0.52

41
42
 Figura 27: Plan del proyecto completo

10) Historiales:

Estimación de LOC Nuevas y cambiadas. X puede empezar a llenar las tablas

de Tamaño de Programas para tener un historial y sirva para próximas

estimaciones por comparación.

43
 Figura 28: Historial de tamaño de programas

Con este historial es posible calcular una parte de un nuevo programa. Por ej.

Si X trabajo en la inserción, modificación y eliminación de 7 datos de una tabla

y le costó programar N líneas y T tiempo, en un programa nuevo usara

igualmente una inserción en una base de datos, esta vez con 10 datos, y los

anteriores datos puede usarlos de la siguiente manera:

44
 Figura 29: Historial de tamaño de programas de referencia

11) Resumen Semanal de Actividades

A partir del cuaderno de registro de tiempos de las últimas semanas, el Ing. X

puede obtener un Resumen Semanal de Actividades que le permitirá conocer

el tiempo que necesita en una semana para llevar a cabo actividades de

programación. En caso de tener otras actividades, como por ejemplo pasar

clases de actualización por las mañanas, el Ing. deberá registrarlo en esta tabla.

Así se irá obteniendo distintos resúmenes semanales, tendrá uno cuando

programa y pasa clases, otro cuando solo programa, etc. De esta manera, antes

de obtener un nuevo compromiso, X analizará el tipo de semanas que vienen,

y en base a criterio aceptar o rechazar. A continuación, veamos como X obtiene

un resumen semanal a partir del cuaderno de registro de tiempos.

45
46
Figura 30: Registro de tiempos

47
De la primera semana que trabajo X, debería completar un resumen semanal

como sigue:

Figura 31: Resumen primera semana

48
Una segunda semana con las mismas actividades sería:

Figura 32: Resumen segunda semana

Con esto queda completada una primera adopción del PSP del Ing. X. De esta

manera se irá completando la base de datos de funciones que permitan una

mejor estimación. También contará con un registro semanal de tiempo que lo

protegerán del exceso de compromisos.

49
12) Estimación de nuevos proyectos

Ahora para cualquier otro pedido de software X, ya contara con datos reales

que registró en sus anteriores Resúmenes del Plan, permitiendo que el nuevo

Resumen Del Plan del proyecto se pueda iniciar correctamente. A

continuación, veamos como completar una nueva estimación a partir del último

Resumen:

X supone que las LOC Nuevas y cambiadas Estimadas = 400

50
Figura 33: Estimación de nuevos proyectos

51
 A partir de aquí comienza nuevamente todo el proceso anteriormente descrito,

el cual básicamente nos permitirá empezar a adoptar el PSP.

5. Conclusiones.

EL PSP es una disciplina hecha para que el ingeniero de software desarrolle

programas en alta calidad, siguiendo los procesos recomendados.

Permite medir, evaluar y monitorear cada avance que se realiza en el desarrollo

de software, identificando posibles errores y reduciéndolos.

Es posible aplicar PSP en cualquier etapa del ciclo de desarrollo del software.

52
6. Bibliografía.

Espejo Chavarría, A., Bayona Oré, S., & Pastor, C. (2016). Aseguramiento de la Calidad en el
Proceso de Desarrollo de Software utilizando CMMI, TSP y PSP. Lima.

Niño Manrique, Jhon Fredy (2012). Estudio Empírico de aplicación de PSP para el desarrollo
transversal de competencias de Gestión, en estudiantes de un programa de tecnología en
sistemas. Medellín

Salinas Erick, Cerpa Narciso & Rojas Pablo. (2010). Arquitectura orientada a servicios para
software de apoyo para el proceso personal de software. Chile.

Soto Duran, D., Acosta Gómez, J. & Vargas Agudelo, F. (2010). Aplicación del proceso personal de
software en profesional informático. Colombia.

Soto Duran, D., & Reyes Gamboa, A. (2010). INTRODUCIENDO PSP (PROCESOS PERSONAL DE
SOFTWARE) EN EL AULA. Colombia.

Larco Ampudia, Enrique Andres (2007). Uso del PSP (Personal Software Process) en el desarrollo
del software . Quito.

53