5. Poniendo todo junto, y agregando lo que falta: El Proceso de
10.2. Acerca el Simulador de Impacto Ganancial
Como dije al comienzo de las conclusiones, la utilidad del Simulador de Impacto Ganancial aún está por verse. De todas maneras haré algunas aprecia- ciones en base a las evidencias que se tienen hasta el momento, y también un poco de futurología, lo más sustentada que pueda.
A la última palabra respecto del SIG, por supuesto, la tendrán siempre los integrantes del CEPLAD, por ser ellos los usuarios nales y también quienes establecen los requerimientos. Pablo Benchimol, becario del CEPLAD, y la per- sona destinada a hacer el seguimiento de este proyecto, hizo la evaluación que esperaba, que se puede resumir en sus siguientes palabras textuales9:
Pablo: me gusto
el orden que planteas es util
hay q darle practica para que sea mas uido el uso
y pense el lo groso que quedaria el programa agregando una fase basica de capital jo
En un tenor parecido se encuentra mi evaluación personal. El SIG, sin dejar de decir que en su versión actual efectivamente funciona, tiene un potencial muy grande y muchas direcciones en las que puede crecer. Por el grado de abstracción y generalidad que utiliza, la base que provee puede ser utilizada para desarrollos especí cos en ámbitos muy variados, ya sea en el agro o en la industria, en una empresa con patronal o con gestión obrera, en el control paralelo, etc.
10.2.1. El SIG vs. el YSI
Otra referencia bastante objetiva para hacer una evaluación es el YSI, la versión del Simulador desarrollada por Axel Kicillof y presentada en [LK99]. Haciendo una comparación sin entrar en las propiedades internas del software, se puede decir que en muchos aspectos el SIG supera a su predecesor, y en otros está preparado para hacerlo. Tampoco tiene sentido comparar en términos de funcionalidad real, ya que el YSI puede ser cali cado más bien como un prototipo, y no se encuentra preparado para ser utilizado en la práctica. Hago foco, entonces, en la funcionalidad que ambos productos proponen.
Para empezar, se debe recordar que el Modelo de Rotación del Capital im- plementado en el SIG es una versión simpli cada del Modelo utilizado en el YSI. No considera, entonces, la incidencia del capital jo, ni permite calcular el conjunto de resultados asociados al capital, si no sólo los resultados de la empresa ([LK99]).
Los sistemas de escenarios provistos en ambos programas son conceptual- mente similares. En el SIG se agrega la posibilidad de trabajar con varios esce- narios base, cada uno con su correspondiente cronoestructura base, en los que se pueden considerar por separado distintos aspectos del negocio.
Por otra parte, el conjunto de cambios permitidos en los subescenarios es mayor en el YSI, por ejemplo permitiendo modi caciones en las condiciones de
pago10. Además, el YSI provee una interfaz grá ca que permite de nir visual- mente los valores de modi cación a lo largo del período de registro. A favor del SIG se puede decir que provee una forma más general de de nir el conjunto de operaciones que será afectado por los cambios, ya que se basa en catego- rizaciones de nidas por el usuario. En el YSI sólo se hace la distinción de las operaciones por ítem asociado y por cliente o proveedor.
No hay punto de comparación en cuanto a las fuentes externas de datos que pueden ser utilizadas, ya que el YSI sólo cuenta con una base de datos interna modi cable sólo a través de ingeniería inversa y reprogramación. En teoría, de acuerdo a [LK99], el YSI extrae automáticamente la información de los archivos de la empresa. Esto se puede hacer en la versión actual del SIG, aunque sólo a través de planillas de cálculo, y no directamente interactuando con la base de datos de ningún sistema de gestión.
10.3. Recapitulando
En resumen, puedo concluir que los objetivos básicos de este trabajo se cumplieron a pesar de su envergadura.
Se logró desarrollar un estudio bastante completo del método de Meyer y de las posibilidades de implementarlo en Java con las herramientas existentes. Incluso se pudo ir poco más lejos proponiendo algunos patrones y consejos para la aplicación del método. Se desarrollaron también algunas pequeñas herramien- tas reusables, como la de exportación selectiva y la de integración de JML con NetBeans.
Se propuso un Proceso de Desarrollo que integre aquellos elementos del mé- todo de Meyer que se pudieron trasladar a Java, pero que sin dudas en muchos otros aspectos no fue desarrollado con la profundidad deseable.
El Diseño por Contratos ha probado ser, al menos en este contexto, un método útil y practicable en el contexto de la tecnología Java. Se pudieron apreciar prácticamente todas las ventajas enunciadas por Meyer, y se encontró en Java Modeling Language un lenguaje de especi cación más rico incluso que el mismo Eiel. De hecho, JML no trae más que ventajas, ya que no inter ere con el código Java y uno lo puede utilizar tanto o tan poco como lo desee. Por esto es que seguramente lo volveré a utilizar en cada oportunidad que se me presente.
Para ser un poco más aventurado, diré que el Diseño por Contratos, junto con el diseño seamless, serán dos elementos del método de Meyer que tarde o temprano serán de uso generalizado en la industria del software.11
Creo que el principal mérito de este proyecto ha sido la práctica sistemática del reuso, para ser francos aun más que el trabajo sobre el método de Meyer. En este sentido no puedo dejar de señalar, un poco propagandísticamente, lo suma- mente útiles que han resultado las herramientas desarrolladas por el proyecto NetBeans, principalmente el constructor de interfaces grá cas12y la plataforma. 10Esto signi ca modi car las fechas de las operaciones para postergarlas o adelantarlas, y
posiblemente desdoblarlas en varios pagos.
11Repitiendo una nota al pie de la sección 3.2: al día de la fecha, el Diseño por Contratos
es el request for enhancement (RFE) para Java más votado en http://bugs.sun.com/ (Bug ID 4449383: Support For 'Design by Contract', beyond a simple assertion facility).
12El Swing GUI Builder de NetBeans no tiene, todavía, ningún equivalente en Eclipse que
Para terminar, la versión actual del Simulador de Impacto Ganancial cumple con los parámetros mínimos de calidad y se ha desempeñado correctamente hasta el momento. Es un punto de partida y se encuentra abierto a una cantidad muy amplia de posibles mejoras.
Capítulo 11
Trabajos futuros
Podría escribir una in nidad de trabajos posibles que permitan avanzar en todos los aspectos de este trabajo. Los siguientes me parecen los más represen- tativos.
En cuanto a la aplicación del método de Meyer en Java:
Desarrollar un módulo para NetBeans que facilite el uso de JML.
Colaborar con el desarrollo de JML para agregar soporte a la versión 5.0 del lenguaje Java, y en particular a la genericidad.
Investigar y proponer un mecanismo de diseño seamless. En cuanto al Proceso de Desarrollo:
Utilizarlo en otro proyecto de software.
Mejorarlo. Principalmente los procesos de requerimientos, estimación y testing.
Desarrollar un Proceso de Management que permita la administración de múltiples proyectos dentro de una organización. Este Proceso puede estar orientado, por ejemplo, a la creación de un repositorio de software producido en la Facultad.
En cuanto al Simulador de Impacto Ganancial:
Implementar el diseño de los requerimientos faltantes.1
Extenderlo con lectura de datos de algún sistema ERP de uso generalizado (SAP o Tango, por ejemplo).
Extenderlo con los elementos faltantes del Modelo de Rotación del Capital. Agregar interfaz visual para la especi cación de Cambios.
Extenderlo con evaluación automática de múltiples escenarios, y con aná- lisis de impacto.
Estudiar la posibilidad de utilizar técnicas de optimización con el Modelo de Rotación del Capital.
Parte V
Apéndice A
Preproyecto de Tesis
A continuación se incluye el preproyecto de tesis tal como fue aprobado por el Honorable Consejo Directivo de la Fa.M.A.F. Consideré de interés agregarlo al informe como parte del apéndice para permitir al lector cotejar los resultados esperados con los resultados obtenidos.