|
Algunas evidencias del desarrollo de software |
|
|
|
06.06.2007 |
|
 De las 55 evidencias de la Ingeniería del Software (55 facts) que recopiló hace algunos años Robert L. Glass en su libro "Facts and Fallacies of Software Engineering " esta es mi selección personal:
Gestión de personas
- El factor más importante en el trabajo con software no son las herramientas, ni las técnicas usadas por los programadores; sino la calidad de los programadores.
- Los mejores programadores son 28 veces mejor que los peores. Dado que las diferencias de paga no alcanzan esta proporción, representan la mayor ganga en el campo del software.
- Añadir personal a un proyecto retrasado lo retrasa más.
- El entorno de trabajo ejerce gran impacto en la productividad y en la calidad del producto.
Estimaciones - Una de las dos causas principales que generan proyectos desbordados son las estimaciones mal realizadas.
- Normalmente las estimaciones se realizan al comenzar el ciclo de vida. Tiene un cierto sentido, si no fuera porque de esta forma se hace la estimación antes de definir los requisitos, y por lo tanto antes de conocer el problema.
- La estimación se produce por tanto en el momento erróneo.
- La mayoría de las estimaciones las realiza personal de gestión o de marketing, no las personas que van a construir el software, o sus gestores.
- La estimación la realizan las personas inadecuadas.
- Una vez realizadas las estimaciones no se gestionan con pautas de gestión de proyectos (supervisión periódica, revisión por la ocurrencia de riesgos, modificaciones...)
Conclusiones: No se realizan en el momento oportuno, no las realiza el personal adecuado, o este no tiene la formación necesaria; y no se gestionan adecuadamente.
Reutilización
- La reutilización de pequeñas librerías o subrutinas llava empleándose 50 años de forma satisfactoria.
- La reutilización de grandes componentes es normalmente un problema sin resolver, aunque todo el mundo coincide en que es importante y deseable.
- La reutilización de grandes componentes funciona mejor en familias de sistemas relacionados. Este hecho reduce la potencialidad de la aplicación de la reutilización de grandes componentes.
- Hay dos principios en la reutilización:
a) Es 3 veces más difícil construir componentes reusables que no reusables.
b) Un componente reusable debe probarse en aplicaciones diferentes antes de adaptarse a una librería.
- La modificación de código reutilizable es especialmente generadora de errores. Si se va a revisar más del 10 o 25% de un componente, es mejor rehacerlo de nuevo.
- La reutilización de patrones de diseño es una solución a los problemas inherentes a la reutilización de código.
Ciclo de vida
Requisitos - Una de las dos principales causas de proyectos desbocados es la inestabilidad de los requisitos.
- Los errores de los requisitos son los más caros de resolver durante la producción, y los más baratos de resolver durante el desarrollo.
- El error más difícil de corregir de los requisitos es: requisitos insuficientes.
Diseño
- Al trasladar los requisitos al diseño surge una explosión de requisitos derivados: requisitos para una particular solución de diseño.
- A menudo la lista de estos requisitos de diseño es 50 veces mayor que la original.
- Rara vez hay una única buena solución de diseño para un problema de software.
- El diseño es un proceso complejo e iterativo. La solución inicial de diseño a menudo suele tener errores y no es ciertamente la optima.
Depuración de errores
- La localización y limpieza de errores es la fase que más tiempo consume en el ciclo de vida.
- Cuando el programador cree que lo ha probado a fondo, normalmente solo ha ejecutado un 50 0 60% de las trayectorias lógicas. Empleando soporte automatizado como analizadores, puede alcanzarse hasta el 80 ´0 90%. Es prácticamente imposible probar el software hasta el nivel del 100%.
(CMMI no recomienda introducir herramientas de chequeo sin un nivel 3 de madurez).
Revisiones e inspecciones
- Las revisiones rigurosas pueden remover el 90% de los errores de un producto de software antes de realizar el primer caso de prueba.
- No obstante no pueden reemplazar a las pruebas.
- Las revisiones posteriores a la entrega (a veces llamadas "retrospectivas") suelen considerarse importantes, tanto para determinar la satisfacción del cliente como para mejorar procesos, pero es muy raro que se hagan.
- Las revisiones entre iguales (peer reviews) tienen un carácter técnico y social. Si solo cubren uno y les falta el otro son un desastre.
Mantenimiento
- Normalmente consume del 40 al 80% (la media es el 60) de los costes del software. Por esta razón probablemente sea la fase más importante del software.
Calidad
Eficiencia
- La eficiencia radica más en un buen diseño que en una buena codificación.
Investigación
- La mayoría de los investigadores en Ing. del Softw. hacen más de abogados que de investigadores, sin saber la mayoría de las veces que algunos argumentos que defienden valen menos de lo que creen, y hay pocos investigadores que analicen los pesos reales de las diferentes técnicas y líneas.
 |
RSS de los comentarios
Un saludo.