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
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 3
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 4 J.M. Godoy, F. Gómez y E. Rubio. 20032004
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
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 5
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 6 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 7
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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
página 8 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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?
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 9
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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
página 10 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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).
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 11
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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á.
página 12 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 13
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
Plan Real Hasta la fecha % Hasta la fecha
Revisión del códigoCompilaciónPruebas
Total
Def/HoraTiempo mínimo
Defectos eliminadosPlanificaciónDiseñoCodificación
Plan Real Hasta la fecha % Hasta la fecha
Revisión del códigoCompilaciónPruebas
Total
Def/Hora
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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
página 14 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 15
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 16 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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:
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 17
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 18 J.M. Godoy, F. Gómez y E. Rubio. 20032004
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
Fecha Número Defecto CorregidoTiempo de correcciónEliminadoTipo Introducido
Fecha Número Defecto CorregidoTiempo de correcciónEliminadoTipo Introducido
Fecha Número Defecto CorregidoTiempo de correcciónEliminadoTipo Introducido
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 19
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 20 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 21
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 22 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 23
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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:
página 24 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Interconexiones
Cálculo Decisión
Funciónpredefinida
Funcióndefinida
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 25
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 26 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 27
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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
página 28 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 29
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
✔ 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
página 30 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 31
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 32 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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 ?
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 33
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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:
página 34 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
✔ 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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 35
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
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
✔ 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?
página 36 J.M. Godoy, F. Gómez y E. Rubio. 20032004
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
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
➢ 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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 37
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
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.
página 38 J.M. Godoy, F. Gómez y E. Rubio. 20032004
Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED)
➢ 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.
J.M. Godoy, F. Gómez y E. Rubio. 20032004 página 39