|
Son muchas las críticas que argumentan que la ingeniería del software se asienta sobre bases y conceptos erróneos. En algunas se afirma incluso que el desarrollo de software no se sujeta a los principios científicos y rigurosos, propios de las ingenierías. Este artículo es una versión modificada del publicado en wikipedia "Criticism of software engineering" , y recoge la relación de críticas más frecuentes hacia la ingeniería del software; acompañadas de sus correspondientes reflexiones.
El espíritu de muchas de ellas es común a otras actividades humanas.
Gestión de las expectativas
crítica
La ingeniería del software considera transcendental para el éxito de sus proyectos, satisfacer las expectativas del cliente relativas al resultado y a las fechas de entrega. Por esta razón se parece más a la sicología o al marketing, y no a una ingeniería tradicional con regulación legal de responsabilidades por incumplimiento de intereses generales para la sociedad o para sus clientes.
Respuesta
Todas las profesiones e ingenierías gestionan expectativas. De hecho el concepto de responsabilidad frente a intereses generales de la sociedad implica la satisfacción de las expectativas de quienes en mayor o menor medida resultan implicados por los proyectos de ingeniería.
Requisitos deficientes
Crítica
La mayoría de los proyectos de ingeniería del software tienen requisitos incompletos o inconsistentes. Unas veces se debe a la poca experiencia de los clientes para especificar requisitos. Otras a que no saben bien qué es lo que necesitan y se limitan a decir "Lo sabré cuando lo vea". Incluso los clientes que conocen qué es exactamente lo que quieren encuentran difícil expresarlo en forma de requisitos.
Además de estas dificultades suele ser normal que los clientes esperen más de lo que han expresado, o que los documentos de requisitos describan aplicaciones sin una solución práctica informatizable.
Respuesta
El nivel de certidumbre que se puede obtener de la visión final de un sistema al comenzar su construcción varía en función de sus características: sistemas novedosos sin antecedentes similares previos, sistemas para integrarse en dispositivos de hardware, sistemas para realizar operaciones en negocios veteranos y conocidos o novedosos y sin experiencia previa por parte de los clientes, etc.
Optar por evitar todos los proyectos con requisitos deficientes o difíciles, o por aplicar siempre técnicas de prototipado y desarrollo ágil, o sus contrarias de no comenzar a trabajar hasta tener definido el sistema no son soluciones válidas.
La aplicación de metodologías de ingeniería de requisitos preventiva, o de desarrollo ágil reactivo debe decidirse según las características de cada proyecto.
Complejidad creciente
Crítica
Los críticos señalan el incremento en la complejidad de los requisitos y de las expectativas de los usuarios; y aunque se ha producido una mejora paralela en las tecnologías y las prácticas empleadas, no ha sido capaz de cerrar la brecha entre expectativas y resultados.
Respuesta
El incremento de la complejidad refleja el éxito de la profesión, porque la demanda es una consecuencia de la oferta. El hecho de que los clientes pidan más muestra su confianza en la capacidad de de respuesta de la profesión.
Cambio continuo
Crítica
Los profesionales del software desarrollan de forma continua nuevas prácticas y técnicas para aplicar en todos los entornos posibles. Los críticos argumentan que este desarrollo constante de nuevas prácticas evidencia los fallos de los anteriores.
Respuesta
Muchos ven en el cambio continuo una prueba de que la ingeniería del software se desarrolla y aprende de forma satisfactoria. También las ingenierías tradicionales desarrollan prácticas y técnicas nuevas de forma constante.
Fallos continuos
Crítica
Los críticos argumentan que son muy frecuentes los sistemas con diseños o desarrollos pobres, y que los desastres iniciales del software no han sido capaces de prevenir los siguientes.
Respuesta
Todas las profesiones que trabajan para realizar proyectos, cada vez mejores y más grandes cometen errores. La ingeniería tradicional también tiene fallos: Los automóviles matan a 40.000 personas cada año en los Estados Unidos. Los accidentes nucleares de Three Mile Island y Chernobyl o el desastre de la planta química de Bhopal mataron a centenares de personas. Las explosiones de las lanzaderas espaciales Columbia y Challenger; o el uso como aditivo para la gasolina del MTBE, que termina por contaminar el agua potable son algunos ejemplos.
Aunque se han desarrollado, y se desarrollan grandes sistemas de software, la presencia de errores es un problema tanto en la ingeniería del software como en la ingeniería tradicional.
Por eso hay quien afirma que la ingeniería del software ofrece ya resultados tan fiables y predecibles como la ingeniería aeroespacial o la biológica.
Fallos para determinar las causas con exactitud
Crítica
Las críticas afirman que mientras los ingenieros tradicionales analizan los errores, establecen con precisión sus causas y diseñan métodos para evitarlos en el futuro; los ingenieros de software no pueden establecer métodos rutinarios y sistemáticos para determinar con precisión sus causas, o tardan demasiado para evitar con garantías repeticiones futuras.
Respuesta
La depuración es la actividad que establece con claridad la causa de los fallos de las aplicaciones. Los procesos de mejora incluyen la búsqueda de la causa de los problemas en los procesos. Los ingenieros de software delimitan de forma sistemática las causas, y emplean los resultados para desarrollar mejores lenguajes, bases de datos, procesos y aplicaciones.
Nada nuevo
Crítica
Las críticas afirman que los ingenieros de software no crean nada nuevo, sino que se limitan a emplear lo ya conocido por la ciencia de la computación.
Respuesta
Motu proprio, los ingenieros de software optimizan compiladores, desarrollan sistemas para trazar y gestionar errores, para la gestión de la configuración, como CVS, o métodos de trabajo como Extreme Programming. Independientemente de quien crea o mejora las tecnologías y las prácticas, los ingenieros de software son brillantes a la hora de adoptar las mejores.
Cualquiera puede hacer ingeniería del software
Crítica
Cualquier persona hábil en otros campos (ingenieros, científicos, personas de negocio) pueden diseñar plantillas para hojas de cálculo o simulaciones, y de modo accidental llegar a escribir grandes aplicaciones, suponiendo así que son ingenieros de software. Por esta razón, la ingeniería de software no requiere conocimientos especiales.
Respuesta
La ingeniería de software es una práctica que requiere aprendizaje específico y práctica. Son ingenieros de software las personas que cuentan con la formación y práctica adecuadas, y se mantienen al día en la evolución de la tecnología, los métodos y las aplicaciones. Esto es aplicable a todas las profesiones.
No sabemos qué es la ingeniería del software
Crítica
La ingeniería del software no se ajusta a los modelos ortodoxos de definición y clasificación propios de las ingenierías (cálculo y rigor científico).
Respuesta
Esta afirmación la suelen realizar a menudo los críticos que quieren imponer sus propias definiciones.
Es mucho lo que sabemos en la actualidad de la ingeniería del software. Las tecnologías, prácticas y aplicaciones, así como la propia comunidad de la ingeniería del software está en continuo crecimiento. Por supuesto, los ingenieros de software mantienen desacuerdos sobre muchos detalles.
El software no es ciencia
Crítica
Las ingenierías civiles, eléctricas, mecánicas o químicas se construyen sobre resultados físicos o químicos cuyo rigor y solidez científica permiten construir sistemas complejos con métodos institucionalizados y sistemáticos. Sin embargo no ocurre lo mismo con el software, donde no es posible descomponer de forma sistemática un sistema complejo. Al no tener un acuerdo unificado sobre la Ingeniería del Software resulta difícil evaluar la cualificación de quienes la practican.
Respuesta
Los ingenieros de software emplean lógica, teorías probadas y matemática discreta para crear funciones en el desarrollo de programas.
No hay teoremas sobre personas y proyectos.
Crítica.
No hay teoremas que expliquen porqué unos ingenieros de software son más productivos que otros. Tampoco los hay capaces de explicar porqué unos proyectos fracasan y otros no. No se puede elaborar una ingeniería sin conocer esto.
Respuesta
Las ingenierías implican actividades sociales complejas. Ningún teorema puede explicar porqué un ingeniero mecánico es más productovo que otro. Ningún teorema puede explicar por qué algunos proyectos civiles como la construcción de carreteras Big Dig de Boston desbordan las estimaciones y presupuestos, o por qué se incendian las lanzaderas espaciales.
¿Qué es éxito?
Crítica
Según un estudio de Standish Group de 2000, el 28% de los proyectos de software se ejecutaban cumpliendo todas las condiciones de éxito (funcionalidad adecuada, cumplimiento de agendas y presupuestos); mientras que el 23% fallaba en todas.
Respuesta
Son muchos los proyectos de ingeniería incapaces de satisfacer las expectativas: muchos puentes y edificios se construyen desbordando agendas y costes. Considere que el 40% de las lanzaderas espaciales se han incendiado y el resto han quedado fuera de servicio para unos cuantos años. Casi todas las construcciones de casas suelen sobrepasar los costes y las agendas. El exito en los proyectos de software no es muy diferente al de su entorno.
Por arte de magia
Crítica
Después de un duro trabajo de programación para desarrollar un sistema, ocurre con frecuencia que los clientes no son conscientes de la dificultad que encierra.
Respuesta.
Esto ocurre en todas las profesiones.
El desarrollo de software es inherentemente creativo
Crítica
El software es un conocimiento para la ejecución que se descubre a través de un proceso creativo, donde el aprendizaje, el trabajo por prueba y error y la capacidad para lidiar con los retos de las propias asunciones son importantes. Para la fase de construcción se cuenta con el trabajo automatizado de los compiladores, pero los aspectos más difíciles se encuentran en la obtención de los requisitos y en el diseño del sistema, etapas más próximas a la creación artística que a la ingeniería o a la ciencia. Por eso el ámbito de los beneficios de la ingeniería del software se ciñe a facilitar que los desarrolladores puedan probar sus ideas, y puedan descubrir los errores con la mayor agilidad posible proporcionándoles información sobre el estado del sistema de software.
Respuesta
Desarrollar software supone construir artefactos lógicos con capacidad de trabajo. Las actividades de construcción entremezclan el componente técnico con el creativo que el diseñador, como autor de la obra, puede desarrollar en mayor o menor medida. De forma similar ocurre en otras ingenierías de construcción. En la arquitectura, por ejemplo, la faceta de ingeniería cubre el componente técnico. El nivel de creatividad y diseño se apoya más en el talento del creador, uso de maquetas, prototipos, etc.
Muchos ingenieros de software emplean métodos ágiles para desarrollar software, porque encuentran en ellos menos trabas para desarrollar la faceta creativa.
La ingeniería de requisitos establece procesos y técnicas para la obtención, análisis y especificación de las funcionalidades, parámetros de rendimiento y calidad que debe satisfacer el sistema; así como para su gestión y mantenimiento durante el ciclo de vida.
No hay consenso
Crítica
En las ingenierías tradicionales hay un área de consenso clara sobre cómo deben construirse las obras, con qué estándares y los riesgos que se asumen al descuidarlos. Los ingenieros que no siguen las prácticas de su profesión pueden ser demandados. Sin embargo no hay un consenso similar en la ingeniería del software, donde cada cual promueve sus propios métodos, proclamando grandes beneficios de productividad que generalmente no se respaldan con evidencias científicas imparciales.
Respuesta.
Sí, es cierto. La ingeniería del software es una disciplina muy joven que escasamente cuenta con cinco décadas de vida. El contraste y la experiencia de tendencias es el camino de la experiencia que da madurez a todas las ingenierías.
Revisión: 17 abril 2005 Copyright (c)2005 Juan Palacio
Con permiso para la copia, distribución y/o modificación de este documento en los términos de la licencia GNU Free Documentation License, en sus versión 1.02 o cualquiera de las posteriores publicadas por la Fundación de Software Libre.
|
Suscripción
RSS 
