1. El trabajo del ingeniero del Software

Transcripción

1 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 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 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 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: Definir el objetivo de la calidad Medir la calidad del producto Comprender el proceso Ajustar el proceso Utilizar el proceso ajustado Medir los resultados Comparar los resultados con el objetivo Realimentar y continuar mejorando J.M. Godoy, F. Gómez y E. Rubio página 1

2 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 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) 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

3 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 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 Comienzo Fin Tiempo de interrupción de tiempo 03/11 9:00 9: Codificar HotelSI 1 Fecha: Actividad Comentarios C U 12:40 13: Leer Perl X 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 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 página 3

4 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 Relación entre planes de periodo y planes del producto Tareas basadas en el producto Tareas basadas en el periodo Ingresos Gestión corporativa Inversiones Dividendos / Intereses Clientes Fondos Planes del período Inversores Productos Marketing Planes de productos Finanzas Fabricación Ingeniería Precios y Previsiones Administración 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

5 4.2. Resumen Semanal de Actividades Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED) 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 Lunes 03/ Martes Miércoles Jueves Viernes Sábado Domingo Total Tiempos y Medias del Período Número de semanas (número anterior + 1): 3 Resumen de las semanas anteriores Total Media Máxima Mínima Resumen incluyendo la última semana Total Media Máxima Mínima 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 página 5

6 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 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 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 /11 Codif Descripción: Escribirelprograma 1 (minutosporprograma) 3/11 Leer Descripción: Leersietecaptulosde í PSP (minutospor captulo) í 4/11 Codif Descripción: Escribirelprograma 2 (minutospor 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

7 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 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 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: Programa Tiempo de desarrollo LOC Minutos/LOC Funciones Fecha: Bucle W HILE sencillo Sentencia CASE sencilla Sentencia CASE grande 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 W HILE sencillo 5 14 W HILE grande W HILE grande Case 2 11 CASE sencillo CASE sencillo CASE grande Estimado J.M. Godoy, F. Gómez y E. Rubio página 7

8 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 Cómo hacer una estimación de tiempo Comenzando por los datos de cómo se ha utilizado anteriormente el tiempo, se pueden asignar cantidades de tiempo que probablemente se utilizarán de cada categoría en el futuro. Un ejemplo de estimación de tiempo preliminar será: Actividad Minutos estimados Codificar 360 Leerlibros 180 Resumir 150 Prepararex ámenes 120 Otros 30 Minutos reales 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 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: Estimación semana #1 Fecha: Tarea Codif. Leer Resumir... Total Lunes Martes Miércoles Jueves Viernes Sábado Domingo Total página 8 J.M. Godoy, F. Gómez y E. Rubio

9 7.4. Priorizar el tiempo Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED) 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 Exigida Trabajocasa Inform ática Discrecional Comer Dormir Entretenimiento Totales 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 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 página 9

10 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 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 minimizar el impacto 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 cometan 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 comprometida Semanal Compromiso Con quién? Horas Fecha: Fecha de inicio Se consigue L M X J V Trabajoremunerado Gerente 24'0 Nómina L M V Entregarresumen AGDS Equipo 9'0 Aprobar L M X J V TrabajoIBM (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

11 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 diagrama de Gantt: Proyecto: Autor: Fecha: ID tarea 1 Requisitos 2 Terminado Nombre 3 9 Nov. 3 Estudiary planificar 4 Propuesta 5 Aceptada 6 Dise ño Nov Nov. 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: Nov. 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 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: Des Des Des Des Des. ID tarea Nombre 3 9 Nov Nov Nov Nov. 1 7 Des Des Des Des Des. 1 Requisitos 2 terminado 3 Estudiary planificar 4 Propuesta 5 aceptada 6 Dise ño El ejemplo muestra una situación concreta. La línea vertical indica la fecha en que se realiza el informe (02/12/03). Se puede apreciar que la tarea ID 1 ha sido completada; la ID 3, casi; y la ID 4, un poco menos. Además, un punto de control (ID 2) ha sido superado (la flecha indica la fecha real de su realización). J.M. Godoy, F. Gómez y E. Rubio página 11

12 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 Seguimiento del valor conseguido La siguiente tabla permite realizar un seguimiento adaptativo del proyecto: Semana Valor Planificado Valor Ganado Valor Estimado % 16.2% % 38.2% % 69.4% % 92.5% % 115,7% % 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

13 10. El plan del proyecto 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 Resumen del plan del proyecto Nombre: Fecha: Programa: Programa #: Resumen Plan Real Hasta la fecha Minutos/LOC LOC/Hora Defectos/KLOC Rendimiento V/F Tamaño Programa (LOC) Total nuevo & cambiado Tamaño máximo Tamaño mínimo Tiempo por Fase (min) Planificación Diseño Codificación Revisión del código Compilación Pruebas Postmortem Total Tiempo máximo Tiempo mínimo Defectos introducidos Planificación Diseño Codificación Revisión del código Compilación Pruebas Total Plan Real Hasta la fecha % Hasta la fecha Plan Real Hasta la fecha % Hasta la fechadef/hora Defectos eliminados Planificación Diseño Codificación Revisión del código Compilación Pruebas Total Plan Real Hasta la fecha % Hasta la fechadef/hora J.M. Godoy, F. Gómez y E. Rubio página 13

14 10.3. Resumen Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED) 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) 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 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 / LOC Tiempo por fase máximo = Tamaño máximo Minutos / LOC Tiempo por fase mínimo = Tamaño mínimo Minutos / LOC página 14 J.M. Godoy, F. Gómez y E. Rubio

15 11. El proceso de desarrollo del software 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 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 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 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 página 15

16 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

17 12. Defectos Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED) 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 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 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 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 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 página 17

18 Tipos de defectos 10 Documentación 40 Asignación 70 Datos 20 Sintaxis 50 Interfaz 80 Función 30 Contrucción de paquetes 60 Chequeo 90 Sistema 100 Entorno Nombre Fecha Programa # Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido Fecha Número Tipo Introducido Eliminado Tiempo de corrección Defecto Corregido 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 U tilización del Cuaderno de Registo de Defectos. El reunir los datos de los defectos permite: Mejorar la programación. Reducir el número de defectos de los programas. Ahorro de tiempo. Ahorro de dinero. Realizar el trabajo de forma responsable 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

19 13.Encontrar defectos 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 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 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 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 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 página 19

20 Un guión para hacer revisión de código es: Análisis y Gestión del Desarrollo del Software (Ingeniería Informática. UNED) 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 Revisar antes de compilar. Las razones de efectuar la revisión antes de la compilación son: 1. El tiempo empleado es el mismo que si se hace después de compilar. 2. Supone un ahorro en tiempo de compilación. 3. Tras la compilación la revisión de código no suele ser completa. 4. La compilación es tan efectiva antes o después de la revisión de código 5. Cuando un programa tiene muchos defectos durante la compilación, generalmente tiene muchos defectos en las pruebas 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

21 14. Listas de comprobación para la revisión de código 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 # # # # Includes Verificarque los includes est án completos La lista de comprobación para la revisión de código Hasta la fecha % Hasta la fecha 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 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 compilación y pruebas. 3. Para los tipos con el más defectos, examinar el Cuaderno de Registro de Defectos y averiguar los errores específicos 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ódigo 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 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 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 página 21

22 15.La previsión de defectos 15.1 U tilización de los datos de defectos. La disciplina personal, asociada con la revisión de defectos y su análisis, es mucho más efectiva que los años de 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 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 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. Dd plan = 1000(D D i )/(N N i ) Como normalmente el nuevo programa tendrá la misma densidad de defectos: D plan= N plan*dd plan/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: D plan =Nplan*D Hasta la fecha /N hasta 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

23 16. La economía de eliminar defectos 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 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 Cálculo de los Defectos/Hora en el resumen del Plan del Proyecto defectosintroducidos Hastala Fecha enla fase Defectos/ Horaintroducidos Hasta la Fecha en una fase= minutos dedicados Hastala Fechaen la fase 60 defectos eliminados Hastala Fecha en la fase Defectos/ Hora eliminados Hastala Fecha en una fase= minutos dedicados Hastala Fecha enla fase 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. Plan de defectos eliminados antes de compilar Rendimiento Plan = Plande defectos introducidosantes de compilar 100 Defectos eliminadosreales antes de compilar Rendimiento Real = Defectos introducidosreales antes decompilar 100 Defectos eliminados Hastala Fecha antes de compilar Rendimiento Hastala Fecha = Defectos introducidoshasta la Fecha antes de compilar 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ódicamente 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 página 23