1. El trabajo del ingeniero del Software

1. El trabajo del ingeniero del Software

1.1. ¿Qué es la ingeniería del Software?

El trabajo de un ingeniero del software es entregar productos software de alta calidad a unos costes establecidos y en un  plazo determinado. Para hacer un trabajo efectivo se precisa:

✔ Planificación.

✔ Realización del trabajo de acuerdo con el plan.

✔ Esforzarse en producir productos de máxima calidad.

El software de los ordenadores es crítico para muchos negocios: al aumentar su importancia, la eficacia de los grupos de  ingeniería del software es cada vez más importante. El activo más importante del ingeniero del software es hacer coincidir  los compromisos con la calidad de los productos.

1.2. El Proceso Software Personal (PSP)

El 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 esos planes.

✔ Explica cómo los procesos definidos guían su trabajo.

1.3. La disciplina del trabajo de alta calidad

La disciplina se define como una actividad o ejercicio que desarrolla o mejora habilidades. La disciplina del PSP pro­

porciona un marco de trabajo estructurado para desarrollar las habilidades personales y los métodos necesarios para un inge­

niero del software. De esta forma se disminuye el coste y el tiempo del aprendizaje y se reduce el riesgo.

1.4. ¿Cómo mejorar la calidad del trabajo? El proceso de mejora

Para conseguir una mejora se debe de poder cuantificar el trabajo y evidentemente se debe cambiar el proceso. Los pa­

sos necesarios en el proceso de mejora son:

Definir el objetivo

de la calidad Medir la calidad

del producto Comprender

el proceso

Ajustar

el proceso Utilizar el

proceso ajustado Medir

los resultados Comparar los resultados con el objetivo

Realimentar y continuar mejorando

2. La gestión del tiempo

2.1. Fundamentos para gestionar el tiempo

✔ Probablemente se dedicará el tiempo a lo mismo que en la anterior. Cuidado con ciertos momentos temporales 

“especiales”, como la época de exámenes para un estudiante.

✔ Un plan realista supone controlar la forma de usar el tiempo.

✔ Para comprobar la exactitud de las estimaciones de tiempo se deben documentar y posteriormente compararlas  con lo que realmente se hace.

✔ Planes más precisos suponen descubrir los errores de los planes anteriores y qué es mejorable.

✔ Para gestionar el tiempo hay que planificarlo y seguir el plan.

2.2. Pasos en la comprensión del uso del tiempo

1. Clasificar las actividades principales.

2. Registrar el tiempo dedicado a las actividades principales.

3. Registrar el tiempo de forma normalizada para que los datos estén organizados y sean útiles.

4. Guardar los datos de tiempo en un lugar adecuado (el Cuaderno de Ingeniería).

2.3. Cuaderno de Ingeniería

✔ Servirá para consignar el control del tiempo y otras cosas como compromisos, ideas, notas, etc.

✔ Los cuadernos deben numerarse para poder almacenarlos en orden.

✔ Las páginas deben numerarse dejando las dos primeras para que hagan las veces de índice.

3. El control del tiempo

3.1. El registro de los datos de tiempos

El objetivo del registro del tiempo es obtener datos de cómo se trabaja realmente. La forma y procedimiento utilizado no  es importante mientras los datos sean exactos y completos.

Dado que la cantidad de tiempo no interrumpido que se dedica a una tarea es inferior a la hora, medir el trabajo en horas  no proporciona el detalle necesario para planificar y gestionar el trabajo. Es más fácil usar minutos.

3.2. Uso de una tabla de Registro de Tiempos normalizada

La tabla utilizada tiene los siguientes campos:

✔ Fecha de realización de la actividad.

✔ Comienzo de la actividad.

✔ Fin de la actividad.

✔ Tiempo de interrupción. Sumatorio de tiempo debido a interrupciones.

✔ ∆ tiempo. Tiempo dedicado a cada actividad, minutos entre comienzo y fin menos el tiempo de interrupción.

✔ Actividad. Nombre descriptivo para la actividad.

✔ Comentarios. Descripción completa de cualquier cosa que pueda ser útil a la hora de analizar los datos.

✔ C (Completado). Se indica con una cruz si la tarea se ha completado.

✔ U (Unidades). Número de unidades de una tarea acabada.

Cuaderno de Registro de Tiempos:

Nombre: __________________________________________________________ Fecha: ______________________________

Fecha Comienzo Fin Tiempo de 

interrupción ∆ de

tiempo Actividad Comentarios C U

03/11 9:00 9:50 10+7 33 Codificar Hotel SI 1

12:40 13:23 12+5 26 Leer Perl X 7

. . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3. Gestión de las interrupciones

Las interrupciones son un problema del control del tiempo, para su control es útil un cronómetro. El tiempo de interrup­

ción es muy variable y los datos registrados pueden utilizarse para comprender con qué frecuencia se interrumpe el trabajo,  lo que ayuda a mejorar la calidad y eficiencia en el trabajo.

3.4. Control de las tareas finalizadas

Para controlar el gasto del tiempo se necesita controlar los resultados producidos. Las columnas C y U del Cuaderno de  Registro de Tiempos ayudan a identificar rápidamente el tiempo dedicado a las distintas tareas. Una unidad de trabajo es más  útil cuando es más detallada.

Evidentemente, el ingeniero debe llevar consigo una copia del Cuaderno de Registro de Tiempos, por lo que puede ser  apropiado incluirlo en el Cuaderno de Ingeniería.

Para llevar a cabo el control del tiempo de una forma consistente y precisa pueden ayudar ciertos trucos:

✔ Llevar siempre el cuaderno de notas encima.

✔ Si ocasionalmente se olvida reflejar una hora, hacer una estimación y figurarla.

✔ Utilizar un cronómetro para registrar las interrupciones.

✔ Resumir el tiempo puntualmente.

4. Planificación de períodos y productos

4.1. Planes de períodos y productos

Hay dos clases de planificación. La primera está basada en un período de tiempo (día, semana, mes, ...). Un plan de pe­

ríodo hace referencia a la forma de planificar la utilización del tiempo durante ese período. La segunda clase de plan está ba­

sada en la actividad (programar, escribir informes, ...). Se les denomina planes de producto. Los productos pueden ser tangi­

bles o intangibles.

4.1.1. Relación entre planes de periodo y planes del producto

La gestión corporativa proporciona fondos para que los departamentos de ingeniería y fabricación desarrollen y produz­

can productos. La ingeniería desarrolla productos y los envía a fabricación, y son entregados al cliente por el grupo de mar­

keting.

Ingeniería y fabricación proporciona planes de producto a finanzas y administración que los usan para generar los planes  del periodo para ingresos y gastos trimestrales y anuales. Finanzas y administración marca los precios y previsiones a inge­

niería y fabricación. La gestión corporativa decide qué dividendos o intereses se pagará a los inversores y las nuevas inver­

siones. Tras conocer los dividendos proporcionará fondos a ingeniería, cerrando el ciclo.

Aunque los planes del período y del producto están relacionados, son diferentes. El principal propósito del trabajo es  producir productos y servicios de valor para los otros. El coste, la planificación y localidad de esos bienes y servicios son lo  más importante. No se puede hacer un plan competente de uno sin planificar el otro.

Gestión  corporativa Tareas basadas 

en el producto

Clientes

Ingresos

Marketing

Ingeniería Fabricación

Finanzas Administración Planes de

productos

Precios y Previsiones Productos

Tareas basadas  en el periodo

Inversores

Inversiones Dividendos / Intereses

Fondos Planes

del período

4.2. Resumen Semanal de Actividades

Para hacer un plan del período, es importante conocer como se gasta el tiempo. El primer paso es registrar el tiempo en  el Cuaderno de Registro de Tiempos. El segundo paso es resumir los datos de una forma útil. Se genera así el Resumen Se­

manal de Actividades:

Nombre _____________________________________________________ Fecha __________________

Tarea ^{Codificar Leer Resumir} Total

Fecha ^{79 79}

Lunes 03/11 43 43

Martes

Miércoles ^{128 50 45 223}

Jueves ^{124 124}

Viernes ^{166 166}

Sábado ^{36 36}

Domingo ^{48 48}

Total ^{337 258 124 719}

Tiempos y Medias del Período Número de semanas (número anterior + 1): __3__

Resumen de las semanas anteriores

Total ^{570 412 138 1120}

Media ^{285 206 69 560}

Máxima ^{311 260 80 651}

Mínima ^{259 152 58 469}

Resumen incluyendo la última semana

Total ^{907 670 262 1839}

Media ^{302 223 87 612}

Máxima ^{337 260 124 721}

Mínima ^{259 152 58 469}

Los datos en el Resumen Semanal de Actividades ayudan a entender cómo se gasta el tiempo de forma que se pueda esti­

mar los tiempos máximos para tareas complicadas, y los mínimos para otras más sencillas. Estos datos son útiles para plani­

ficar semanas siguientes.

Evidentemente, dependiendo de las actividades que se realizan, el período de esta tabla puede variar, siendo quincenal o  mensual según las necesidades.

5. La planificación del producto

5.1. ¿Qué es un plan del producto?

La planificación es una parte crítica del trabajo del ingeniero del software, y por lo tanto todo ingeniero tiene que saber  cómo hacerlo. La clave está en la práctica. El plan del producto ayuda a decidir cuánto tiempo se necesita para hacer el tra­

bajo y cuándo se acabará, a la vez que ayuda al control del progreso.

Un adecuado plan del producto requiere tres cosas:

✔ Tamaño y características más importantes del producto a realizar.

✔ Una estimación del tiempo requerido para hacer el trabajo.

✔ Una previsión de la planificación.

5.2. Definiciones

✔ Producto. Algo que se produce para alguien.

✔ Proyecto. Normalmente produce un producto.

✔ Tarea. Elemento de trabajo.

✔ Proceso. Forma de hacer proyectos.

✔ Planes. Describen la forma en que se hace un proyecto (o tareas individuales), cómo, cuándo y coste tendrá. 

✔ Trabajo. Algo que se hace, tanto un proyecto como una tarea.

5.3. El Cuaderno de Trabajos

Diseñado para registrar los datos de tiempos estimados y reales, es un documento de planificación del producto, ya que  trata datos del producto. A la inversa, el Cuaderno de Registro de Tiempos y el Resumen Semanal de Actividades contienen  datos de planificación de períodos.

Nombre: ____________________________________________________________ Fecha: _______________________

Trabajo Fecha Proceso Estimado Real Hasta la fecha

Tiempo Unidades Tiempo Unidades Velocidad Tiempo Unidades Velocidad Máximo Mínimo

1

3/11 Codif. 100 1 158 1 158 158 1 158 158 158

Descripción: Escribir el programa 1 (minutos por programa)

2

3/11 Leer 50 2 80 2 40 80 2 40 40 40

Descripción: Leer siete captulos de PSP (minutos por captulo)í í

3

4/11 Codif. 158 1 124 1 124 282 2 141 158 124

Descripción: Escribir el programa 2 (minutos por programa)

. . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Descripción: ^{. . .}

En general, las primeras anotaciones serán por suposición. Tras un cierto número de anotaciones se puede valorar el tra­

bajo y utilizar los valores acumulados para realizar estimaciones equilibradas; es decir, que se compensarán entre ellas. Al  estimar grandes trabajos es más probable conseguir una aproximación razonable al plan global.

6. El tamaño del producto

6.1. El proceso de planificación del producto

Para hacer un buen plan del producto es necesario utilizar medidas precisas; pesar de todo, la planificación no es un pro­

ceso exacto. Lo mejor, es comparar lo que se ha hecho con lo que se tiene que hacer.

Las tareas varían considerablemente en tamaño y complejidad, es útil tener una forma de compararlas. La identificación  de medidas del tamaño es complejo ya que hay diferencias en la complejidad de una misma tarea. 

6.2. El tamaño de un programa

Para estimar el tiempo requerido para codificar un programa, es útil conocer los tiempos dedicados a programas simila­

res. La medida que permite definir el tamaño de un programa es el LOC (Lines Of Code). Al contar las LOC se asume que  no se cuentan las líneas en blanco ni comentarios. Es importante adoptar una forma normalizada de codificación para ser co­

herente en la cuenta de LOC.

Existen campos donde las LOC no son aplicables, como en construcción de menús, ficheros, páginas de informes o pan­

tallas. A falta de una medida, puede ser adecuado contarlas por unidades.

6.3. Estimación del tamaño del programa

La dificultad de la estimación de tiempo en la codificación de programas es que no es posible contabilizarlos hasta que  se finalizan. En primer lugar se debe cuantificar las LOC y a partir de ahí, el número de minutos por LOC.

Existen muchos métodos para estimar el tamaño de los programas, pero primero se deben de examinar los requisitos  para los programas a desarrollar. Después, clasificar los tamaños relativos de los nuevos programas entre los programas que  ya se han escrito. Finalmente, basándose en la experiencia y dependiendo de la clasificación, estimar las LOC.

Nombre: ____________________________________________________ Fecha: ___________________

Programa Tiempo de

desarrollo LOC Minutos/LOC Funciones

4 93 10 9.30 Bucle W HILE sencillo

2 69 11 6.27 Sentencia CASE sencilla

3 114 14 8.14 Sentencia CASE grande

. . . . . . . . . . . . . . .

6.4. Estimaciones de tamaños mayores

Los programas contienen una mezcla de funciones y procedimientos, lo que hace difícil relacionarlos con programas de­

sarrollados previamente. Como solución se puede adoptar un formulario que contenga varios programas o funciones y pro­

cedimientos incluidos en programas. El objetivo es construir un registro histórico de elementos previamente escritos junto  con los datos de cuantas líneas de código contiene cada uno. De esta forma para considerar las funciones de un nuevo pro­

grama, basta con estimar el tamaño de cada función y sumar todas las estimaciones de funciones para obtener la estimación  total del programa.

Nombre: ____________________________________________________ Fecha : ________________

Programa LOC Funciones anteriores Funciones estimadas Mínimo Media Máximo Bucles

4 10 W HILE sencillo

5 14 W HILE grande W HILE grande 7 11 14

Case

2 11 CASE sencillo CASE sencillo 5 8 11

3 14 CASE grande

Estimado ^{12 19 25}

7. La gestión del tiempo

7.1. Elementos de la gestión del tiempo

Los datos reunidos sirven para gestionar el tiempo de la siguiente forma:

✔ Decidir cómo utilizar el tiempo.

✔ Hacer una estimación de tiempo.

✔ Controlar la forma de utilizar el tiempo frente a lo estimado.

✔ Decidir qué cambios hacer para llevar las acciones en concordancia con lo estimado.

El Resumen Semanal de Actividades muestra los tiempos medio, máximo y mínimo que se dedican a cada actividad se­

manalmente. Un análisis de las categorías puede determinar el grado de detalle de las mismas. Para gestionar el tiempo es  importante centrarse en aquellas que consumen más tiempo.

7.2. Cómo hacer una estimación de tiempo

Comenzando por los datos de cómo se ha utilizado anteriormente el tiempo, se pueden asignar cantidades de tiempo que  probablemente se utilizarán de cada categoría en el futuro.

Un ejemplo de estimación de tiempo preliminar será:

Actividad Minutos

estimados Minutos reales

Codificar 360

Leer libros 180

Resumir 150

Preparar ex menesá 120

Otros 30

Total ⁸⁴⁰

Se debe de reequilibrar gradualmente la forma de utilizar el tiempo, ya que es impensable dedicar más tiempo a una ta­

rea sino se identifican otras que se puedan acortar.

7.3. Establecer reglas básicas

No todo el tiempo se puede gestionar de forma regular, por ello, para proporcionar una guía de tareas diarias se necesita  una estimación. Una forma útil de hacer esto es utilizando una estimación semanal de actividades:

Nombre: _____________________________________ Fecha: _________________

Estimación semana #1

Tarea ^{Codif. Leer Resumir . . .} Total

Lunes ^{40 50 90}

Martes ^{120 40 160}

Miércoles ^{40 50 90}

Jueves ^{120 40 160}

Viernes ^{40 50 90}

Sábado ^{120 120}

Domingo

Total ^{360 200 150 710}

7.4. Priorizar el tiempo

Tras analizar las tareas semanales, éstas se pueden dividir en fijas, exigidas y discrecionales (por ejemplo). Este análisis  proporciona una herramienta para examinar la distribución personal del tiempo en una tabla Resumen Global de Tiempos  Semanales:

Nombre: ___________________________________________ Fecha: __________________

Actividad ^{Trabajo U NED} Comer / Dormir Otros Total

Fija

Trabajo 1.920 1.920

Exigida

Trabajo casa 840 840

Inform ticaá 1.800 1.800

Discrecional

Comer 1.000 1.000

Dormir 2.700 2.700

Entretenimiento 1.820 1.820

Totales ^{2.760 1.800 3.700 1.820 10.080}

Conforme se controle el tiempo, se debe comparar el tiempo real dedicado frente al estimado. Si el tiempo es gestionado  consistentemente con la estimación, no serán necesarios cambios, en caso contrario se deben reajustar las estimaciones. Es  importante anotar las nuevas estimaciones.

7.5. Sugerencias para la gestión del tiempo variable

Para establecer las reglas básicas para la gestión del tiempo variable, se deben considerar las siguientes cuestiones:

✔ ¿Qué actividades son de máxima prioridad?

✔ ¿Hay tareas que se deben realizar en momentos específicos?

✔ ¿Hay actividades que a hacer tan pronto como haya tiempo?

8. Gestión de los compromisos

8.1. Definición de compromiso

Un verdadero compromiso, es tanto personal como contractual y requiere un acuerdo voluntario y explícito entre dos o  más partes sobre:

✔ Qué se hará.

✔ Los criterios para determinar que está hecho.

✔ Quién lo hará.

✔ Cuándo se hará.

✔ La compensación u otra retribución que se dará a cambio.

✔ Quién proporcionará la compensación o retribución.

8.2. Responsabilidad para hacer compromisos

Se puede asegurar que los compromisos son responsables y están bien gestionados de la siguiente forma:

✔ Analizar el trabajo antes de aceptar el compromiso.

✔ Apoyar el compromiso con un plan.

✔ Documentar el compromiso.

✔ Ante la incapacidad de cumplir el compromiso comunicarlo a la otra parte tan pronto como se sepa e intentar mi­

nimizar el impacto.

8.3. Gestión de compromisos

La gestión de los compromisos, además de para evitar que sean olvidados, sirve para planificar el tiempo cuando el tra­

bajo a hacer excede del tiempo disponible. Cuando se tenga que faltar a un compromiso se debe notificar tan pronto como se  sepa a la otra parte para poder trabajar juntos en la resolución de los problemas derivados. Nunca se debe abandonar sin in­

tentar cumplir con el compromiso utilizando todos los medios (eso incluye contactar con un experto independiente, añadir  recursos, etc.).

Los compromisos incumplidos generalmente conducen a molestias e insatisfacciones. Como consecuencia de una mala  gestión se pueden producir las siguientes situaciones:

✔ El trabajo requerido excede del tiempo disponible   . Cuidado con obtener nuevos compromisos cuando ya no hay  tiempo disponible a causa de otros compromisos en curso.

✔ Fallar al enfrentarse a los compromisos   . Pensar que un trabajo es más fácil de lo que realmente es.

✔ Prioridades mal colocadas   . Cuando se está desbordado se tiende a realizar primero las tareas más inmediatas, no  las más importantes. Esto puede ser contraproducente. Es necesario reestructurar todos los compromisos.

✔ Pobre calidad del trabajo   . Bajo presión y prisas puede que el trabajo pierda calidad al hacer recortes y que se co­

metan “errores tontos”.

✔ Pérdida de confianza   . Tal reputación es difícil de reparar.

✔ Pérdida de respeto sobre las opiniones   . Cuando se pierde la confianza en el cumplimiento de los compromisos, es  probable que tampoco se tengan en cuenta las opiniones, o que ni se soliciten.

La confección de una Lista de Compromisos será de gran ayuda para gestionarlos:

Nombre: _________________________________________________ Fecha: ________________

Fecha 

comprometida Compromiso ¿Con 

quién? ^Horas Fecha de 

inicio Se consigue Semanal

L M X J V Trabajo remunerado Gerente 24'0 N minaó

L M V Entregar resumen AGDS Equipo 9'0 Aprobar

L M X J V Trabajo IBM (17.00 a 20:00) J. Stone 15'0 01/09 N minaó Otros

28/11 Pr ctica SDá Equipo 24'0 11/09 Aprobar

9. Gestión de las programaciones

9.1. Diagrama de Gantt

Es una forma útil de presentar el flujo general de las tareas de un proyecto.

Una vez desglosado el trabajo en tareas y cuantificado el tiempo necesario para cada una de ellas, se confecciona el dia­

grama de Gantt:

Proyecto: _____________________________ Autor: _________________________ Fecha: _________________

tareaID Nombre 3­9

Nov. 10­16

Nov. 17­23

Nov. 24­30 Nov. 1­7

Des. 8­14

Des. 15­21

Des. 22­28

Des. 29­4 Des.

1 Requisitos 2 Terminado 3 Estudiar y planificar 4 Propuesta 5 Aceptada 6 Dise oñ . . . . . .

Las barras muestran las fechas previstas de comienzo y fin de cada tarea. Unos óvalos representan puntos de control.

Cuando la programación que se elabora implica a varias personas se debe:

1. Asegurarse que cada persona conoce las tareas que debe hacer.

2. Obtener un compromiso de fechas para cada una de estas tareas.

3. Identificar las interdependencias entre las tareas.

4. Documentar cada una de estas interdependencias.

5. Revisar la programación propuesta y las interdependencias con todas las personas implicadas, asegurándose de que  no hay conflictos, desacuerdos o malentendidos.

6. Revisar la programación para asegurarse de que cubre todas las tareas necesarias para completar el trabajo.

Un punto de control o hito es un punto que, objetivamente, se puede identificar en un proyecto. Presupone que se ha  completado una parte del proyecto y que por tanto se ha realizado un cierto grado de progreso. Al incluir varios hitos en el  proyecto se puede ver fácilmente si se está dentro de lo programado o no.

Los hitos deben ser claros y no ambiguos: una acción específica que se hace o no se hace.

La frecuencia de los puntos de control es importante: ni demasiado próximos en el tiempo ni demasiado distanciados. 

Situar un punto de control cada 5 horas de trabajo más o menos es una buena opción. En cualquier caso, es conveniente que  exista al menos un punto de control semanal, para evitar el olvido.

9.2. Seguimiento de los planes de los proyectos

Informar sobre el estado real de un proyecto es esencial cuando se hacen para los clientes, que son los que pagan.

El control de los planes también permite actuar  a tiempo frente a un problema.

El diagrama de Gantt se puede usar para informar del progreso:

Proyecto: _____________________________ Autor: _________________________ Fecha: __02­12­2003____

tareaID Nombre 3­9

Nov. 10­16

Nov. 17­23

Nov. 24­30 Nov. 1­7

Des. 8­14

Des. 15­21

Des. 22­28

Des. 29­4 Des.

1 Requisitos 2 terminado 3 Estudiar y planificar 4 Propuesta 5 aceptada 6 Dise oñ . . . . . .

El ejemplo muestra una situación concreta. La línea vertical indica la fecha en que se realiza el informe (02/12/03). Se  puede apreciar que la tarea ID­1 ha sido completada; la ID­3, casi; y la ID­4, un poco menos. Además, un punto de control  (ID­2) ha sido superado (la flecha indica la fecha real de su realización).

Es importante evitar una falsa visión (demasiado optimista) de la situación de progreso del proyecto:

✔ Definir los puntos de control con claridad y por escrito.

✔ No cambiar la programación hasta tener un nuevo plan.

✔ Informar de la situación real frente al plan, sin cambiarlo.

✔ Para mostrar una nueva estimación de fechas, dejar la programación original en el mismo lugar y anotar las nuevas  fechas con líneas de puntos.

✔ Guardar copias de la programación original y de todas las actualizaciones.

9.3. Seguimiento del valor conseguido

La siguiente tabla permite realizar un seguimiento adaptativo del proyecto:

Semana Valor Planificado Valor Ganado Valor Estimado

1 13.2% 16.2%

2 26.2% 38.2%

3 47.3% 69.4%

4 74.8% 92.5%

5 86.1% 115,7%

6 100.0% 138.8%

El valor planificado desglosa el proyecto porcentualmente. Ha medida que avanza y se va calculando el porcentaje real­

mente realizado (valor ganado) se puede realizar una estimación de la parte que queda a la luz del “ritmo” de trabajo.

En el ejemplo anterior, se puede apreciar que el trabajo estaba proyectado para seis semanas, pero tras consignar el valor  ganado (lo realmente hecho) durante las tres primeras semanas, los cálculos sobre el valor estimado indican que, al ritmo ac­

tual, se podrá finalizar el trabajo en cinco semanas; una antes de lo previsto.

El valor ganado ayuda a controlar con precisión el estado del proyecto y estimar exactamente cuándo acabará.

10. El plan del proyecto

10.1. La necesidad de los planes de los proyectos

El plan del proyecto define el trabajo y cómo se hará. Proporciona una definición de cada tarea principal, una estimación  del tiempo y de los recursos necesarios y un marco de trabajo para gestionar la revisión y el control. Si está documentado es  un punto de referencia para comparar con el rendimiento real, con el fin de ver los errores de estimación y mejorar la exacti­

tud en la planificación.

10.2. Resumen del plan del proyecto

Nombre: Fecha:

Programa: Programa #:

Resumen  Plan  Real  Hasta la fecha 

Minutos/LOC  LOC/Hora  Defectos/KLOC  Rendimiento  V/F 

Tamaño Programa (LOC) Total nuevo & cambiado Tamaño máximo Tamaño mínimo Tiempo por Fase (min)

Planificación Diseño Codificación

Plan Real Hasta la fecha % Hasta la fecha

Revisión del código Compilación Pruebas Postmortem

Total

Tiempo máximo Defectos introducidos

Planificación Diseño Codificación

Plan Real Hasta la fecha % Hasta la fecha

Revisión del código Compilación Pruebas

Total

 Def/Hora Tiempo mínimo

Defectos eliminados Planificación Diseño Codificación

Plan Real Hasta la fecha % Hasta la fecha

Revisión del código Compilación Pruebas

Total

 Def/Hora

10.3. Resumen

La sección Resumen contiene los datos de la velocidad utilizados para hacer el plan. También proporciona un lugar para  registrar la velocidad real después de acabar el trabajo. En la entrada Minutos/LOC (minutos por líneas de código) de la co­

lumna Plan se utilizan los datos históricos o del Cuaderno de Trabajos. En la entrada LOC/Hora (líneas de código por hora)  se debe introducir el valor planificado y valor el real como 60/(Minutos/LOC).

10.4. Tamaño del Programa (LOC)

Los datos de Total Nuevo & Cambiado tiene las LOC escritas realmente, es decir las LOC totales menos aquellas que se  hayan reutilizado. Si en la parte de código reutilizado se debe realizar alguna modificación también se contarán esas LOC.

Los valores Tamaño máximo y Tamaño mínimo se obtienen a partir de los valores obtenidos en el Cuaderno de Trabajos.

10.5. Tiempo por Fase

Esta sección se utiliza para los datos de las fases del proceso de desarrollo del software. Para calcular el tiempo total  planificado para el desarrollo de un nuevo programa, se estima el tamaño del programa en  LOC  y se multiplica por  Minutos/LOC planificados de la parte superior de la tabla. Esto produce una estimación de los minutos totales para desarro­

llar el programa.

Tiempo por fase total = Total Nuevo & Cambiado × Minutos / LOC Tiempo por fase máximo = Tamaño máximo × Minutos / LOC Tiempo por fase  mínimo = Tamaño mínimo × Minutos / LOC

11. El proceso de desarrollo del software

11.1. ¿Por qué se utilizan los procesos?

Un proceso es un conjunto definido de pasos para hacer un trabajo. Cada paso o fase de un trabajo tiene especificado  unos criterios de entrada que deben ser satisfechos antes de comenzar la fase. De igual forma, cada fase tiene unos criterios  de salida que deben satisfacerse antes de dar por terminada la fase.

11.2. Algunas definiciones

✔ Producto. Algo que se produce para un colaborador, un empresario o un cliente.

✔ Proyecto. Normalmente produce un producto.

✔ Tarea. Elemento de trabajo.

✔ Proceso. Forma de hacer proyectos.

✔ Los procesos tienen varias fases o pasos, como la planificación, el desarrollo y las pruebas.

✔ Una fase de un proceso puede estar compuesta de múltiples tareas o actividades, como pruebas de integración,  pruebas del producto y pruebas del sistema.

✔ Planes. Describen la forma en que un proyecto concreto va a ser hecho, cómo, cuándo y qué coste tendrá. También  se pueden planificar tareas individuales.

✔ Trabajo. Algo que se hace, tanto un proyecto como una tarea.

Cuando un proceso está totalmente descrito, se denomina proceso definido, el cual está compuesto normalmente por:

✔ Guiones. Conjuntos de pasos escritos, que los usuarios o agentes del proceso siguen cuando utilizan el proceso.

✔ Tablas. Registros y resúmenes, que se utilizan para registrar y almacenar los datos del proyecto.

✔ Plantillas.

✔ Estándares.

11.3. Guión del Proceso

El guión inicial del PSP es el siguiente:

Propósito • Guiar en el desarrollo de pequeños programas.

Criterios de entrada • La descripción del problema.

• Tabla Resumen del Plan del Proyecto del PSP.

• Datos de tamaños y tiempos reales de programas anteriores.

• Cuaderno de Registro de Tiempos.

1 Planificación • Obtiene una descripción de las funciones del programa.

• Estima las LOC Máxima, Mínima y Total requeridas.

• Determina los Minutos/LOC.

• Calcula los tiempos de desarrollo Máximo, Mínimo y Total.

• Escribe los datos del plan en la tabla Resumen del Plan del Proyecto.

• Anota el tiempo de planificación en el Cuaderno de Registro de Tiempos.

2 Diseño • Diseña el programa.

• Anota el diseño en el formato especificado.

• Anota el tiempo de diseño en el Cuaderno de Registro de Tiempos.

3 Codificación • Implementa el diseño.

• Utiliza un formato estándar para introducir el código.

• Anota el tiempo de codificación en el Cuaderno de Registro Tiempos.

4 Compilación • Compila el programa.

• Corrige todos los errores encontrados.

• Anota el tiempo de compilación en el Cuaderno de Registro Tiempos.

5 Pruebas • Prueba el programa.

• Corrige todos los errores encontrados.

• Anota el tiempo de pruebas en el Cuaderno de Registro Tiempos.

6 Postmortem • Completa la tabla de Resumen del Plan del Proyecto con los datos de tiempo y tamaño  reales.

• Anota el tiempo postmortem en el Cuaderno de Registro Tiempos.

Criterios de salida • Programa probado a fondo.

• Diseño adecuadamente documentado.

• Listado completo del programa.

• Resumen del Plan del Proyecto completado.

• Cuaderno de Registro de Tiempos completado.

11.4. Puntos de control y Fases

El proceso de desarrollo del software, extiende la idea de punto de control desde uno pocos puntos a todas las fases del  proceso. Con un proceso definido, cada fase produce un resultado específico y por lo tanto la conclusión de una fase es un  punto de control medible.

11.5. Actualización de la Tabla Resumen del Plan del Proyecto

La sección Tiempo por Fase tiene una fila por cada fase del proceso. Durante la fase de planificación se escriben los da­

tos bajo la columna Plan. Durante la fase Postmortem, se escriben los datos bajo la columna Real.

La columna Hasta la Fecha contiene el total de todos los tiempos dedicados en cada fase para todos los programas aca­

bados. La columna % Hasta la Fecha tiene el porcentaje de los tiempos de la columna Hasta la Fecha.

12. Defectos

12.1 ¿Qué es la calidad del software?

Un producto que proporciona las prestaciones que son más importantes para los usuarios, es un producto de calidad. Las  necesidades de los usuarios se recogen en los documentos de requisitos, por lo cual, si estos no se entienden no se puede de­

sarrollar un programa de calidad.

Aunque las funciones del software son muy importantes para los usuarios, no serían útiles al menos que el software fun­

cione, por ello el primer aspecto de la calidad está relacionado con los defectos software. La primera prioridad del desarro­

llador debe ser entender los defectos que introduce y prevenirlos como pueda.

12.2 ¿Qué son los defectos?

Un defecto es un error  en un programa, en su diseño, requisitos, especificación o en la documentación. En definitiva un  defecto, reduce la capacidad de los programas para cumplir completa y efectivamente las necesidades de los usuarios. Es  una cosa objetiva que se puede identificar, describir y contabilizar.

Para mejorar la calidad del programa, es esencial que los ingenieros aprendan a gestionar todos los defectos que introdu­

cen en sus programas. Se debe de separar la identificación de los defectos de la determinación de sus causas. La eliminación  de defectos es un proceso más sencillo que su prevención.

Dado que encontrar y corregir los defectos software tiene un coste elevado, es importante minimizarlos, para ello se  debe aprender de los defectos introducidos, identificar los errores que los causan y aprender a no repetir el fallo en el futuro.

12.3 Tipos de defectos

Con el fin de poder analizar los defectos se deben categorizar, para poder observar las categorías más problemáticas, y  centrarnos en su prevención y eliminación.

Tipos de defectos

Número  Nombre del tipo Descripción

10 Documentación Comentarios, mensajes

20 Sintaxis Ortografía, puntuación, erratas, formato de las instrucciones.

30 Contruir paquetes Gestión del cambio, librerías, control de versión 40 Asignación Declaración, nombres duplicados, ámbito, límites.

50 Interfaz Llamadas a procedimientos y referencias E/S, formatos de usuario.

60 Chequeo Mensajes de error, chequeos inadecuados.

70 Datos Estructura, contenido

80 Función Lógica, punteros, bucles, recursión, defectos de función 90 Sistema Configuración, pruebas y otros problemas que soporta el sistema.

12.4 La comprensión de los defectos.

Reunir los defectos ayuda a comprender los errores y a encontrarlos, corregirlos y prevenirlos mejor. Para reunir los de­

fectos se debe:

➢ Registrar cada defecto encontrado en un programa.

➢ Registrar información suficiente sobre cada defecto para poder entenderlo posteriormente.

➢ Analizar los datos para ver que tipos de defectos causan los mayores problemas.

➢ Idear formas de encontrar y corregir estos defectos.

12.5 El cuaderno de registro de defectos.

El Cuaderno de Registro de Defectos está diseñado para ayudar a reunir datos sobre los defectos. Su formato es:

Esta tabla se utiliza para mantener los datos de cada defecto encontrado y corregido. Los datos se utilizarán en el Resu­

men del Plan del Proyecto. Cada defecto se debe anotar de forma separada y completa. Los campos son:

✗ Fecha: La que se encontro el defecto.

✗ Número: Número de orden secuencial de error encontrado.

✗ Tipo: Según lista de defectos.

✗ Introducido: Fase en la que se introduce (diseño, codificación, compilación,... etc).

✗ Eliminado: Fase en la que se encontró y corrigió el defecto.

✗ Tiempo de corrección: Medición o estimación del tiempo necesario para encontrar y corregir el defecto.

✗ Defecto corregido: Se ignora la primera vez. Si se introduce un defecto mientras se arreglaba otro introducir el nú­

mero de defecto incorrectamente corregido. Si no se puede identificar el número de defecto, anotar una × en la ca­

silla.

✗ Descripción: Breve descripción de forma clara del defecto.

Se deben de anotar en el Cuaderno de Registro de Defectos un defecto por cada corrección del programa, sin tener en  cuenta la naturaleza de la corrección y el número de mensajes de error del compilador. En general se considera un error los  cambios realizados sobre una fase anterior en la que nos encontramos del producto o parte del mismo.

12.6 U tilización del Cuaderno de Registo de Defectos.

El reunir los datos de los defectos permite:

✔ Mejorar la programación.

✔ Reducir el número de defectos de los programas.

✔ Ahorro de tiempo.

✔ Ahorro de dinero.

✔ Realizar el trabajo de forma responsable.

12.7 El proceso del PSP actualizado.

Durante la fase postmortem, se revisa el Cuaderno de Registro de Defectos y se contabilizan los defectos introducidos  en cada fase (planificación, diseño, codificación, compilación y pruebas) y se anotan en la columna Real del apartado defec­

tos introducidos. A continuación, se contabilizan los defectos eliminados en cada fase, y se anotarán en la columna Real del  apartado correspondiente. La columna de ambos apartados “Hasta la fecha” contabiliza los errores encontrados / eliminados  en cada fase hasta la fecha, la columna “% hasta la fecha” el tanto por ciento del total.

El dato “Hasta la Fecha” en Minutos/LOC se obtiene como el cociente entre el tiempo total del desarrollo Hasta la Fecha  y las LOC Nuevas & Cambiadas hasta la fecha. Las LOC/Hora se calculan dividiendo 60 por los Minutos/LOC hasta la Fe­

cha.

Tipos de defectos

10 Documentación 40 Asignación 70 Datos

20 Sintaxis 50 Interfaz 80 Función

30 Contrucción de paquetes 60 Chequeo 90 Sistema 100 Entorno

Nombre Fecha Programa #

Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido

Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido

Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido

Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido

13.Encontrar defectos.

13.1 Los pasos para encontrar defectos.

Hay varias formas para encontrar defectos en un programa, pero en esencia tienen los siguientes pasos:

1. Identificación de los síntomas del defecto.

2. Deducir de esos síntomas la localización del defecto.

3. Entender lo que es erróneo en el programa.

4. Decidir cómo corregir el defecto.

5. Hacer la corrección.

6. Verificar que se ha resuelto el problema.

13.2 Formas de encontrar y corregir defectos.

El compilador es una de las herramientas que ayudan a detectar errores, aunque no de forma completa, pueden evitar un  90% de errores sintácticos y algunos lógicos. Otra herramienta es por medio de las pruebas, estas dependen de los casos  planteados y de sus condiciones. Además las pruebas siguen obligando a moverse desde los síntomas al problema, y sólo ve­

rifican las condiciones probadas. Un tercer método es la entrega del programa al usuario y que éste informe de los errores  que identifique. La forma más efectiva de encontrar y corregir defectos es la revisión personal del código fuente del progra­

ma.

13.3 Revisión del código.

Para hacer la revisión de código se estudia el código fuente a partir de un listado, antes de compilarlo o probarlo. Tras  hacer el diseño o la codificación es más fácil recordar la intención que se tiene, simplificando la corrección del problema.

La revisión de código consume tiempo, pero su eficiencia es mayor que las pruebas, ya que se detectan los problemas y  no los síntomas. En el momento de revisión del código se piensa sobre lo que el programa debe hacer.

Las desventajas principales de las revisiones son que consumen tiempo y la dificultad de hacerlas  correctamente, sin  embargo la capacidad de revisión mejora con la práctica.

La razón más importante para revisar los programas antes de compilarlos y probarlos es la dificultad de convertir en un  producto de calidad un programa que ha sido varias veces parcheado.

13.4 El coste de encontrar y corregir defectos.

En los proyectos software, el producto es dividido en programas elementales o módulos. Tras el diseño, implementación  y compilación del mismo, se realizan las pruebas de unidad. Tras la combinación de módulos pasamos a las pruebas de inte­

gración. Se realizan varios niveles de pruebas de componentes antes de combinarlos en productos y realizar las correspon­

dientes pruebas. Finalmente se ensamblan los productos y se realizan las pruebas del sistema.

El coste medio de encontrar y corregir un defecto crece unas 10 veces en cada paso del proceso de desarrollo. Además  del coste, una razón importante para encontrar los defectos al principio, es que la compilación, depuración y pruebas tienen  una efectividad reducida.

13.5 El uso de las revisiones para encontrar defectos.

La razón principal de reunir los datos de defectos es para poder entender la clase de defectos que se pueden introducir. 

Los defectos de un programa nuevo serán parecidos a los encontrados en programas anteriores. Esto supone que la estrategia  de revisión se debe basar en el perfil personal.

El objetivo de la revisión de código es encontrar el mayor número de defectos lo más pronto posible en el proceso soft­

ware.

 Un guión para hacer revisión de código es:

Criterios de entrada: Comprobar que se dipone de:

✔ Especificación de requisitos. ^✔ Código fuente del programa

✔ Diseño del programa ✔ Estándares de codificación

1. Procedimientos de revisión Escribir el código fuente completo Imprimirlo en un listado Revisar el código

Durante la revisión chequear cada línea del código fuente para encontrar y  corregir tantos defectos como sea posible.

2. Corregir defectos Corregir todos los defectos encontrados.

Comprobar las correcciones

Anotar los defectos en el Cuaderno de Registro de Defectos

3. Revisión de ámbito Verificar que el diseño satisface todas las funciones descritas en la especi­

ficación.

Verificar que el código fuente implementa todo el diseño.

4. Revisar la lógica del programa Verificar que el diseño lógico es correcto

Verificar que el programa implementa correctamente el diseño lógico.

5. Comprobar los nombres y los tipos Verificar que todos los nombres y los tipos son correctamente declarados  y utilizados.

Chequear la correcta declaración de los tipos de datos integer, long inte­

ger y float.

6. Comprobar todas las variables Asegurarse que toda variable está inicializada chequear los problemas de  desbordamiento, underflow y fuera de rango.

7. Comprobar la sintaxis Verificar que el código fuente cumple todas las especificaciones del len­

guaje.

Criterios de salida:

✗ Código fuente terminado y corregido. ✗ Cuaderno de Registro de Tiempos completo.

✗ Cuaderno de Registro de Defectos completo.

13.6 Revisar antes de compilar.

Las razones de efectuar la revisión antes de la compilación son:

1. El tiempo empleado es el mismo que si se hace después de compilar.

2. Supone un ahorro en tiempo de compilación.

3. Tras la compilación la revisión de código no suele ser completa.

4. La compilación es tan efectiva antes o después de la revisión de código

5. Cuando un programa tiene muchos defectos durante la compilación, generalmente tiene muchos defectos en las  pruebas.

13.7 Otras clases de revisiones

Es común la denominada revisión en pareja o inspecciones, esto es ingenieros que revisan programas unos a otros. Esta  técnica normalmente encuentra del 50 al 70% de los defectos de un programa. Aunque suponen mucho tiempo de dedicación  su efectividad se basa en que es más fácil encontrar un error en un diseño o implementación ajena a un error en una que es  propia.

14. Listas de comprobación para la revisión de código

14.1. ¿Por qué ayudan las listas de comprobación?

Una lista de comprobación contiene una serie de pasos de procedimiento que se siguen de forma precisa. Cuando es  esencial encontrar y corregir cada defecto en un programa se debe seguir un procedimiento preciso. Una lista de comproba­

ción tiene el siguiente formato:

Propósito Guía para realizar una revisión de código efectiva # # # # Hasta

la fecha % Hasta la fecha . . . . . .

Includes Verificar que los “includes” est n completos.á . . . . . .

14.2. La lista de comprobación para la revisión de código

Se deben leer y hacer sucesivamente las acciones prescritas tal y como están establecidas en la lista de comprobación. 

Cada acción completada se marca en la lista. Al final se comprueba que todas las comprobaciones hayan sido realizadas, y si  no es el caso se vuelve atrás para realizar las acciones omitidas.

Al utilizar una lista de comprobación, pueden ser útiles las siguientes prácticas:

1. Revisar todo el programa para cada apartado de la lista de comprobación.

2. Cuando se encuentra un defecto, se anota con una marca en la primera columna libre (#). Cada columna # se usa  para cada revisión completa.

3. Después de completar cada comprobación, si no se han encontrado defectos, se escribe × en la primera casilla no  utilizada de la columna #.

4. Hacer un examen final global de todo el programa para buscar lo inesperado, nuevas clases de problemas, etc.

14.3. Elaboración de una lista de comprobación personal

La lista de comprobación debe estar personalizada para el lenguaje usado y para los defectos que cada ingeniero en par­

ticular encuentra y/o omite. Recomendaciones:

1. Hacer una lista clasificada con los defectos en cada fase del proceso software.

2. Clasificar los tipos de defectos en orden descendente del número de defectos encontrados en las fases de compila­

ción y pruebas.

3. Para los tipos con el más defectos, examinar el Cuaderno de Registro de Defectos y averiguar los errores específi­

cos que causan estos tipos.

4. Para los defectos que resultan de los problemas más importantes, idear los pasos necesarios en la revisión de códi­

go para encontrarlos.

5. Registrar las comprobaciones ideadas en la lista de comprobación.

6. Agrupar las pruebas parecidas en la lista de comprobación.

7. Después de desarrollar cada programa, examinar los datos de defectos y la lista de comprobación para identificar  los cambios o adiciones útiles.

14.4. Mejora de la lista de comprobación

Se deben de revisar con frecuencia los datos de defectos y volver a examinar la lista de comprobación. Cuando algún  paso no sea adecuado, idear cómo hacer el paso más efectivo y actualizar la lista de comprobación. Al terminar el programa  se rellena la columna Hasta la fecha a partir del de la lista de comprobación del programa anterior. Después se cumplimenta  la columna % Hasta la fecha. Durante la fase postmortem se debe comparar la lista de comprobación con el cuaderno de re­

gistro de defectos para ver cómo mejorar la lista de comprobación para perfeccionar el hallazgo de defectos. También se  debe considerar descartar los pasos de la revisión que no han encontrado defectos en los programas recientes. Es importante  reducir periódicamente la lista de comprobación ya que ésta tiene tendencia a crecer con el tiempo.

14.5. Estándares de codificación

Las listas de comprobación proporcionan un estándar frente al cual se pueden revisar los programas. Un estándar de co­

dificación define un conjunto de prácticas de codificación aceptadas, las cuales pueden servir como un modelo para el traba­

jo. Este estándar sirve como guía cuando se escribe código fuente. Los estándares de codificación también pueden ser útiles  para prevenir defectos. 

15.La previsión de defectos

15.1 U tilización de los datos de defectos.

La disciplina personal, asociada con la revisión de defectos y su análisis, es mucho más efectiva que los años de expe­

riencia para la reducción del número de defectos introducidos. Reunir los datos de defectos permiten comprender los defec­

tos introducidos, diseñar una lista de comprobación personal para la revisión de código y también para estimar el número de  defectos que se introduciran en un nuevo programa. Las estimaciones exactas del grado de defectos son importantes ya que  pueden fundamentar la necesidad de una nueva revisión del código.

15.2 Densidad de defectos.

La unidad de medida de defectos es defectos por miles de líneas de código, es lo que se denomina densidad de defectos  (Dd) y se mide en defectos/KLOC. El cálculo se realiza de la siguiente manera:

1. Sumar el total de número de defectos (D) encontrados en todas las fases del proceso.

2. Contar el número (N) de líneas de código nuevas o cambiadas en un programa.

3. Calcular la densidad de defectos por KLOC como Dd=1000*D/N.

15.3 Estimación de defectos.

La estimación de defectos suele ser problemática, en un principio los problemas de programación son nuevos, con la ex­

periencia se van superando, lo que supone una reducción en el número de defectos. También se debe de tener en cuenta que  el proceso personal no es estable, conforme se aprende a programar se varían los métodos y procedimientos, es decir, la  práctica de trabajo evoluciona produciendo fluctuaciones en el tiempo de las distintas tareas y en el número de defectos. Así,  revisando el número de defectos/KLOC introducidos y eliminados en los últimos programas, se puede estimar con precisión  el número de defectos que se introducirán en el futuro.

Al planificar un nuevo programa, se estiman primero el número de LOC nuevas y cambiadas, que probablemente tendrá  el programa. A continuación se calcula el valor medio de los defectos(KLOC de los programas desarrollados con anteriori­

dad. Con esto se puede calcular el número de defectos/KLOC esperados para el nuevo programa.

Ddplan= 1000(D1+...+Di)/(N1+...+Ni)

Como normalmente el nuevo programa tendrá la misma densidad de defectos:

Dplan= Nplan*Ddplan/1000

Este cálculo se puede realizar con “Tamaño hasta la fecha” y los datos de defectos en el Resumen del Plan del Proyecto:

Dplan=Nplan*DHasta la fecha/Nhasta la fecha

Con el número total de defectos esperados para el nuevo programa, se puede calcular el número de defectos esperados  para cada fase. Para ello se multiplica el número total de defectos esperados por el valor “%hasta la fecha” para cada fase y  se divide por 100.