RobotDocIRS |
. |
RobotDocIRS |
. |
|
Resumen El artículo intenta formalizar la máquina
RobotDocIRS, herramienta que constituye la síntesis de nuestra experiencia
en la programación de aplicaciones. RobotDocIRS es un
generador de código en plataforma Web, que aprende de acuerdo a un conjunto de
reglas de sintácticas y semánticas. La idea central de esta
herramienta interna de la compañía, es sistematizar y
complementar el ciclo metodológico
en el puente
diseño-desarrollo , con un
prototipo que cumpla con los estándares de
calidad y
estilo en
la programación de la aplicación. Así mismo, que el prototipo
represente una maqueta compleja y dinámica que aproxime al
máximo los requerimientos del cliente y pueda ser mejorada en
línea conjuntamente con el cliente En sus inicios RobotDocIRS comenzó como una aplicación generadora de código en programación modular, la cual permitía tener el prototipo básico. Su construcción se realizó a partir de la experiencia y nuestras propias librerías ( programas, funciones, scripts y objetos), utilizados a lo largo de varios años, para el desarrollo de aplicaciones. Sin embargo, en un proceso de mejoramiento empírico e investigativo, se fue descubriendo que era posible adicionar componentes y clases en cada una de las capas que forman el sistema, reemplazando el trabajo humano de un programador.
|
Abstract The article, written in Spanish, attempts to formalize the RobotDocIRS machine tool, which is the synthesis of our experience in programming applications. RobotDocIRS code generator is a Web platform that learns according to a set of syntactic and semantic rules. The thrust of this internal tool company, is to systematize and complement the methodological cycle on the bridge design-development, with a prototype that meets the standards of quality and style of application programming. Also, the prototype model represents a complex and dynamic approaches to maximize the customer's requirements and can be improved in conjunction with the Customer line. In the beginning RobotDocIRS began as a code generator application in modular programming, which have allowed the basic prototype. It was built from the experience and our own libraries (programs, functions, scripts and objects), used over several years to develop applications. However, in a process of improving empirical, investigative, it was discovered that it was possible to add components and classes in each of the layers that make up the system, replacing the human work of a programmer. |
Robot Computacional Robot es un dispositivo, que desempeña tareas automáticamente, ya sea de acuerdo a supervisión humana directa, a través de un programa predefinido o siguiendo un conjunto de reglas generales, utilizando técnicas de inteligencia artificial. Generalmente estas tareas reemplazan, asemejan o extienden el trabajo humano. Un robot debe tener como mínimo dos propiedades a saber: i) Sustituir mano de obra. RobotDocIRS RobotDocIRS es un sistema computacional que cumple las condiciones antes descritas, con el objetivo general de contribuir al Negocio del Cliente, a través del modelamiento. En otros términos, RobotDocIRS es una herramienta tecnológica para el Levantamiento de Procesos, Diseño y Rediseño Funcional.
Su forma de complementar el ciclo metodológico, se realiza construyendo en corto tiempo la 'Obra Gruesa' de una Aplicación que opera sobre IIS y SQL Server. RobotDocIRS es un maquina con capacidad de realizar funciones que requieren de inteligencia, emulando la conducta de un programador, no sólo generando código, sino que interpretando fielmente lo solicitado desde el Levantamiento de Procesos.
RobotDocIRS logra este objetivo, al configurar y construir, un prototipo orientado al cliente, mediante la generación de los los códigos de múltiples páginas ASP(Active Server Pages de Microsoft), con su navegación correspondiente, con una Base de Datos nativa sobre XML, motor de búsqueda indexado y la documentación de ayudas en línea de las páginas respectivas. Todo esto, a partir de una Capa de Insumos que contiene un Léxico, una Sintaxis y una Semántica. Para generar y editar los archivos de insumo, RobotDocIRS está dotado de una simple interfaz que facilita el trabajo y estructura los múltiples insumos de acuerdo a la sintaxis requerida. Estos insumos, son localizados en carpetas únicas, de donde son leídos e introducidos por el Robot hacia la Capa de Proceso. Es decir, una vez arriba el Insumo, se activa la orden de ejecución de RobotDocIRS y comienza el proceso automático de validación, búsqueda de analogías, mejoramiento de errores humanos, ajustes de código, ensamblaje, sincronización de objetos, asociación rutinas y scripts, mejoramiento de. etiquetas, construcción de páginas, etc.. para finalmente producir el Resultado en una carpeta especial que funciona sobre Internet, con una URL definida. Esta resultante corre sobre los servicios de Internet Information Server (IIS) tanto en Intra como en Extranet
RobotDocIRS es un intento por sintetizar la experiencia de años de DocIRS en el desarrollo de aplicaciones, permitiendo sustituir a un programador en el 80% de su trabajo, pero en forma aún más sistemática, ordenada, verificada y sin errores. La interacción que se genera entre Levantamiento y el prototipo, permite un diseño funcional robusto que asegura un manejo eficiente de los datos, eliminar la variabilidad, reducir los tiempos de ciclo, costos más bajos para el cliente y efectos positivos en el desempeño financiero de DocIRS. Herramienta Interna
Con métodos convencionales, hay un largo retraso antes de que el cliente consiga ver cualquier resultado. Así mismo el desarrollo puede durar tanto tiempo que las reglas del negocio del cliente podrían haber cambiado, lo que en la mayoría de los casos, lo obliga a intentar cambiar los requerimientos como parte del contrato. La solución DocIRS basada integramente en su experiencia, logra con un 20% de los recursos lo que convencionalmente se produce con un 80% de los recursos en la construcción de software, porque:
RobotDocIRS hace rentable el Levantamiento de Procesos porque permite:
Ahorro significativo para el Constructor
El prototipo representa un gran ahorro, particularmente para quien construye la aplicación El prototipo construido por RobotDocIRS es más que un programa de prueba. Es prácticamente la aplicación preliminar o versión beta de la aplicación requerida, pero sin las conexiones a bases de datos, sin los listados e informes que derivan de estos datos. Efectivamente, el prototipo RobotDocIRS pone a disposición de los constructores el diseño funcional convertido en sistema, con al menos el 90% de todo el código fuente de los formularios o páginas completas, las validaciones por campo, por objeto y globales, la navegación por menús y viñetas e incluso los diversos estilos del proyecto. Cuando se entrega el prototipo de RobotDocIRS, es porque ya pasó por las etapas de aprendizaje del proceso, las funcionalidades, y porque ya se descubrieron y analizaron los puntos sensibles de sistema que se desarrollará. El prototipo RobotDocIRS ahorra también un considerable tiempo al desarrollador, no sólo en términos de la comunicación, y claras especificaciones de los requerimientos, sino que especialmente le ahorra un gran número de Horas Hombres de programación, dado que ya está construida eficientemente la interfaz de presentación con la aprobación del cliente. Este hecho, lo demuestra la aplicación en desarrollo del Comité Electrónico de la Plataforma Pequeña Empresa de BancoEstado. En efecto, el proveedor seleccionado por BancoEstado para construir el modulo Comité Electrónico, la interfaz de su Entregable es casi en su totalidad, - sin cambios -,el mismo prototipo generado por RobotDocIRS. Es decir, este constructor hasta el momento, se montó 100% sobre los códigos del prototipo de RobotDocIRS aplicándole sólo la conexión a bases de datos y otros detalles de reglas de negocio que RobotDocIRS no abarca.
Ventaja RobotDocIRS permite a DocIRS adquirir una enorme ventaja , porque la competencia llega sólo hasta la etapa de Levantamiento tradicional y no llega a entregar como valor agregado, un completo prototipo (con pantallas, formularios, campos, detalles, validaciones, su correspondiente navegación y documentación completa de cada formulario o pantalla y un mapa de navegación) que funcione con rapidez y exactitud, minutos después de solicitado el cambio, haciéndolo visible en un sitio Internet exclusivo del cliente. Es decir, para que las empresas puedan competir con DocIRS, deberían alcanzar a nivelar el Entregable dentro de este ámbito, incorporando un alto numero de Horas Hombres de programadores de primer nivel. Estas varias semanas de desarrollo que deberían trabajar, a fin de lograr este nivel de producción del RoboDocIRS, tiene un impacto significativo en el precio y en los tiempos de entrega.
¿Qué entendemos por Diseño Funcional?
Prototipo: Onda Transversal del Levantamiento En efecto, el prototipo instantáneo es como una una onda transversal a todas las fases del proyecto de automatización, lo que transforma una metodología plana y lineal de documentación UML, en un método experimental que deja exactamente documentado, comunicado y especificado el sistema para los constructores (Ver página ¿Cuáles son las características que debe tener una herramienta UML?). Las múltiples versiones del prototipo que produce el RobotDocIRS, van modificando los diagramas (de Flujo de Procesos, de Actividades, de Casos de Uso, de Secuencia, de Clases) y la definición y alcances del modelo de datos, sus conclusiones e inteligencia de negocios.
En síntesis, RobotDocIRS es ideal para la construcción de maquetas y prototipos, logrando tiempos record de respuesta, para la interacción con el Cliente en la etapa del Levantamiento de Procesos. Dado que en los diferentes momentos del proceso , se van eliminando problemas que se detectan en el análisis de las pantallas y documentación, y se van agregando mejoramientos que van asegurando mayor rapidez y solidez en el producto. Satisfacer los requerimientos del cliente Según nuestra experiencia, bajo esta concepción de prototipo es más susceptible de encontrar formas de incorporación de los resultados y reglas de negocio más optimas, puesto que los usuarios participan directamente en la experiencia de análisis y diseño, evaluando y comparando ellos mismos el diseño y la información generada por el sistema. El prototipo se inicia como modelo de simulación que va evolucionando con su uso, para llegar a minimizar los defectos. En efecto, los usuarios evalúan el diseño y la información generada por el modelo inicial y proponen cambios en la medida que es utilizado, de modo que los requerimientos funcionen no solo en el papel, sino que transforma e implementa los mejoramientos en forma concreta. Es decir, el prototipo es fundamental para comprender e interpretar exacta y rápidamente los requerimientos del cliente. El equipos de DocIRS y el Cliente, trabaja en ciclos sucesivos Insumo-Resultado, hasta llegar a los límites de perfección con el mínimo de defectos observables. RobotDocIRS opera sobre capas:
Modulo-->Formulario-->Objetos -->Documentación
El insumo es preparado por los Ingenieros Industriales de DocIRS,
responsables del levantamiento de Usuarios y Proceso. Ese insumo se organiza a través de
una interfaz especial que permite construir en forma sencilla y eficiente los insumos
tales como módulos, formularios, campos asociados a cada formulario, documentación por
formulario y campo, objetos y valores introducidos en las celdas de las tablas etc... Los
archivos insumos internamente en RobotDocIRS están relacionados biyectivamente. Esta
aplicación opera remotamente sobre un VPN especial de DocIRS.
Nótese que los objetos pueden ser archivos de textos simples o con sus scripts asociados y que los parámetros a sustitur en la construcción son /1\/2\,... Por ejemplo:
Ejemplo de Resultado, es el prototipo de una plataforma completa entregada en enero 2007 para BancoEstado, cuenta con 68.000 líneas de código ASP, 1200 objetos, 70 formularios, ayuda enlínea, navegación a través de viñetas, pull-down menús y links. Esta aplicación completa, como unidad toda, RobotDocIRS la genera en forma perfecta sólo en 45 segundos.
¿Qué debemos evitar hacer con esta herramienta interna? Debemos evitar la modificación manual de las páginas generadas por RobotDocIRS. Porque estas intervenciones, posteriormente impiden generar todos los códigos, dado que el Robot genera la aplicación completa como una unidad toda (índices, rutinas, ayudas, rótulos, viñetas, menú, enlaces, etc,) cada vez que se ejecuta. Es decir, al intervenir páginas modificando y realizando arreglos manuales, implica necesariamente continuar trabajando con el método de desarrollo convencional (no más con el robot) y bajar los tiempos del ciclo, aumentar los defectos, costos y sacar al cliente de las normas y marco de la tecnología. Es decir, hacer cambios y mejoramientos en forma aislada, atenta contra la variabilidad. Este concepto de no intervención de los resultados del RobotDocIRS, ha sido difícil implantarlo con los ingenieros de la empresa responsables del Levantamiento Procesos y Diseño Funcional, dado que ellos pueden y saben desarrollar códigos (como ASP, Java, VBscript, HTML,...) y desean agregarle, - por su cuenta - detallitos y "pirotecnia" (fundamentalmente de diseño), a las páginas construidas por el RobotDocIRS. Pero, justamente la experiencia ha demostrado que haber realizado estos cambios en forma manual sobre varias páginas de la aplicación, se transformó posteriormente en un problema, que jugó en contra, especialmente en la detección de fallas a lo largo y ancho de la aplicación. (Es decir, se perdió tiempo significativo y más encima se hecho a perder la calidad del prototipo. Nótese que sólo en revisar y arreglar los problemas se gastaron más de 5 Horas Hombre, en consecuencia que RobotDocIRS demora sólo 55 segundos en hacer todo de nuevo, validado y bién).
Hoy estos ingenieros, dada la experiencia, prefieren agregar nuevos objetos y bloques, perfeccionar la versatilidad, solicitando que todas las nuevas variantes se produzcan, en lo posible, sólo desde el RobotDocIRS, dado que los Insumos que ellos mismos configuran, constituyen la materia prima de donde RobotDocIRS construye toda la aplicación como una unidad toda. Es decir, hoy en el equipo de Levantamiento de Procesos y Diseño, se está implementando creativamente la política de fortalecer RobotDocIRS. La fortaleza del RobotDocIRS es justamente que construye la aplicación con un conjunto de conocidos de objetos, en forma sistemática y ordenada. Este hecho, de configurar la aplicación con piezas o legos permite que el usuario aprenda en forma estándar y dentro de un marco determinado a realizar sus requerimientos e ideas. Este lego no es cerrado, es decir puede continuar infinitamente aumentando sus piezas simples y compuestas, y es una herramienta que permite formar usuarios (o contraparte técnica del cliente). A quienes es necesario inculcarles una medición común, normas o reglas comunes de construcción y estándares de visualización de sus requerimientos. Variabilidad Controlada La calidad del producto es un función directa de la calidad del proceso. De ahí que, es un un objetivo fundamental en el mejoramiento del resultado R, controlar y reducir la variabilidad, de forma que los procesos relacionados a RobotDocIRS sean estables, consistentes y predecibles. En nuestro caso, tanto el creador de RobotDocIRS y como su equipo, conocen con exactitud cómo cada variable del proceso afecta cada característica del prototipo, con la permanente posibilidad de intervenir y ajustar estas variables dentro del sistema, de modo que siempre el servicio de RobotDocIRS responda a las necesidades del cliente. e ---------> 0 t ---------> Min[tiempo] RobotDocIRS está diseñado bajo el supuesto que el resultado queda determinado por las condiciones bajo los cuales se realiza. Esto significa que en el proceso de construcción del producto, no existe variabilidad aleatoria, dado que el modelo es determinístico. En la gráfica se ilustra que en no más de 10 ejecuciones de RobotDocIRS, se logra el objetivo (satisfaccón del cliente, prototipo interpreta al cliente), con una desviación estándar muy pequeña. La razón es simple: la transformación que aplica RobotDocIRS depende del diseño de Insumo, y no de sus operaciones internas.
Es decir, se ingresa un conjunto finito y ordenado de variables seleccionadas desde un léxico predeterminado, según el Levantamiento de Proceso y RobotDocIRS produce exactamente lo que debe resultar según su programación. Supongamos el resultado entregado, no satisface (al propio ingeniero DocIRS o) al cliente. Entonces, implica que el resultado carece de algún objeto y/o no presenta un distribución apropiada de ellos. Esta falta puede ocurrir por una de las siguientes causas:
Las respectivas soluciones son:
Otra fuente de error de muy menor ocurrencia, que no es considerada para medir la variabilidad de este proceso, podría darse porque las validación de uno o más argumentos de un objeto, no están completamente validadas en la aplicación que prepara la Capa Insumo y/o que tampoco son capturadas y corregidas durante el Proceso. RobotDocIRS, cuenta también con un conjunto de validaciones que detecta y corrige automáticamente errores menores, tales como duplicación de variables, caracteres no aceptados para identificar objetos, ortografías, etc..). Esta fuente de error dice relación con verificar bien el objeto, antes de ser incluido en el modelo. En síntesis, el proceso es constante y la variabilidad está controlada en ambos casos.(Dentro del ámbito del contenido no del diseño) Algebra de RobotDocIRS - Léxico Sea L el conjunto numerable de n objetos que constituyen la librería de RobotDocIRS
L = {O1, O2, O3,…On}
Más específicamente L = {Xi / C(Xi) = True con i=1,2,3,…n}. Donde cada objeto Xi se define como un conjunto complejo de datos que posee estructura y fue previamente construido como parte del sistema Insumo de RobotDocIRS.
C(X): Representa las condiciones funcionales que debe cumplir cada objeto de L . Los objetos pertenecientes a L son, en general, rutinas de códigos ASP paramétricos localizados en la librería o también funciones directamente construidas, dentro de la aplicación computacional que genera el Resultado, ambas formas cumplen con una definición de nombre único, una sintaxis predefinida y estar declarados en la Lista de Objetos de RobotDocIRS. Además L cumple con las siguientes propiedades: i) fÎL ii) OjÎL => Ojc = L –{ ÈOi } con i¹j
Se define L como un conjunto que admite agregar un objeto cuando sea requerido.
L = L È {On+1}, El objeto On+1 puede ser agregado a L, siempre y cuando el objeto cumpla con la condiciones de pertenencia C(x) que exige RobotDocIRS, para constituir un objeto del conjunto L. - Estructura Insumo Ahora, se define el sistema de insumos S sobre L como una clase con estructura de arbol: S É M É F ÉO
S: Sistema o conjunto de todos los insumos de RobotDocIRS. M: Módulos o clasificaciones para los formularios. F: Formularios o páginas constituidas por objetos O: Objetos seleccionados de L son el último elemento del árbol.
Sea S= {M1, M2, M3,…,Mn1} , el conjunto formado por los módulos definidos en el Levantamiento y Diseño que se sintetizan en el Insumo robot completo, donde los Mj ¹ Mi , cuando "i¹j Mj = {Fj1, Fj2, Fj3,…,Fjn2} , es el insumo correspondiente a un modulo Mj, conformado por n2 Formularios. Donde los Fji ¹ Fjk , " i ¹k Para cada formulario Fjk Î Mj, se tiene que Fjk ={Ojk1, Ojk2, Ojk3,…, Ojkn3} es un conjunto ordenado (≤) que admite el uso del mismo objeto, pero con notación diferente en su asignación o etiqueta. El orden definido, corresponde a la secuencia de construcción y posición del objeto en el Resultado. Es decir, Fjk es el conjunto de los n3 objetos seleccionados de L, que conforman un formulario definido Fjk, perteneciente al modulo Mj del sistema S. Fjk =È Ojki . Un formulario admite la unión del mismo objeto (no confundir con L) El conjunto de los n3 objetos seleccionados de L, que constituyen un formulario están definido bajo una relación de orden. |
