¿Por qué las herramientas CASE no tuvieron éxito?

Question

... ¿o por qué fallaron?

Voy a construir una prueba de un concepto de algo que podría clasificarse como CASE, pero quiero evitar algunos de los errores cometidos antes.

Gracias!

Answer 1

En primer lugar, creo que los diagramas proporcionan un valor real cuando son pequeños y simples. Los diagramas grandes y altamente detallados en su mayoría desperdician mucho papel, tiempo, espacio en el disco duro, etc. Un lápiz y papel funcionan bastante bien para diagramas que son lo suficientemente pequeños (y bastante simples) para ser útiles. Una herramienta de software solo ayuda cuando está produciendo un diagrama que es tan grande y complejo que está prácticamente garantizado que es inútil.

En segundo lugar, en la mayoría de los casos, la forma más rápida de dibujar un diagrama, es comenzar por escribir un código (simplificado, simulado) y luego "invertir la ingeniería" del diagrama desde el código. Dibujar el diagrama directamente es a menudo más lento que escribir el código. Para proporcionar mucho valor real, producir el diagrama de alto nivel tiene que ser bastante más simple que escribir un código equivalente.

Cuando llegue el momento, rara vez he visto herramientas CASE utilizadas como una "ayuda" real para "ingeniería de software" de todos modos. En la mayoría de los casos que he visto, la ingeniería de software se realiza completamente por separado, y las herramientas CASE se usaron para realizar ingeniería inversa de diagramas a partir de código que ya estaba escrito. Las personas que producen los diagramas generalmente los consideran inútiles, y los incluyeron en informes a los gerentes de nivel superior para el "factor sorpresa". La única "ayuda" que esperaban de los diagramas era impresionar a la administración con la complejidad de lo que estaban haciendo con la esperanza de aumentar la financiación (algunos incluían diagramas de cosas como partes de la biblioteca estándar, para agregar pura complejidad). .

Editar: En cuanto a cómo fallaron las herramientas en la parte de ingeniería de software, no sé de una respuesta simple simple - por lo que he visto, diría que es más una "muerte de mil" nicks ", que cualquier problema único y evidente. Si tuviera que señalar un solo gran problema, sería que los que he visto realmente no tienen en cuenta los Patrones. Solo por ejemplo, lo que me gustaría es trabajar a un nivel de abstracción aún mayor, para poder señalar algunas funcionalidades y jugar con cosas como "cómo quedarían las cosas si tuviera que implementar las siguientes partes de esa funcionalidad como clases de decorador? " Sí, puedo dibujar un diagrama con ellos como clases de decorador, y uno sin, pero no tengo una forma realmente rápida y fácil de decir "transformar toda esta jerarquía para mover X, Y y Z en las clases de decorador".

Contraste una herramienta CASE típica con una hoja de cálculo. En una hoja de cálculo, puedo cambiar una celda y volverá a calcular automáticamente cómo afecta eso a cualquier otra cosa en la hoja de cálculo que dependa de ella. Por el contrario, las herramientas CASE parecen (al menos para mí) pegadas aproximadamente al nivel de un control de cuadrícula, donde puedo hacer cambios en una celda, pero aún tengo que rastrear manualmente qué otras células dependen de esa, y qué fórmulas para use, y calcule y modifique todas las celdas afectadas a mano. Sí, si quiero imprimir una hoja de los valores correctos, poder editarlos en la computadora para que no tenga marcas de borrador en las celdas y tal sería una mejora, pero solo pequeño mejora, no del tipo que convirtió las computadoras personales de juguetes para unos pocos aficionados en un elemento básico de prácticamente todos los negocios en la tierra.

Answer 2

Si mira la entrada de Wikipedia: http://en.wikipedia.org/wiki/Computer-aided_software_engineering, verá las herramientas "clásicas" de la década de 1990. Habiendo trabajado con muchas de esas herramientas, sugeriría que el enfoque en la comercialización fragmentó el mercado. Típicamente, no solo pagó grandes sumas por las herramientas, sino también por consultoría, capacitación y entornos de tiempo de ejecución. Con tantas herramientas en oferta, era difícil crear un equipo competente que se especializara en una herramienta determinada.

Además, no ayudó que las herramientas se vendieran en exceso. Gestiones prometedoras incrementos poco realistas en la productividad. No hay otra área de TI en la que haya visto tanto material de estantería: productos utilizados para un proyecto y luego abandonados, a menudo junto con el proyecto también.

Los conceptos de CASE permanecen en Eclipse y muchas otras herramientas MDE. Los problemas de las curvas de aprendizaje y la fragmentación aún no se han resuelto. Si bien el costo de las herramientas se ha reducido (a ser gratuito en muchos casos), los costos de capacitación, consultoría y aumento continúan.

Antes de gastar mucho esfuerzo en su herramienta CASE, eche un vistazo a los campos de MDA, MDE, DSL, incluso UML. Vale la pena explorar el sitio web de OMG también.

Al final del día debe enfocarse en lo que produce y no en la herramienta. Si puede automatizar algunas tareas, entonces eso es bueno. Construir otra herramienta similar a CASE es un gran ejercicio intelectual, pero con mínimas posibilidades de éxito comercial. Después de todo, IBM, Oracle y Computer Associates solo han tenido éxitos esporádicos con sus herramientas y todavía las están comercializando enérgicamente a clientes empresariales.