Hacia una mayor calidad del software
Un requisito irrenunciable
De acuerdo con un estudio realizado por el Standish Group, un 52% de todos los proyectos emprendidos por los departamentos de informática interna alcanzan un costo del 189% de sus estimaciones originales, y contienen un 42% de las características o funciones propuestas originalmente; un 81% de todos los proyectos se cancelan antes de completarlos; y sólo un 16% de los proyectos se completan a tiempo y dentro del presupuesto.
Aunque siempre resulta agradable disponer de las funciones y características más recientes en el software, es hora de que los departamentos informáticos en las empresas reclamen también las mejores. Según los sociólogos, nos estamos moviendo hacia un término medio de mediocridad, y haciéndonos tolerantes con lo "suficientemente bueno" o lo "casi correcto". Después de todo, la mayoría de los aviones no se estrellan. La mayoría de los techos no gotean. Y, además, la mayoría del tiempo el software funciona. Es así como surgió el software "suficientemente bueno".
Aunque está muy bien conseguir la versión más reciente de un rápido programa de correo electrónico, cuando ese programa hace que el sistema falle a la tercera o cuarta vez que se utiliza, se pierde tiempo y aumenta el estrés.
¿Estamos realmente dispuestos a emplear tiempo en interrumpir y poner en marcha de nuevo el sistema a causa de un error en el mismo? ¿Es que no tienen importancia los cargos extra por conexión que se acumulan mientras se intenta desconectar el módem y volverlo a conectar? ¿Es aceptable perder 10 minutos de trabajo porque un conflicto entre dos aplicaciones produce un fallo total del sistema? ¿Puede permitirse el centro de proceso pasar por alto el retraso de un año en los planes porque el software no cumplía con lo prometido?
Contentarse con lo suficientemente bueno es hundirse en el fondo.
Suficientemente bueno
Lo cierto es que la calidad del software estándar no es tan mala como dice todo el mundo si se compara con los desarrollos internos. Los vendedores someten a sus productos a tests beta, que ofrecen a cientos o incluso a miles de personas la oportunidad de identificar defectos y permite al vendedor disponer de tiempo para remediar defectos críticos antes de la introducción formal del producto. Las empresas no pueden someter a sus aplicaciones de creación propia a un escrutinio así. Hay que enfrentarse a la realidad: Los vendedores se concentran principalmente en las funciones comerciales críticas que sus productos han sido diseñados para soportar y, por lo tanto, los defectos de sus productos pueden ser más una molestia que un obstáculo serio. Aunque esto no es una excusa para interfaces deficientes o un diseño no intuitivo, lo importante es poder realizar el trabajo.
Las empresas han llegado a una situación en la que esperan y aceptan productos defectuosos. Los vendedores de software apuestan su futuro en cada introducción o mejora importante de un producto, y cualquier despliegue catastrófico podría muy bien ser el último. ¿Cuánto tiempo seguirá en actividad un vendedor si suministra sólo un 42% de la funcionalidad prometida?
¿Está libre de defectos el software de los vendedores? Obviamente, no. Los vendedores son especialmente sensibles a las demandas que plantea la introducción a tiempo de un producto en el mercado. La competencia es abundante, y nuevas empresas se unen a ella cada día. Entonces, ¿a quién culpar por un software defectuoso? Los vendedores reaccionarán ante las demandas y expectativas de la comunidad de consumidores y continuarán suministrando productos defectuosos hasta que elevemos nuestras expectativas de calidad y rehusemos adquirir productos defectuosos. Actualmente, se compra un producto sabiendo que tiene defectos, pero con cierta seguridad de que está en camino un arreglo mediante la transferencia de un fichero por el World Wide Web o mediante un nuevo release. Así, el comprador queda satisfecho, y el vendedor también.
Causas fundamentales de un software deficiente:
---------------------------------------------------------------------
1. Formación inadecuada de los directores y del staff.
2. Evaluación inadecuada de los defectos y de los costos.
3. Excesiva presión para el cumplimiento de los plazos.
4. Insuficiente eliminación de los defectos.
5. Altos niveles de complejidad.
6. Requerimientos y diseño ambiguos y de consecuencias imprevisibles.
Un doce por ciento de las compañías se han enfrentado a problemas de responsabilidad respecto a daños directos en relación con la falta de calidad del software.
En junio de 1996, el cohete Ariane 5 de la Agencia Espacial Europea realizó su primer viaje. Treinta segundos después del despegue, una parte del software falló y el vehículo de lanzamiento se autodestruyó. El Ariane 5 había costado más de 7.000 millones de dólares y su desarrollo había requerido casi 10 años.
Un sesenta y cinco por ciento de las compañías afirman que la mejor forma de satisfacer las demandas de calidad del software es "crear un proceso que establezca objetivos y en el que los tests se inicien al comienzo del ciclo de desarrollo".
¿En qué se emplea el tiempo de mantenimiento del software?
Análisis de la codificación: 47%
Tests y depuración de errores: 28%
Escribir codificación: 19%
Documentación: 6%
Aunque siempre resulta agradable disponer de las funciones y características más recientes en el software, es hora de que los departamentos informáticos en las empresas reclamen también las mejores. Según los sociólogos, nos estamos moviendo hacia un término medio de mediocridad, y haciéndonos tolerantes con lo "suficientemente bueno" o lo "casi correcto". Después de todo, la mayoría de los aviones no se estrellan. La mayoría de los techos no gotean. Y, además, la mayoría del tiempo el software funciona. Es así como surgió el software "suficientemente bueno".
Aunque está muy bien conseguir la versión más reciente de un rápido programa de correo electrónico, cuando ese programa hace que el sistema falle a la tercera o cuarta vez que se utiliza, se pierde tiempo y aumenta el estrés.
¿Estamos realmente dispuestos a emplear tiempo en interrumpir y poner en marcha de nuevo el sistema a causa de un error en el mismo? ¿Es que no tienen importancia los cargos extra por conexión que se acumulan mientras se intenta desconectar el módem y volverlo a conectar? ¿Es aceptable perder 10 minutos de trabajo porque un conflicto entre dos aplicaciones produce un fallo total del sistema? ¿Puede permitirse el centro de proceso pasar por alto el retraso de un año en los planes porque el software no cumplía con lo prometido?
Contentarse con lo suficientemente bueno es hundirse en el fondo.
Suficientemente bueno
Lo cierto es que la calidad del software estándar no es tan mala como dice todo el mundo si se compara con los desarrollos internos. Los vendedores someten a sus productos a tests beta, que ofrecen a cientos o incluso a miles de personas la oportunidad de identificar defectos y permite al vendedor disponer de tiempo para remediar defectos críticos antes de la introducción formal del producto. Las empresas no pueden someter a sus aplicaciones de creación propia a un escrutinio así. Hay que enfrentarse a la realidad: Los vendedores se concentran principalmente en las funciones comerciales críticas que sus productos han sido diseñados para soportar y, por lo tanto, los defectos de sus productos pueden ser más una molestia que un obstáculo serio. Aunque esto no es una excusa para interfaces deficientes o un diseño no intuitivo, lo importante es poder realizar el trabajo.
Las empresas han llegado a una situación en la que esperan y aceptan productos defectuosos. Los vendedores de software apuestan su futuro en cada introducción o mejora importante de un producto, y cualquier despliegue catastrófico podría muy bien ser el último. ¿Cuánto tiempo seguirá en actividad un vendedor si suministra sólo un 42% de la funcionalidad prometida?
¿Está libre de defectos el software de los vendedores? Obviamente, no. Los vendedores son especialmente sensibles a las demandas que plantea la introducción a tiempo de un producto en el mercado. La competencia es abundante, y nuevas empresas se unen a ella cada día. Entonces, ¿a quién culpar por un software defectuoso? Los vendedores reaccionarán ante las demandas y expectativas de la comunidad de consumidores y continuarán suministrando productos defectuosos hasta que elevemos nuestras expectativas de calidad y rehusemos adquirir productos defectuosos. Actualmente, se compra un producto sabiendo que tiene defectos, pero con cierta seguridad de que está en camino un arreglo mediante la transferencia de un fichero por el World Wide Web o mediante un nuevo release. Así, el comprador queda satisfecho, y el vendedor también.
Causas fundamentales de un software deficiente:
---------------------------------------------------------------------
1. Formación inadecuada de los directores y del staff.
2. Evaluación inadecuada de los defectos y de los costos.
3. Excesiva presión para el cumplimiento de los plazos.
4. Insuficiente eliminación de los defectos.
5. Altos niveles de complejidad.
6. Requerimientos y diseño ambiguos y de consecuencias imprevisibles.
Un doce por ciento de las compañías se han enfrentado a problemas de responsabilidad respecto a daños directos en relación con la falta de calidad del software.
En junio de 1996, el cohete Ariane 5 de la Agencia Espacial Europea realizó su primer viaje. Treinta segundos después del despegue, una parte del software falló y el vehículo de lanzamiento se autodestruyó. El Ariane 5 había costado más de 7.000 millones de dólares y su desarrollo había requerido casi 10 años.
Un sesenta y cinco por ciento de las compañías afirman que la mejor forma de satisfacer las demandas de calidad del software es "crear un proceso que establezca objetivos y en el que los tests se inicien al comienzo del ciclo de desarrollo".
¿En qué se emplea el tiempo de mantenimiento del software?
Análisis de la codificación: 47%
Tests y depuración de errores: 28%
Escribir codificación: 19%
Documentación: 6%
