¿Debo escuchar a mi empleador y usar las herramientas CASE?

Mi empleador (no un desarrollador) cree que las herramientas CASE nos ayudarán a mejorar nuestro proceso de desarrollo y documentación. No estoy seguro de eso, somos un pequeño equipo de 5 desarrolladores que crean soluciones de banca móvil para clientes locales. Creo que las herramientas CASE serán una pérdida de tiempo y dinero, ya que deben comprarse y necesitaremos algo de tiempo antes de acostumbrarnos a ellas y ser eficientes trabajando con ellas para modelar y otras cosas. La generación de código es otro problema, realmente creo que el código generado por CASE no será tan bueno como el código escrito por buenos desarrolladores.

Creo que si nos atenemos a principios ágiles, diseñamos patrones, usamos TDD y mantenemos nuestro código limpio. Deberíamos ser buenos. Y en cuanto a Análisis y Diseño, creo que los diagramas UML simples en la pizarra deberían ser la solución. La documentación es buena e importante, pero debe hacerse lo menos posible y no debemos centrarnos en Docs y olvidar el código. Esto es lo que pienso.

¿Estoy en lo correcto? ¿O debería escuchar a mi empleador y comenzar a buscar una herramienta CASE adecuada?

La situación garantiza un enfoque analítico de la decisión. El resultado final será "¿La herramienta CASE proporciona un valor para el negocio?" A menudo, la gerencia querrá que los desarrolladores adopten una metodología o herramienta porque han escuchado cosas buenas al respecto, independientemente de cuán bien se ajuste a los procesos y la cultura actuales de la organización.

Si su empleador le ha pedido que busque herramientas CASE, como ChrisF señala, debe hacerlo (este es un problema en el lugar de trabajo, no de programación). Algunos factores que afectarían la adopción de una herramienta CASE incluyen:

• ¿Para cuáles de sus procesos hay herramientas CASE disponibles?
• Una estimación de cuántas horas-persona se necesitarían para adoptar las nuevas herramientas,
• ¿Cómo cambiarían los procesos con la adopción de las nuevas herramientas?
• o ¿Qué tipo de impacto positivo (o negativo) sería medible al adoptar las nuevas herramientas?

Piense en esto como una oportunidad para actualizar su entorno y procesos de desarrollo. Puede ser que sus procesos actuales coincidan perfectamente con la cultura de su organización, pero le debe a su empleador y a su equipo hacer la investigación adecuada.

Sí, debería comenzar a investigar las herramientas CASE.

1. Porque necesita evidencia para respaldar su afirmación de que no ayudarán. Nunca se sabe, es posible que le ayuden.
2. Porque tu empleador te lo dijo.

No repetiré los puntos expuestos por David Kaczynski en su excelente respuesta, ya que son exactamente los pasos que debes seguir.

Parece un gran cambio de paradigma de Agile a CASE / MDA orientado al desarrollo con generación de código. No necesariamente desde el punto de vista de la gestión de proyectos (un enfoque CASE no entrará en conflicto con los conceptos de iteraciones, historias de usuarios, retroalimentación rápida o mejora continua), pero definitivamente desde una perspectiva de "artesanía de software": significa menos control sobre el código código generado, generado que probablemente será ilegible, rígido, más difícil de probar, constantemente necesitando sincronización con el modelo, y así sucesivamente.

Por lo que describe, lo que su empleador necesita es fácilmente comprensible:

• Mejor documentación para evitar la pérdida de conocimiento si un desarrollador dejara el equipo.
• Un proceso de desarrollo más rápido.

Como profesional del software, definitivamente puede (y debe) contarle sus dudas sobre la capacidad del enfoque CASE para cumplir con estas expectativas. También es su deber comenzar a buscar herramientas CASE si así lo exige. Solo probar uno de ellos no significa 1 / que los resultados serán satisfactorios (especialmente estoy pensando en la sobrecarga de generación de código potencialmente grande que entra en conflicto con la necesidad de desarrollarse más rápido) y 2 / que no puede encuentre un compromiso donde se utilizarán algunas características de la herramienta CASE (diagramas, generación de documentación) mientras se preserva el contexto ágil existente.

Aquí hay un artículo interesante sobre las herramientas CASE en un entorno ágil y sus posibles beneficios / inconvenientes: http://www.agilemodeling.com/essays/simpleTools.htm

Mi empleador (no un desarrollador) cree que las herramientas CASE nos ayudarán a mejorar nuestro proceso de desarrollo y documentación ".

Si fuera a actuar como consultor para su empleador, estaría obligado a intentar disuadirlos de este tipo de cosas. En primer lugar, es un error de gestión importante que las personas que no están involucradas en el trabajo elijan herramientas para desarrolladores. Esto casi nunca sale bien. Es al menos el doble de malo cuando las personas que eligen no tienen una sólida formación técnica. Y si no tienen ninguna experiencia con las herramientas que están presionando, es probable que sea una debacle total.

La razón más probable por la cual la gerencia no técnica sugiere este tipo de cosas es porque alguien está tratando de venderles algo. Una empresa importante que vende este tipo de cosas tiene ingresos que están cayendo como un zepelín de plomo en el aire enrarecido. Los vendedores (también conocidos como revendedores, consultores) que no se han mudado a otra cosa están tratando rabiosamente de encontrar nuevas marcas, er ... clientes. Una de las principales razones por las que estas empresas están luchando es que ya no hay mucha demanda de este tipo de herramientas. Por "este tipo de herramientas", me refiero a las herramientas que prometen "eliminar el código de escritura". No hay nada malo con el código, dependiendo del idioma. El código escrito tiene abstracciones mucho más poderosas que las que ofrecen estas herramientas.

Una de las razones principales por las que esta es una forma tan pobre de administrar el desarrollo es que reducirá severamente el grupo de personas que está disponible para atraer a su equipo. Por un lado, necesitan aprender estas herramientas poco comunes y, en segundo lugar, los desarrolladores más experimentados no quieren trabajar con estas cosas. A menudo, el argumento en torno a este tipo de herramientas es que realmente no necesita buenos desarrolladores porque estas herramientas hacen la mayor parte del trabajo pesado. Esto es completamente falso. Es lo contrario. Hacen todas las cosas que son triviales y, a menudo, hacen que hacer las partes no triviales sea más difícil. Tampoco eliminan realmente la necesidad de escribir código.

Específicamente con las herramientas CASE, he trabajado en tres lugares diferentes que poseían estos paquetes. En cada uno, fue así:

1. El modelo fue cuidadosamente diseñado en la herramienta. Tomó mucho más tiempo de lo normal y no se produjeron resultados utilizables hasta muy tarde en el esfuerzo.
2. El modelo necesitaba ser aumentado con lógica empresarial. El modelo estaba equivocado y tuvo que modificarse manualmente durante las últimas fases del proyecto porque el esfuerzo estaba muy retrasado.
3. Volver a sincronizar el modelo y el código fue tan costoso que la herramienta CASE se archivó, y nunca más se volvió a usar.

En pocas palabras, fue un fracaso total del 100% y una pérdida de dinero en cada caso. Cuando he hablado con otras personas que han usado herramientas CASE en otras organizaciones, la historia siempre es la misma. No he usado todas estas herramientas y es posible que algunas personas las hayan usado bien, pero estoy bastante seguro de que la mayoría de los equipos que las han usado dejaron de usarlas hace mucho tiempo.

Uno de los beneficios que obtendría al investigar / implementar herramientas CASE es que habrá adquirido un conjunto de habilidades más comercializables para el empleo futuro. Creo que muchas de sus preocupaciones son notables, pero, como lo señaló David Kaczynski, esta no es una pregunta de programación sino una pregunta de relación empleador / empleado. Otro beneficio de las herramientas CASE es que una vez que se aprende, su empresa estará en condiciones de asumir una gama más amplia de proyectos de mayor complejidad. Es muy posible que un contrato que su empleador quiera obtener requiera o que otorgue preferencia al uso de herramientas CASE.

Está mezclando el problema y la solución y su jefe está tratando de ayudar, con más o menos éxito. Para desafiar a su jefe, debe tener claro cuál es su papel en la organización. Si él es el CEO y usted es el CTO, la decisión es suya y el CEO debe señalar qué aspectos comerciales se ven afectados por la falta de documentación. Su obligación será entonces resolver el problema comercial, con una herramienta CASE o cualquier otra solución con la que salga.

Con respecto a la sugerencia específica de usar las herramientas CASE, creo que debe elegirla correctamente para lograr su objetivo sin sobrecargar a su equipo con trabajo adicional. Si desea mejorar la documentación, puede tener suficiente con una herramienta que pueda generar diagramas a partir del código, no necesariamente para generar el código a partir del diagrama gráfico. Un ejemplo de tal herramienta es Codelogic . Hace unos años, me aseguré de que nuestros diseños fueran limpios y claros para ser entendidos y que fuera bastante fácil de usar. Si a medida que expresa dinero es otra preocupación, probablemente pueda buscar en el código abierto (no puedo ayudar aquí, pero estaría interesado en el resultado de cualquier investigación).

La alternativa a las herramientas CASE también puede ayudar. Medir cosas como las medidas ciclomáticas u otras medidas de complejidad mantendrá su diseño bien estructurado y los desarrolladores centrados en el código. Los mejores comentarios sobre su código, similares a los de Javacode, también pueden ayudar a mejorar la documentación.

Honestamente, creo que si considera que las herramientas CASE no ayudan a su jefe debe saberlo. Si es un buen jefe, valorará su opinión. Nunca me ha gustado un empleado que simplemente hace lo que se le dice sin un análisis crítico. Pero, por supuesto, como sugiere David, cualquier discusión debe mantenerse en argumentos fuertes y objetivos.

Trataría de hacer que su empleador se dé cuenta de que él / ella ha entendido las cosas al revés. Si hay margen de inversión para el equipo de software, debe identificar cuáles son sus cuellos de botella o problemas de calidad. SI resulta que tiene más margen de mejora en las áreas de documentación y proceso de desarrollo, debe identificar qué cambios tienen el mayor ROI con respecto a la mejora de estas áreas. Eso podría o no estar comenzando a usar herramientas CASE.

Ayuda a tu jefe, ayúdate a ti mismo

Puede reaccionar o actuar ante esta solicitud.

¿Recuerdas todas las preguntas de "Mover el monte Fuji"? Si estuvieras en una entrevista para un trabajo que realmente querías, no le dirías al entrevistador cuán estúpida fue la pregunta, pero seguirías haciendo preguntas y expresando tus mejores ideas para resolverla. En algunas culturas, nunca le dirías que no a un jefe que realmente te pidió que movieras el Monte Fuji, pero encontraría una manera para que ambos salvaran la cara.

Reenmarcar la pregunta

Si tuviera que replantear la pregunta en algo como,

"¿Puedo comprar o adquirir un conjunto de herramientas que automatizan la mayor cantidad posible de tareas de baja productividad relacionadas con el software?"

Esta tarea se vuelve mucho más sabrosa. Ayude a su jefe (y a usted mismo) dándole una opción con clara trazabilidad a CASE, y una o dos opciones ágiles / de código abierto / basadas en la nube.

CASO revisitado

En los años 90, las herramientas CASE podían tomar la forma de un conjunto de herramientas de Rational que probablemente incluía Requisite Pro, Rational Rose, Clear Case, Rational Robot (un corredor de prueba), Purificar, Cobertura pura y Cuantificar, y varias otras herramientas que se integraron juntos Si usted fuera una tienda MAD (Médica, Aviónica, Defensa), podría usar versiones actualizadas de estas herramientas para producir documentación extensa y rastreable y artefactos que a menudo requieren los clientes en esos mercados.

Póngase en contacto con IBM y obtenga un vendedor para que le dé una cotización de cinco licencias (o solo una licencia flotante). Agregue algo de entrenamiento también. Compartir esta cita con su gerente puede finalizar la charla sobre las herramientas CASE. Pero no me malinterpretes. Me gustan Rational, sus científicos principales y sus productos, pero los he accedido principalmente a través de licencias universitarias porque su precio era demasiado alto para las empresas donde trabajé. Si lo aprueban, al menos desde mi experiencia, tratarán su derecho con un buen apoyo, capacitación de calidad (generalmente en un complejo turístico de primer nivel con excelente comida).

Herramientas para la venta

Todavía tiene una gran oportunidad para ir de compras de herramientas. Los desarrolladores ágiles también necesitan herramientas. Puede comprar una suite que le brinde soporte de documentación para tarjetas de historias en línea, casos de uso, casos de uso y otros tipos de diagramas UML. Atlassian tiene lo que creo que es un buen conjunto de herramientas: Jira para el seguimiento de tareas y errores, Green Hopper por lo que describen como gestión de proyectos ágil, Confluence para una wiki de intranet, Crucible para la revisión de código en línea y Bamboo para un servidor de integración continua. Existen licencias de software como servicio para estos y otros conjuntos de herramientas dirigidos a sus necesidades si es ágil.

La integración IDE es otra vía para obtener un año 2012 equivalente a CASE. Si usted es un desarrollador de Microsoft, Visual Team Studio tiene herramientas que tienen un alcance similar al que creó Rational. Cuentan con ingeniería de software de ida y vuelta, generación de comprobantes de prueba de unidad de clases, integración con sistemas de control de origen y un conjunto de herramientas para la colaboración en equipo.

Herramientas de código abierto

En el lado de código abierto, Eclipse y sus muchos complementos intentan integrar un montón de herramientas de código abierto. No estoy seguro de si Eclipse Modeling Framework es maduro o si hay otras herramientas que brindan un ingeniero de software eficaz de ida y vuelta, pero la última vez que lo miré, no parecía muy fácil de lograr. El entorno Qt Creator se integra con el control de código fuente y tiene algunas capacidades para ayudarlo con la verificación puntual de la cobertura de código de los cambios mientras está en el editor.

Adopción de herramientas incrementales iterativas

Un enfoque iterativo / incremental para la selección de herramientas también puede ser muy efectivo. Los proyectos de código abierto a menudo admiten entornos únicos o múltiples. Sus elecciones de herramientas pueden verse influenciadas por las pilas que utiliza. Nunca es un buen momento para cerrar completamente el desarrollo, por lo que agregar y entrenar al equipo en algunas herramientas más pequeñas por trimestre puede ser mejor que un enfoque de big bang que cambie todo a la vez.

Soluciones de herramientas en la nube

Muchas de las soluciones enumeradas pueden requerir servidores y una configuración relativamente compleja. Hay muchas opciones en el mercado que se basan en la nube y proporcionan software como un servicio alojado por un proveedor por una tarifa mensual. Esto puede tener sentido para su equipo, ya sea a corto o largo plazo. Algunos pueden tener una solución alojada que puede usar para un inicio rápido, con la opción de comprar licencias más adelante.

Ninguna de estas sugerencias es un camino económico y fácil para la mejora instantánea de la productividad, pero si puede encontrar algunas de las herramientas indispensables una vez que las pruebe.

Una cosa que agregaría a las excelentes respuestas aquí es que podría beneficiarse al comprender cómo desea "mejorar su proceso de desarrollo".

La tendencia abrumadora en los últimos 20 años ha sido optimizar el desarrollo de software para su comercialización. "Agile", "lean", DevOps, TDD, BDD: se trata de sacar el software de calidad por la puerta lo más rápido posible.

Las herramientas CASE no tienen que ver con el tiempo de comercialización. Se centran en la trazabilidad, la coherencia del diseño, la integridad del modelo, etc. Todos estos son aspectos valiosos, especialmente en los sistemas bancarios, pero son a expensas del tiempo de comercialización.

Entonces, quizás pregunte a su jefe exactamente qué está tratando de optimizar.

Por experiencia, trabajar con herramientas CASE rápidamente se vuelve más difícil que trabajar con código, especialmente cuando se trabaja con dominios problemáticos que son más que promedio complejos. El proyecto deja de ser un proyecto "bancario" y, en su lugar, se convierte en un proyecto "insertar-nombre-de-CASE-tool-here".