Análisis y Gestión del Desarrollo del Software -...

Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)

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 proporciona un marco de trabajo estructurado para desarrollar las habilidades personales y los métodos necesarios para un ingeniero 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 pasos necesarios en el proceso de mejora son:

J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 1

Definir el objetivode la calidad

Medir la calidaddel producto

Comprenderel proceso

Ajustarel proceso

Utilizar elproceso ajustado

Medirlos resultados

Comparar los resultadoscon 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.

página 2 J.M. Godoy, F. Gómez y E. Rubio. 20032004


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 FinTiempo de

interrupción∆ de

tiempoActividad 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 interrupció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 período hace referencia a la forma de planificar la utilización del tiempo durante ese período. La segunda clase de plan está basada en la actividad (programar, escribir informes, ...). Se les denomina planes de producto. Los productos pueden ser tangibles 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 produzcan productos. La ingeniería desarrolla productos y los envía a fabricación, y son entregados al cliente por el grupo de marketing.

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 ingeniería y fabricación. La gestión corporativa decide qué dividendos o intereses se pagará a los inversores y las nuevas inversiones. 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 deproductos

Precios yPrevisiones

Productos

Tareas basadas en el periodo

Inversores

Inversiones

Dividendos / Intereses

Fondos Planesdel 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 Semanal 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 estimar los tiempos máximos para tareas complicadas, y los mínimos para otras más sencillas. Estos datos son útiles para planificar 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 trabajo 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

13/11 Codif. 100 1 158 1 158 158 1 158 158 158

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

23/11 Leer 50 2 80 2 40 80 2 40 40 40

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

34/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 trabajo 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 proceso 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 similares. 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 coherente 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 pantallas. 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 dedesarrollo

LOC Minutos/LOC Funciones

4 93 10 9.30 Bucle WHILE 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 desarrollados previamente. Como solución se puede adoptar un formulario que contenga varios programas o funciones y procedimientos 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 programa, 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 WHILE sencillo

5 14 WHILE grande WHILE 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 semanalmente. 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 Minutosestimados

Minutosreales

Codificar 360

Leer libros 180

Resumir 150

Preparar ex menesá 120

Otros 30

Total 840

Se debe de reequilibrar gradualmente la forma de utilizar el tiempo, ya que es impensable dedicar más tiempo a una tarea 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 UNED 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 trabajo 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 intentar 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?

HorasFecha de

inicioSe 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: _________________

IDtarea

Nombre 39Nov.

1016Nov.

1723Nov.

2430Nov.

17Des.

814Des.

1521Des.

2228Des.

294Des.

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: __02122003____

IDtarea

Nombre 39Nov.

1016Nov.

1723Nov.

2430Nov.

17Des.

814Des.

1521Des.

2228Des.

294Des.

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 ID1 ha sido completada; la ID3, casi; y la ID4, un poco menos. Además, un punto de control (ID2) 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 realmente 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 actual, 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 exactitud 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 & cambiadoTamaño máximo

Tamaño mínimoTiempo por Fase (min)

PlanificaciónDiseñoCodificación

Plan Real Hasta la fecha % Hasta la fecha

Revisión del códigoCompilaciónPruebasPostmortem

TotalTiempo máximo

Defectos introducidosPlanificaciónDiseñoCodificación


Revisión del códigoCompilaciónPruebas

Total

Def/HoraTiempo mínimo

Defectos eliminadosPlanificaciónDiseñoCodificación


Revisión del códigoCompilaciónPruebas

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 columna 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 desarrollar el programa.

Tiempo por fase total = Total Nuevo & Cambiado × Minutos / LOCTiempo por fase máximo = Tamaño máximo × Minutos / LOCTiempo 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 datos 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 acabados. 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 desarrollar un programa de calidad.

Aunque las funciones del software son muy importantes para los usuarios, no serían útiles al menos que el software funcione, por ello el primer aspecto de la calidad está relacionado con los defectos software. La primera prioridad del desarrollador 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 introducen 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 defectos 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 Resumen 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 casilla.

✗ 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 Utilizació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 defectos 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 Fecha.


Tipos de defectos10 Documentación 40 Asignación 70 Datos20 Sintaxis 50 Interfaz 80 Función30 Contrucción de paquetes 60 Chequeo 90 Sistema

100 Entorno

Nombre Fecha Programa #

Fecha Número Defecto CorregidoTiempo de correcciónEliminadoTipo Introducido





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 verifican 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 programa.

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 integración. Se realizan varios niveles de pruebas de componentes antes de combinarlos en productos y realizar las correspondientes 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 software.



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 especificació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 integer 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 lenguaje.

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ódigo5. 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 comprobación tiene el siguiente formato:

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

% Hastala fecha

. . . . . .

Includes Verificar que los “includes” estn 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 particular 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 registro 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 codificación define un conjunto de prácticas de codificación aceptadas, las cuales pueden servir como un modelo para el trabajo. 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 Utilizació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 experiencia para la reducción del número de defectos introducidos. Reunir los datos de defectos permiten comprender los defectos 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 experiencia 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 anterioridad. 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.



16. La economía de eliminar defectos

16.1. La necesidad del trabajo de calidad

El proceso de integración y pruebas está orientado a encontrar y eliminar los defectos. Cuando el producto final se entrega, a menudo su calidad es tan escasa que los ingenieros deben dedicar meses a corregir los defectos que encuentran los clientes. Un principio del trabajo de calidad, es obtener el producto correcto a la primera.

16.2. El problema de eliminar defectos

Conforme se hacen sistemas software más grandes y complejos, el problema de eliminar defectos se agravará.El rendimiento en la eliminación de defectos mide la tasa de los defectos encontrados con un método de eliminación.

16.3. Cálculo de los Defectos/Hora en el resumen del Plan del Proyecto

Defectos /Horaintroducidos Hasta la Fecha en una fase=defectosintroducidos Hasta la Fecha enla faseminutos dedicados Hastala Fechaen la fase

×60

Defectos /Hora eliminados Hasta la Fecha en una fase=defectos eliminados Hasta la Fecha en la faseminutos dedicados Hasta la Fecha enla fase

×60

16.4. Cálculo del Rendimiento en el resumen del Plan del Proyecto

Cuando se eliminan defectos en una fase interesa saber cuántos se encontraron y cuántos quedaron ocultos. Aunque no es posible saberlo durante el desarrollo, los datos de procesos históricos pueden ayudar a hacerse una idea. En PSP se define el rendimiento del proceso como la tasa de defectos encontrados antes de la primera compilación y las pruebas.

RendimientoPlan=Plan de defectos eliminados antes de compilarPlande defectos introducidosantes de compilar

×100

RendimientoReal=Defectos eliminadosreales antes de compilar

Defectos introducidosreales antes decompilar×100

RendimientoHasta la Fecha=Defectos eliminados Hasta la Fecha antes de compilar

Defectos introducidosHasta la Fecha antes de compilar×100

16.5. Mejora de las tasas de eliminación de defectos

Sugerencias para mejorar la tasa de eliminación de defectos:✔ Fijarse primero en el rendimiento: el objetivo inicial es conseguir un rendimiento del 70% o superior.✔ Hacer una revisión de código antes de la primera compilación.✔ Controlar en la lista de comprobación dónde se encuentran y se pasan por alto defectos. Hacer ajustes periódica

mente.

16.6. Reducción de las tasas de introducción de defectos

✔ Registrar todos los defectos. Se aprende de ellos, si se conocen.✔ Hacer mejores diseños. Más completos y más documentados.✔ Utilizar los mejores métodos. Mejoran la forma de desarrollar los requisitos, especificaciones, diseños, casos de

prueba y código fuente.✔ Utilizar herramientas software mejores. Reducirán el número de defectos que se introducen.



17. Defectos de diseño

17.1. La naturaleza de los defectos de diseño

La mayoría de los defectos son introducidos durante la fase de codificación, aunque una parte de ellos son defectos del tipo diseño. Esto significa que una buena manera de reducir el número de defectos introducidos será dejar de hacer el diseño durante la codificación.

17.2. Identificación de los defectos de diseño

Los mejores compiladores no encuentran todos los defectos sintácticos, y algunos errores de diseño también podrían producir una sintaxis incorrecta. Esto es debido a que algunos errores de sintaxis producen código que tiene validez sintáctica para el compilador.

Para definir los errores de diseño se puede seguir dos opciones:

✔ Definir todos aquellos defectos introducidos en la fase de diseño como defectos de diseño.✔ Definir aquellos tipos de defectos que implican cuestiones de funciones de codificación, lógica, rendimiento y sin

cronización como defectos de diseño.

17.3. El proceso de diseño

La noción de abstracción es muy útil cuando se trata con funciones conocidas y definidas. Si la abstracción a utilizar no es lo suficientemente conocida se debe estudiar a fondo antes de proseguir en el diseño.

La distinción entre diseño y codificación es arbitraria. Esto también significa que la especificación de qué constituye un diseño completo es arbitraria. Por lo tanto, es importante distinguir entre el proceso de diseño y la fase de diseño específico en el PSP. La fase de diseño comienza cuando se realiza el producto llamado diseño.

17.4. Las causas de los defectos de diseño

✔ Un diseño erróneo. Decisión equivocada.✔ Un simple error. Descuido o error tonto.✔ Mala comprensión de lo que se quiere. La función pretendida está correctamente diseñada, pero no responde a lo

que se espera de ella.✔ Incomprensión contextual del sistema. Se entiende el diseño local y el del sistema, pero no se entiende el contexto

del sistema.

17.5. El impacto de los defectos de diseño

Un diseño pobremente representado lleva a que se introduzcan defectos durante la codificación, ya que el programador no podrá ver lo que se pretende y puede que él mismo complete precipitadamente sobre la marcha el diseño.

17.6. Representación del diseño

La representación completa del diseño cuando se crea, probablemente ahorra tiempo. Esto es debido a que se puede producir mucho más rápidamente si se tiene un diseño completo y claro.

17.6.1. Representaciones gráficas del diseñoLa forma más común es el diagrama de flujo: un diagrama con las funciones del programa representadas por cajas y la

lógica del programa fluye representada por líneas que unen las cajas:


Interconexiones

Cálculo Decisión

Funciónpredefinida

Funcióndefinida


17.6.2. Representaciones del diseño con pseudocódigoEl pseudocódigo proporciona otra forma de representar la lógica del programa: se escribe el programa en un lenguaje

más fácil de comprender para las expresiones complejas.Una descripción de diseño con pseudocódigo es una mezcla de lenguaje humano y elementos de codificación. En vez de

utilizar una lógica completa para definir bien las funciones, se utilizan sentencias sencillas.La principal ventaja del pseudocódigo es que es tan preciso como se necesite y es fácil de entender. Su principal desven

taja es que, un diseño en pseudocódigo puede ser tan detallado que sea difícil de entender. Por eso, es una buena idea proporcionar tanto el pseudocódigo como un diagrama de flujo para cualquier diseño por muy sencillo que sea.

17.6.3. Otros métodos de representaciónLos métodos matemáticos formales tienen la ventaja de ser precisos y la desventaja de ser muy difíciles de aprender.En cualquier caso, se deben tener en cuenta los siguientes puntos:

✔ Diseñar es un proceso mental.✔ Una notación de diseño rica, puede ayudar a pensar con precisión y a representar un diseño complejo.✔ Las notaciones ricas, sin embargo, son difíciles de aprender.✔ Utilizar notaciones familiares, para evitar “traducciones” mentales que provocarán retrasos, inseguridad y errores.



18. Calidad del producto

18.1. Las pruebas

Cuanto más complejo es el producto, las pruebas consumen más tiempo y son más caras. Las pruebas, en estos casos, también son menos efectivas para encontrar los defectos. Razones:

✔ Los defectos pueden enmascarar otros defectos, sobre todo en programas grandes con muchas interacciones.✔ Es poco práctico probar todos los caminos lógicos, incluso para programas medianos.

Por lo tanto, es más adecuado seguir un procedimiento sistemático que minimice la posibilidad de introducir defectos, y no dejar para la fase de pruebas su detección y corrección.

18.2. El filtro de las pruebas

Cada revisión, compilación o prueba elimina un cierto porcentaje de defectos, actuando como un filtro. Esto también significa que cada proceso de eliminación de defectos pasa por alto una fracción de ellos.

Dentro de los métodos de detección de errores los que tienen mayor rendimiento son la revisión de código (70%80%) y la inspección de código (50%70%). Ambos son métodos manuales. Otros, todos ellos automatizados, como la compilación y los diferentes tipos de pruebas, muestran un rendimiento menor.

Por lo tanto, es conveniente que un producto software tenga el menor número de defectos posible al comenzar las pruebas. Todo esto implica que, para conseguir un producto de máxima calidad, los defectos se deben eliminar antes de comenzar a compilar

18.3. El cálculo de los valores de rendimiento

El rendimiento en cualquier fase se puede calcular de la siguiente manera:

Rendimiento fase=Número de defectos eliminadosdurante la fase

Númerode defectos en el producto al inicio de la fase×100

18.4. La estimación del rendimiento definitivo

Aunque nunca se puede saber con certeza el rendimiento cuando se acaba una fase, la medida de rendimiento ayudará a evaluar y mejorar el proceso.

La única forma de determinar cuántos defectos quedan, es controlar los que se van encontrando en el producto durante el resto de su vida útil.

Una regla de utilidad empírica es asumir que los defectos que quedan en un producto equivalen al número de los mismos encontrados en la última fase de eliminación. Esto equivale a asumir que el rendimiento de esta última fase fue del 50%.

18.5. Prototipado

Una vez que se ha alcanzado de forma consistente un rendimiento del 70%, continuar mejorando será más difícil. La mayor parte de los defectos pasados tendrán que ver con el diseño.

Para eliminar todos los defectos se deben escribir prototipos de programas pequeños y de nuevas funciones. Estos prototipos permitirán probarlos antes de incorporarlos al programa.



19. La calidad del proceso

19.1. Las medidas de la calidad

La medida fundamental de un proceso tiene que ver con el volumen de productos realizados, su calidad, el tiempo y los recursos requeridos para hacer el trabajo.

Las tasas de eliminación de defectos disminuyen conforme mejora la calidad del producto. Con pocos defectos, llevará mucho tiempo encontrarlos, con independencia del método utilizado, sobre todo en revisión y pruebas. Sin embargo no es así en compilación debido a la naturaleza automática de los compiladores.

Los defectos en los grandes sistemas están en los módulos que lo constituyen. Estos defectos se pueden dividir en dos clases: aquellos que implican solamente un módulo y los que implican interacciones entre módulos. Aplicando con alto rendimiento PSP se eliminan casi todos los defectos de la primera clase. La segunda clase es más complicada. Una buena estrategia es:

✔ Desarrollo de módulos con la máxima calidad posible.✔ Inspeccionar todas las interfaces de módulos y sus interacciones.✔ Inspeccionar los requisitos y asegurarse que todas las funciones importantes son adecuadamente entendidas, dise

ñadas e implementadas.✔ Inspeccionar el sistema y el diseño del programa frente a los requisitos para asegurarse de que se tratan correcta

mente.✔ Hacer pruebas de unidad exhaustivas tras inspeccionar el código.✔ Hacer una prueba de integración total.✔ Hacer pruebas a todo el sistema.

19.2. El coste de la calidad

El Coste de la Calidad (CDC) tiene tres elementos principales:

✔ Coste de los fallos. Incluye todos los costes de corregir los defectos del producto. Cualquier actividad realizada como una parte normal de la reparación de un defecto.

✔ Coste de valoración. Todo trabajo de valoración del producto para ver si tiene defectos, excluyendo el tiempo dedicado a la corrección de defectos. Incluye la revisión de código, el tiempo de compilación y las pruebas. Se puede considerar como la tasa pagada para asegurar que el programa está libre de defectos.

✔ Coste de prevención. El que se incurre al modificar el proceso para evitar introducir defectos. Incluye el análisis para comprender los defectos, trabajo para mejorar los procesos de especificación de requisitos, diseño e implementación; trabajo de rediseño y pruebas de un nuevo proceso. También se incluye el prototipado.

La forma como el PSP mide el CDC es la siguiente:

✔ La valoración CDC es la suma de todo el tiempo de revisión como un porcentaje del tiempo real de desarrollo.✔ Los fallos CDC son la suma de todo el tiempo de compilación y pruebas como un porcentaje del tiempo total de

desarrollo.

19.3. La relación Valoración/Fallos

La relación Valoración/Fallos ó V/F se calcula dividiendo la valoración CDC por los fallos CDC. También se puede calcular como el tiempo de la revisión de código dividido por el total del tiempo de compilación y pruebas.

V/F mide la cantidad relativa de tiempo dedicada a encontrar defectos antes de la primera compilación, siendo un buen indicador de la probabilidad de encontrar defectos en las pruebas.

Cuando V/F < 1, las pruebas generalmente encuentran muchos defectos; sin embargo cuando V/F > 2, los procesos tienen pocos Defectos/KLOC en la pruebas. La deducción es que para reducir los defectos en las pruebas, se deben de eliminar antes de la compilación.

Para lograr valores V/F por encima de 2 se debe revisar el histórico de compilaciones, el tiempo de pruebas y planificar el doble de tiempo (como mínimo) para la siguiente revisión de código.

Cuando se encuentren la mayor parte de los defectos en la revisión de código, se deben mejorar las tasas de revisión. Para ello se debe identificar cualquier paso de la revisión que ni encuentra ni pase por alto defectos y reconsiderar su inclusión o combinación para conseguir mayor rapidez.



19.4. Cálculo del verdadero coste de calidad

Para calcular los verdaderos costes de fallos y valoración, se deben dividir los tiempos de revisión, compilación y pruebas entre los componentes respectivos de valoración y fallos.

Así, si se llama CV al tiempo de compilación en el que no se encuentran fallos, y CF al tiempo de corrección de defectos durante la compilación, se tiene que el Tiempo de Compilación, C, será:

C=CVCF

De igual forma para las fases de Revisión, R, y Pruebas, P, se tendrá:

R=RVRF

P=PVPF

Utilizando estos parámetros se aumenta la precisión de la valoración y fallos CDC:

ValoraciónCDC=CVRVPV

tiempo total de desarrollo×100

FallosCDC=CFR FPF

tiempo total de desarrollo×100



20. Trabajo en equipo y sus técnicas

20.1. Las funciones de los equipos

✔ Rapidez de respuesta a las necesidades del cliente.✔ Generación de nuevas ideas y soluciones.✔ Mejora de los procesos.✔ Implantación de decisiones complejas.✔ Realización de tareas complejas o interdependientes.✔ Funciones de coordinación.

20.2. Proceso de compromiso

El proceso de compromiso está implícito en una buena gestión de requisitos, adecuada planificación de proyectos, correcto seguimiento y control de proyectos y cualquier otro proceso que requiera trabajo en equipo. En el proceso de compromiso se debe de tener en cuenta tanto los aspectos técnicos como los aspectos del negocio. El proceso de compromiso se asienta en los siguientes principios:

✔ Actitud personal de compromiso totalmente asumida.✔ Cultura de equipo/organización para poder aceptar y cumplir los compromisos, sean grandes o pequeños.

El proceso de compromiso software necesita un plan de proyecto documentado que contenga una estimación de recursos, esfuerzo y coste, y un calendario basado en estas estimaciones. El plan debe establecer que los recursos están disponibles y que las condiciones técnicas del negocio supongan un riesgo razonable.

20.3. El trabajo en equipo

El fracaso de los proyectos software generalmente es debido a problemas de trabajo en equipo. El origen de la presión suele ser el cumplimiento de un calendario apretado. Sin embargo el origen real de la presión es uno mismo. Una estrategia y un proceso de planificación enseña a los equipos como tratar la presión. Los equipos analizan el trabajo, idean una estrategia para realizarlo, estiman el tamaño de los productos que obtendrán, y luego hacen el plan.

20.3.1 El consenso y sus característicasEl consenso es probablemente la mejor manera de tomar decisiones dentro de un equipo de trabajo. El consenso es:

✔ Encontrar una propuesta que todos los miembros del equipo puedan apoyar o con la que puedan convivir.✔ La ausencia de disidencias minoritarias: ningún miembro del equipo mantiene una oposición frontal a la propues

ta.

En cambio, no hay consenso cuando:

✔ Se busca el voto unánime.✔ Se utiliza un voto mayoritaria en el que la mayoría gana y la minoría pierde.✔ Se busca la total satisfacción de todo el mundo.

En términos generales, las características de un buen consenso son:

✔ Requerir tiempo para conseguirlo.✔ Requerir la participación activa de todos los miembros.✔ Requerir ciertas habilidades de comunicación: escuchar, resolver conflictos, facilitar la discusión.✔ Requerir un pensamiento creativo y mentes abiertas.

20.3.2 Grupo Equipo

Hay tres condiciones básicas para que un grupo funcione satisfactoriamente:

✔ Tareas claras y delimitadas.✔ Cada miembro conoce a los demás miembros del equipo y conoce su trabajo y el papel que representa.✔ El equipo sabe cuál es su trabajo y responsabilidad y en que términos está planteado.

Los equipos son más eficaces cuando se desarrollan fuertes relaciones entre todos sus miembros. Esto es más verosímil cuando los equipos son pequeños, de 4 a 8 ingenieros.

20.3.3 Propiedades de un equipo eficazAl equipo se le deben proporcionar las siguientes cuatro propiedades:

✔ Cohesión. Tanto física como emocionalmente.



✔ Metas desafiantes. Metas específicas y mensurables, pero también han de suponer un reto significativo.✔ Realimentación. Se evidencian tanto los resultados del equipo como las aportaciones individuales dentro del equi

po.✔ Marco común de trabajo. Percepción clara del qué, cómo, cuándo y por qué, en el ámbito del equipo.

20.3.4 Consolidación de equiposLa consolidación del equipo se produce cuando los miembros llegan a aceptar un conjunto común de metas:

✔ Metas. Es conveniente que todos los miembros participen en su decisión.✔ Roles. + Líder del equipo + Responsable de la calidad y del proceso

+ Responsable de desarrollo + Responsable del soporte+ Responsable de planificación

✔ Planes. División de la labor total en ciclos de desarrollo. Posteriormente se define el contenido funcional de cada ciclo, su tamaño esperado, y los modos de integrar y probar estas partes para obtener un producto acabado.Con el proceso definido, el quipo entonces estima los tamaños de los productos de cada ciclo, el tiempo necesario para realizar cada producto, el orden de este trabajo, y las personas que intervendrán en cada etapa.

Para hacer frente a la comunicación interna del equipo se establecen reuniones semanales. Es muy importante que los miembros del equipo conozcan el estado del trabajo de los otros.

La comunicación externa se refiere a la que tiene lugar con otros grupos, como la dirección. Esta comunicación no debería limitarse a exponer los problemas que surgen durante el proceso. Es mucho mejor que el líder del equipo tramita a la dirección un informe semanal de situación.

20.3.5 Modelo de crecimiento de un equipoCinco etapas: Formación, Conmoción, Normalización, Actuación y Terminación. (FCNAT)Cuatro elementos para explicar cada etapa: CR: Comportamiento en la Relación

CT Comportamiento en las TareasRR: Resultado en la RelaciónRT :Resultado en las Tareas

FormaciónSe presentan los roles y las tareas del resto del equipo.

CONCIENCIACIÓN

CR → DependenciaCT → OrientaciónRR → AceptaciónRT → Compromiso

ConmociónSe clarifican roles y responsabilidades. CONFLICTO

CR → HostilidadCT → ResistenciaRR → PertenenciaRT → Clarificación

NormalizaciónTodo el trabajo se realiza conjuntamente. Sobresale la identidad del grupo.

COOPERACIÓN

CR → CohesiónCT → ComunicaciónRR → ApoyoRT → Involucración

ActuaciónSe consigue una alta productividad y creatividad. PRODUCTIVIDAD

CR → InterdependenciaCT → ResoluciónRR → OrgulloRT → Logros

TerminaciónEl equipo después de finalizar su trabajo se deshace. SEPARACIÓN

CR → DesconexiónCT → FinalRR → SatisfacciónRT → Reconocimiento



20.3.6 Atributos del equipo

✔ Claridad en los objetivos.✔ Roles claramente definidos.✔ Trato agradable en el equipo✔ Concienciación del proceso del grupo✔ Participación equilibrada

✔ Plan de mejora continua.✔ Comunicación clara.✔ Procedimientos de decisión bien definidos✔ Reglas básicas establecidas✔ Utilización del método científico

20.3.8 Problemas habituales en los equipos

✔ Liderazgo ineficaz.✔ Participación desigual.✔ Calidad deficiente.✔ Deficiente valoración personal.

✔ Fracaso en la cooperación.✔ Falta de resolución y ausencia de confianza.✔ Ampliación de requisitos.

Otros problemas más específicos pueden ser:

✔ Vacilación.✔ Influencia excesiva.✔ Excesivo protagonismo.✔ Participación reticente.✔ Aceptación de opiniones como hechos.

✔ Impaciencia.✔ Imputaciones erróneas.✔ Subestima.✔ Divagaciones.✔ Enemistades personales.

20.4 Reuniones

20.4.1. Tipos de comportamientoEn toda reunión se producen tres tipos de comportamiento:

✔ Iniciación. Imponer las ideas: Proponiendo → se introduce una nueva idea o acción.Construyendo → acuerdo y ampliación sobre las ideas presentadas.

✔ Reacción. Evaluar las contribuciones de los demás: Apoyando → Acuerdo con el punto de vista del otro.Expresando desacuerdo → Objeciones a opinión del otro.Defendiendo atacando → A la persona no al asunto.

✔ Clarificación. Intercambiar informaciones y opiniones: Verificando la comprensiónBuscando informaciónDando informaciónResumiendo

20.4.2. Roles típicos en una reunión✔ Líder . Puede haber uno para toda la reunión o uno para cada uno de los puntos de la agenda. Características:

• Es la persona que dirige la reunión.• Convoca y modera la reunión cuando no hay moderador.• Organiza todas las actividades del equipo.• Supervisa la preparación de informes y presentaciones.• Se interesa por la resolución de problemas.• Será razonablemente bueno en el trabajo con individuos y grupos.• Es el responsable de la creación y mantenimiento de canales de comunicación que permitan a los miembros

del grupo hacer su trabajo.• Debe tomar precauciones para no dominar el grupo en las reuniones.

✔ Moderador . También puede asumirlo el líder.• Mantener la discusión dinámica y enfocada en el punto establecido.• Intervenir si la discusión se disgrega en discusiones múltiples.• Impedir con mucho tacto que alguien sea dominante o pase desapercibido.• Concluir las discusiones.

✔ Cronometrador, secretario y evaluador final . También puede asumirlo el líder.• Notificar y avisar al grupo cuando se acaba el tiempo asignado para un punto o está a punto de terminar.• Tomar nota de los temas principales y de los puntos claves que se trataron.• Anotar las decisiones tomadas, incluyendo quién se comprometió a hacer qué cosa y para cuándo.• Tomar nota de los puntos que se acuerda discutir más adelante en la misma reunión o en una futura.• Anotar qué fue bien y qué fue mal, para mejorar la próxima reunión.



20.4.3. Reglas para reuniones provechosas✔ Fijar una agenda. Cada reunión debe tener una agenda fijada. Las agendas deberán incluir la siguiente informa

ción:• Los puntos de la agenda.• Las personas que van a presentar los puntos.• Un límite de tiempo.• El tipo de punto y si se requiere alguna discusión o una decisión, o si es tan solo informativo.

En las agendas se incluirán generalmente las siguientes actividades:• Ambientaciones o actividades cortas (510 minutos) usadas para despejar la mente de los participantes de los

eventos del mundo exterior y para enfocarlos en la reunión.• Revisión rápida de la agenda. Corrigiendo y/o asignando puntos.• Recesos durante reuniones largas. Para reuniones de al menos dos horas se necesita un receso.• Evaluación de la reunión.

✔ Disponer de un moderador y cronometrador✔ Realizar actas✔ Redactar la próxima agenda✔ Regla de los 100 kilómetros

20.4.4. Técnicas de decisiónEl principal objetivo de una reunión es la toma de decisiones.Técnicas de decisión ante una reunión donde se presenten dificultades para alcanzar el consenso:✔ Brainstorming. Lluvia de ideas.✔ Votación múltiple. Se votan varias opciones a la vez otorgando más puntos cuanto mejor se cree que es la opción.✔ Grupos nominales. Se exponen las ideas de cada miembro y se escriben en la pizarra. Después, se votan las dife

rentes opciones usando la votación múltiple.✔ Matriz de la función de calidad (QFD). Permite establecer un diagrama conceptual del problema a discutir y pro

porciona los medios para la planificación y comunicación entre distintas áreas o departamentos.✔ Diagrama causaefecto. También se le llama diagrama Ishikawa o de espina de pez.

Todos los miembros van indicando en el diagrama las causas mayores de los efectos así como las subcausas de éstas, llegando hasta el detalle que se precise.



21 Factores humanos

21.1 Modelo del perfil de personalidad.

Un trabajo en equipo eficaz sólo se consigue con el esfuerzo combinado de todos sus miembros. Todos ellos deben participar, contribuir y considerar el trabajo en equipo como la parte más importante de sus respectivas labores. Un elemento clave es la comunicación entre los miembros del equipo, es importante conocer la personalidad individual.

Para definir el perfil de la personalidad de cada individuo se identifican cuatro aspectos diferentes a través de los cuales las personas se relacionan con el resto del mundo:

➢ ¿Dónde centra su atención?➢ ¿Cómo recopila la información?➢ ¿Cómo toma las decisiones?➢ ¿Cómo prefiere enfrentarse al mundo?

21.1.1 Preferencias personales.

El Myers Briggs Type Indicator (MBTI) es un instrumento de evaluación del perfil de personalidad. El análisis de las preferencias personales basados en MBTI son las siguientes:

¿Dónde centra su atención?Este aspecto está relacionado con la prioridad en la procedencia de los estímulos; es decir, si se considera más importan

te los estímulos internos o los externos.

Extroversión (E) Introversión (I)

Características Estímulos exteriores esenciales Estímulos esenciales internos

Puntos de interés El exterior, el mundo, la acción, el cambio

El interior, los pensamientos, ideas propias y la comprensión.

Peculiaridades Amigable, hablador. Expresa emociones, gregario

Reservado y callado. Personal y reflexivo. Oculta sus emociones y necesita privacidad.

Forma de manifestarse Actúa y después piensa. Motivado con otras personas

Piensa y después actúa (o no). Motivado por impulsos internos.

Actividad en el trabajo Respuesta rápida. Trabajo en equipo. Soluciona sobre la marcha y sin pulir

Respuesta meditada. Trabaja sólo. soluciones optimizadas y buscadas previamente.

Imagen que transmite Superficiales Reservados

¿Cómo recopila la información?Apartado relacionado con la forma en que el individuo busca y recopila información, bien a través de los sentidos o bien

por intuición.

Sentidos (S) Intuición (N)

Características Estudia las partes de la totalidad. realista, perspicaz y específica.

Estudia el ámbito global. Busca patrones y relaciones. Mira el futuro, es conceptual, teórico y generaliza.

Puntos de interés Los detalles con un enfoque en métodos pruebaerror

Patrones y tendencias, conceptos e ideas. Nuevo enfoque.

Peculiaridades Manejo de aspectos prácticos Imagina posibilidades

Forma de manifestarse Vive el presente Vive hacia el futuro. Anticipa

Actividad en el trabajo Paso a paso. Atento a los detalles pocos errores

Salta de un punto a otro. Añade nuevas posibilidades. Paciente con la complejidad. Mira la globalidad.

Imagen que transmite Materialistas y poco imaginativos Volubles, poco prácticos y soñadores.

¿Como toma las decisiones ?



En este aspecto puede prevalecer la lógica o las consideraciones objetivas o personales.

Pensando (P) Sintiendo (T)

Características Decisiones basadas en la lógica Decisiones en valores personales.

Puntos de interés La verdad y la justicia Relaciones y armonía

Peculiaridades Ve las cosas como un observador externo. Distante, punto de vista impersonal. Bueno para analizar planes.

Ve las cosas desde dentro. Aprecia las maneras espontáneas. Bueno para entenderse con la gente.

Forma de manifestarse Funciona con lógica Funciona por convicciones

Actividad en el trabajo Conciso y serio. Impersonal. Justo Amigable, personal. Trata a los demás según lo necesitan.

Imagen que transmite Fríos y distantes Dispersos y emocionales.

¿Cómo prefieren enfrentarse al mundo?Aspecto que refleja la manera de vivir. La gente con preferencia juzgando se considera organizada; los de preferencia de

percibir son abiertos a las cosas bajo distintas perspectivas.

Juzgando (J) Percibiendo (C)

Características Decisivo, resuelto, organizado, controlador.

Curioso, espontáneo descubre.

Puntos de interés Toma de decisiones. Concluir el trabajo y alcanzar la meta.

Mantener abiertas opciones. .

Peculiaridades Vida organizada. Planificando siempre Vida flexible. Las agendas les resultan dolorosas.

Forma de manifestarse Vida bajo control. Define orden y estructura.

Experimentan la vida.

Actividad en el trabajo Estructurado y ordenado. Resuelto y exacto. Toma decisiones fácilmente.

Estimulado por el momento. Adaptable y tolerante. Buen gestor en época de crisis.

Imagen que transmite Exigente, rígido y hermético. Desorganizado, desordenado e irresponsable.

Las diferentes combinaciones producen la siguiente tabla:

SP ST NT NP

IJ Responsable Leal Contemplativo Independiente

IC Pragmático Artístico Idealista Conceptual

EC Espontáneo Generoso Optimista Inventivo

EJ Inflexible Armonizador Persuasivo Dominante

21.2 Mecanismos de comunicación.

Las acciones no verbales que demuestran que se está escuchando, los gestos, posición del cuerpo y expresiones faciales. El lenguaje corporal es subjetivo y dependiente del contexto y cultura de los individuos. Para mejorar la comunicación no verbal se pueden utilizar las siguientes técnicas:

➢ Realizar una relajación física antes y durante la comunicación.➢ Establecer contacto visual. desempeña cuatro funciones de comunicación

✗ Regula el flujo de información señalando el principio y el final✗ Representa interés y atención✗ Transmite emociones.✗ Manifiesta el tipo de relación entre los que se comunican.

➢ Aproximarse a la persona que escucha.➢ Sonreír y mostrarse animado➢ Halar de manera relajada.

Algunas acciones que se deben evitar son:



✔ Hablar demasiado rápido o despacio.✔ Mirar a otra parte o desviar la mirada

Es uno de los elementos más importantes de las relaciones interpersonales en un equipo de trabajo. Hay dos posiciones claras: alegatos e indagaciones.

21.3 Comunicación interpersonal.

En la construcción de un equipo firme y consolidado, la comunicación es crítica; los tres elementos más importantes de la comunicación son: visibilidad, escucha y negociación.

Visibilidad:En los equipos consolidados, todos sus miembros estarán en contacto permanente, saben lo que están realizando, hay un

ambiente de entusiasmo y un sentido del progreso diario. Los equipos de gran rendimiento:

➢ Saben lo que está sucediendo en cada momento.➢ Pueden prever problemas y realizar rápidamente los cambios.➢ Saben cuando algunos necesitan ayuda➢ Pueden ver los efectos de su trabajo.

La escucha.Los mejores comunicadores, son los mejores escuchadores, tras escuchar (y comprender) se puede empezar la comuni

cación para solucionar problemas. Hay cinco niveles de escucha:

1. Ignorando2. Aparentando3. Escucha selectiva4. Escucha atenta (centrándose en las palabras).5. Escucha empática (con intención de entender).

La negociaciónUna gran proporción de todas las interacciones humanas se relacionan con las negociaciones.

21.4 El problema del cambio.

El cambio es un proceso donde se transita entre diferentes estados, muchas veces aparecen resultados inesperados. La dinámica de los acontecimientos del cambio debe ser gestionada como si fuera una parte muy importante del propio negocio. El cambio se convierte en un motor generador de oportunidades y de debilidades.

21.5 Actitudes básicas frente al cambio.

La respuesta ante el cambio debe ser positiva en tres aspectos: intelectual, emocional y funcional. Es necesario analizar y pensar razonablemente la manera más adecuada para realizar el cambio.

En un modelo de cambio simple se producen tres estados básicos:

1. Estado actual: status quo.2. Estado transitorio: Estado interino caracterizado por la confusión, pérdida de productividad, incertidumbre del

éxito y alta resistencia al cambio.3. Estado final deseado.

Para comenzar el proceso del cambio aparecen de forma general dos procesos:

➢ Descongelación: mover la organización desde el estatus quo al estado de transición.


Persuasión Aserto: Esto es lo que pienso y mis motivosExplicación: Me baso en estoImposición: Esto es lo que hay (Inadecuado)

Generación Discusión: Equilibrio entre defensa, indagación y argumentación.

Sin acusaciones personalesDemagogia: Fingir equilibrio u no escuchar (Inadecuado)

Ovservación Mera presencia: Formas pero sin contenidoTanteo: Observación sin hablarAusencia: Falta de atención (Inadecuado)

Inquisición Encuesta: Exploración de perspectivasClarificación: ¿Qué intentamos resolver?Interrogar: ¿Porqué no admite equivocaciones? (Inadecuado)

Indagación

Alegato


✔ Facilitando una atmósfera en la que sea más difícil permanecer que moverse hacia adelante.✔ Facilitando el liderazgo en la dirección elegida.

➢ Congelación o procesos de consolidación de los cambios.✔ Guiar a la organización hacia el objetivo.✔ Poner en funcionamiento mecanismos que ayuden a institucionalizar el movimiento de la organización hacia

el estado deseado.✔ Implementando totalmente el plan de acción previsto.

21.6 Requisitos para gestionar el cambio.

Visión Habilidades Incentivos Recursos Plan de acción Resultado

× × × × × Cambio

× × × × Confusión

× × × × Ansiedad

× × × × Cambio gradual

× × × × Frustración

× × × × Salidas en falso

Las necesidades de las personas durante la transición son:➢ Información sobre todo lo que va a pasar, cuándo, cómo y porqué. todas las personas deben ser incluidas en el

proceso de planificación.➢ El apoyo se concreta facilitando una comunicación bidireccional desde la dirección a todos los afectados y en sen

tido contrario para conocer y considerar las opiniones de todos. Se debe proporcionar seguridad en los aspectos fundamentales (puesto de trabajo, etc) y formación adecuada a las nuevas tareas a desarrollar.

➢ Se debe dar libertad para asumir riesgos sin que se produzcan acusaciones en el caso de fallo. Así mismo se debe recompensar bien de forma intangible o tangible.

21.7 Resistencia al cambio.

➢ Comunicación del cambio. Un cambio concebido y mal comunicado no es una realidad. Los lideres deben realizar comunicaciones escritas, reuniones de gestión y presentaciones.

➢ Recursos para el cambio: El trabajo en equipo facilita el cambio, así mismo se deben de asegurar los recursos adecuados en volumen y tiempo.

➢ Fallos de los planes del cambio: Los fallos más habituales son:✗ Falta de conexión entre los planes de estrategia, de negocio y del trabajo diario.✗ Complejidad del plan.✗ Falta de formación de los trabajadores✗ No comprender que las innovaciones se deben revisar y actualizar durante el proceso del cambio.

➢ Descuidos habituales en la preparación del cambio:✗ No tomar en consideración al usuario final.✗ Fallos en el trabajo en equipo y delegación de responsabilidades.✗ Falta de apoyo en todos los niveles✗ Falta de una definición clara de expectativas (costes, claridad).✗ Mala gestión de las quejas.

21.8 Barreras al cambio.

En un cambio hay que tener en cuenta todos los subsistemas que constituyen una organización:

En cada paso del cambio hay que realizar una serie de preguntas:¿Qué elementos de la organización se necesitan cambiar?.¿Cuál es el impacto deseado del cambio?


Sistema de la organización

Subsistema Estratégico

Subsistema Tecnológico

Subsistema Humano – Cultural

Subsistema Estructural

Subsistema de Gestión

Entradas:Recursos humanosTecnológicos Materiales

Salidas: Productos y Servicios

Flujo de E/S


➢ Sistemas tecnológico➢ Sistemas de gestión➢ Sistemas Estratégicos➢ Sistemas Sociales➢ Sistemas Ambientales

¿Quién es el responsable de hacer el cambio?¿Cuándo se supone que se debe completar el cambio?¿Cuál es el resultado esperado del cambio?¿Cómo se espera que se va a conseguir el cambio?¿Qué apoyo existe para el proceso del cambio?

Intentar resolver demasiados problemas al mismo tiempo puede ser imposible o destructivo. Habrá que enfocarse en problemas que tienen el mayor impacto en la organización si no se resuelven. Para que una organización este preparada para el cambio debe poseer los siguientes atributos:

➢ Historia de cambios: Experiencias anteriores, éxitos y fracasos.➢ Claridad de las expectativas: grado según el cual los resultados esperados tras el cambio son compartidos a dife

rentes niveles dentro de la organización. Especificar en detalle las suposiciones sobre el impacto del cambio, sobre todo del usuario final.

➢ Origen de la idea o del problema: grado en que los más afectados por el cambio sugieren el cambio o conocer el problema que se soluciona.

➢ Apoyo de la alta dirección

Nivel estratégico

Director General, Presidente

Visión global para la compañía

Nivel de negocios

Directores y Mandos Intermedios

Puente entre la visión global y las actividades diarias

Operaciones

Jefes de Departamento y Mandos Intermedios

Se gestionan los plazos, desafíos, obligaciones y calendario.

✔ Compatibilidad con los objetivos de la organización: grado según el cual el cambio propuesto se corresponde con prácticas y planes de la organización ya sean pasados o presentes.

21.9 Roles para el cambio

Inventor: capaz de integrar tendencias e información en nuevos conceptos, modelos y planes, proponiendo un marco global que aglutine a todos ellos.

Emprendedor: Se concentran en la eficiencia y eficacia de la organización. Identifica los asuntos críticos y las nuevas posibilidades. Buscan nuevas oportunidades. Los inventores y sus innovaciones tecnológicas precisan de los emprendedores para encuadrarlas en una iniciativa de cambio.

Integrador: Forja alianzas. Consigue su aceptación personal, y ayudan a que su equipo y su programa también lo consigan. Relaciona los planes tácticos con los estratégicos y con los asuntos organizativos. En la práctica la cobertura de este rol es el principal factor que asegura el éxito ya que garantiza el cumplimiento de los perfiles de cada rol, es decir, ayudan al equipo a formarse y madurar.

Experto: Asume la responsabilidad del conocimiento técnico y las habilidades necesarias para el cambio. Es capaz de explicar la información de una manera lógica.

Gestor: Simplifica, delega, asigna prioridades y hace que se realice el trabajo a toda costa. Dirige y controla las actividades del personal clave sin ser autoritario.

Patrocinador: Asegura el apoyo y los recursos desde los niveles más altos de la organización. Explica dónde encaja el cambio dentro de la visión global de la organización. Pone al corriente constantemente a la Alta Dirección respecto al progreso del cambio.

Las contribuciones individuales de cada uno de los seis roles son esenciales para la vida del proyecto del cambio. Son los esfuerzos combinados de estos roles los que hacen posible la innovación. No es necesario que haya una persona por rol, pero sí que estén todos los roles cubiertos.

Al identificar cada una de las personas con un rol determinado se cuantifica. Luego se realiza un gráfico de Kiviant mediante el porcentaje resultante de dividir para cada rol el número de preguntas con las que se siente identificado por el número de preguntas para cada rol.



21.10 Acciones para el fracaso.

Existen un conjunto de reglas generales que nos aseguran el fracaso del cambio y que conviene evitar:

✔ Ignorar la sensibilidad de las personas✔ Ignorar los aspectos de las relaciones humanas.✔ Resolver las relaciones discutiendo aspectos técnicos✔ Tratar a la gente de la misma forma que se trata a las máquinas.✔ Ignorar los principios del cambio.✔ Asumir que la percepción propia representa la realidad.

21.10.1 El promotorComo encargado de autorizar y/o reforzar los cambios requeridos para una mejora, el promotor puede contribuir al fra

caso si:

➢ Elige la tecnología equivocada.➢ Asigna a la persona inadecuada.➢ Se compromete para el corto plazo.➢ Establece expectativas no realistas.➢ Cree que sabe todo lo que necesita saber.➢ Espera que todos tengan las habilidades que se necesitan.➢ Exige el esfuerzo de mejora como una imposición.➢ Pide resultados inmediatos.➢ Recorta el presupuesto de formación.

21.10.2 La culturaLa cultura de una organización es extremadamente resistente al cambio. Los desafíos culturales producen descontento,

ansiedad y pueden producir reacciones emocionales extremas. Los esfuerzos de mejora deberían alinearse con la cultura existente en todo lo posible. La cultura puede producir el fracaso si:

➢ Se utiliza como una excusa para el inmovilismo.➢ Se infravalora la fuerza del status quo.➢ Se asume que la cultura del cambio es una cosa trivial.

21.10.3 La Historia.La historia de una organización está muy relacionada con su cultura, pero es más consistente. Puede contribuir al fraca

so si:

➢ Se continúa haciendo las cosas como siempre se han hecho.➢ Se continúa con optimismo a pesar de los errores del pasado.➢ Se asume que los demás recordarán la historia como uno mismo.

21.10.4 La transiciónDesde el status quo a una nueva forma de trabajo se requiere una transición en la que lo nuevo y lo viejo coexisten. La

duración de esta transición depende de la magnitud del cambio. Es importante planificar y seguir el proceso de forma que se pueda corregir. La transición contribuye al fracaso si:

➢ Se sustituye la preparación por la oración.➢ Se espera en lugar de planear.➢ Se sigue un plan a ciegas sin importar lo que ocurra.➢ Se pide un incremento de productividad inmediato.➢ Se ignora la necesidad de gestionar la transición.➢ No se controla el progreso.➢ Se continua recompensando el mismo comportamiento.➢ No se establece un final claro.

21.10.5 La resistenciaSi la resistencia al cambio no se gestiona bien se puede socavar totalmente una iniciativa de mejora. Puede contribuir al

fracaso si:

➢ Se fomenta la resistencia subterránea➢ Se ignora la realimentación que no se desea oír.



➢ Se infravaloran o ignoran los costes de personal.➢ No se implica a la gente que tendrá que cambiar.➢ Se habla de cooperación pero se anima a la competición.

21.10.6 El agente del cambio.El promotor no puede mejorar todos los detalles, por lo que encarga a uno o varios agentes del cambio el implementar

los detalles para una iniciativa específica bajo sus auspicios. El agente del cambio puede contribuir al fracaso si:

➢ Establece calendarios agresivos y optimistas.➢ Trabaja más duro en lugar de más inteligentemente.➢ Considera condicionantes políticos antes que cualquier otra cosa.➢ Trabaja sin interés.➢ Se alinea con la organización.➢ Se toma los contratiempos a nivel personal.

21.11 Como enfrentarse a la resistencia.

Los indicios de la resistencia se identifican prestando atención a los indicios no verbales propios y de los demás como los signos de intranquilidad, alejamiento y tensión y el cansancio e irritación.

Identificar la resistencia se concreta en poder dominarla con un lenguaje neutral, se trata de conocer cuáles son las reservas o las preocupaciones de la persona que se resiste.

El problema no se puede tomar por el lado personal, tras identificar la resistencia es necesario enfatizarla. Unos consejos útiles son:

✗ Reconocer los callejones sin salida.✗ Los técnicos no prestan atención a las comunicaciones a nivel emocional.✗ Los problemas personales desbaratan los esfuerzos del cambio más frecuentemente que los problemas técnicos.


Análisis y Gestión del Desarrollo del Software -...

Documents

Transcript of Análisis y Gestión del Desarrollo del Software -...