Stma de Publicación de Tesinas (En Genexus)

Universidad Nacional del Nordeste
Facultad de Ciencias Exactas, Naturales y Agrimensura.

Carrera: Licenciatura en Sistemas de Información.
TRABAJO FINAL DE APLICACION
Diseño de un Sistema de Información

para la Publicación de Tesinas de Grado.
Autor: Luis Fernando Dellamea Liva
Profesora Orientadora: Mgter. Sonia I. Mariño.
Profesor Coordinador: Agr. Castor Herrmann.
Año 2010
Diseño de un Sistema de Información para la Publicación de Tesinas de Grado
Luis F. Dellamea Liva
Licenciatura en Sistemas de Información
A mi familia, por el apoyo incondicional que me ha brindado.
Página 1
PRÓLOGO
La asignatura Trabajo Final de Aplicación establece las condiciones para la elaboración

y desarrollo del plan de trabajo y los desarrollos de los Trabajos Finales de la Carrera
Licenciatura en Sistemas de Información, teniendo como objetivo completar la formación
académica y profesional de los egresados de dicha carrera.
Este informe expone el diseño y desarrollo de un Sistema de Publicación de

Trabajos Finales de Aplicación (TFA) para la mencionada asignatura.
La idea inicial del tema elegido para este trabajo ha surgido por la iniciativa personal de
aplicar y ampliar los conocimientos brindados desde la Universidad relacionados a temáticas de
desarrollo de aplicaciones Web, metodologías modernas de construcción de software, y
herramientas de desarrollo rápido de aplicaciones (RAD), especialmente las orientadas a tratar
proyectos incrementales y evolutivos.
Parte de este trabajo ha sido realizado en conjunto con el Sr. Fabián Escalante,
estudiante avanzado de la carrera, bajo la orientación de Mgter. Sonia I. Mariño; a quienes estoy
especialmente agradecido por la dedicación y paciencia empeñadas en este proyecto.
Expreso del mismo modo mi gratitud hacia aquellos docentes de esta Alta Casa de
Estudios que han puesto su mejor esfuerzo en la difícil tarea de formar un Profesional de
Sistemas.
Página 2
INDICE GENERAL
RESUMEN SINTÉTICO. 9
RESUMEN EXTENDIDO. 10
CAPÍTULO I: INTRODUCCIÓN. 13
1.1. Introducción a las Aplicaciones Web. 13

1.1.1. Características de las Aplicaciones Web. 14
1.1.2. Estructura de las aplicaciones Web. 15
1.1.3. Ingeniería Web. 15
1.2. Presentación de la Herramienta Genexus. 17

1.2.1. Desarrollo Basado en Conocimiento. 19
1.2.2. Otras características de Genexus. 21
1.2.3. Mantenimiento de Sistemas con Genexus. 22
1.2.4. El Producto Genexus. 23
1.3. Estudio de Metodologías de Desarrollo de Software. 24

1.3.1. Proceso Modularizado Unificado Y Medible. 24
1.3.1.1. Proceso Unificado de Rational. 24
1.3.1.1.1. Características del RUP. 25
1.3.1.1.2. Fases del RUP. 27
1.3.1.2 Métrica Versión 3. 30
1.3.1.2.1. Principales Procesos . 32
1.3.1.2.2. Interfaces de Métrica Versión 3. 32
1.3.1.3. Modelo de Capacidad y Madurez Integral (CMMI). 34
1.3.1.4. Proceso Modularizado, Unificado y Medible. 36
1.3.1.4.1. Características del Proceso M.U.M. 38
1.3.1.4.2. Extensiones Genexus. 40
1.3.2. Programación Extrema con Genexus. 40
1.3.2.1. Metodologías Ágiles de Desarrollo de Software . 40
1.3.2.1.1. Manifiesto Ágil. 41
1.3.2.1.2. Valores del manifiesto ágil. 41
1.3.2.1.3. Principios del manifiesto ágil. 42
Página 3
1.3.2.1.4. Consideraciones sobre Metodologías Ágiles . 44

1.3.2.2. Programación Extrema. 44
1.3.2.2.1. Prácticas XP. 45
1.3.2.2.2. Valores de XP. 47
1.3.2.2.3. Roles XP. 48
1.3.2.2.4. Las Historias de Usuario. 49
1.3.2.2.5. Proceso XP. 49
1.3.2.3. GXP - Programación Extrema con Genexus. 50
1.3.3. Metodología Genexus. 51
1.3.3.1. Actividades a seguir para el desarrollo de aplicaciones. 52
1.3.3.1.1. Actividad de Comunicación y Planeación. 52
1.3.3.1.2. Actividad de modelado. 53
1.3.3.1.3. Actividad de Construcción o Producción. 56
1.3.3.1.4. Actividad de despliegue. 57
1.3.3.2. Metodologías Tradicionales vs. Metodología Genexus. 57
1.3.4. Elección de la Metodología. 60
CAPÍTULO II: METODOLOGÍA. 62
2.1. Actividad de Comunicación y Planeación. 62

2.1.1. Definir el objetivo. 62
2.1.2. Definir el equipo de trabajo. 62
2.1.3. Obtener una imagen global. 63
2.1.4. Definir el alcance de la aplicación. 63
2.1.5. Definir los perfiles de usuario y su jerarquía. 64
2.2-Actividad de estudio de las tecnologías. 65
2.3-Actividad de Modelado. 66
2.3.1. Fase de Análisis. 66
2.3.1.1. Construcción del diagrama de casos de uso. 66
2.3.1.2. Construcción de los diagramas de comunicación. 68
2.3.1.3. Construcción de los diagramas de secuencia. 72
2.3.2. Fase de Diseño. 74
2.3.2.1. Diseño de Transacciones. 74
2.3.2.2. Diseño de Web Panels. 78
Página 4
2.4. Actividad de Construcción o Producción. 82

2.4.1. Codificación 82
2.4.2. Prototipado 83
2.4.3. Validación de la aplicación con datos reales 83
2.4.4. Generación de la Aplicación 83
CAPITULO III: HERRAMIENTA UTILIZADA. 85
3.1. Transacciones. 85
3.2. Web Panels. 86
3.3. Capacidad de Prototipado. 87
CAPITULO IV: UN SISTEMA DE PUBLICACIÓN DE TESINAS DE GRADO. 89
4.1. Utilización por parte del Usuario General. 89
4.2. Utilización por parte del Consultor de TFA. 94
CAPITULO V: CONCLUSIONES. 101
REFERENCIAS BIBLIOGRÁFICAS. 103
Página 5
INDICE DE FIGURAS
Figura 1: Forma de trabajo de Genexus. 18

Figura 2: Obtención del conocimiento en Genexus. 20
Figura 3: Énfasis relativo en las distintas disciplinas según la fase en RUP. 25
Figura 4: Fases, iteraciones y disciplinas en RUP. 27
Figura 5: esquema de la metodología Métrica versión 3. 31
Figura 6: Los niveles de CMMI. 36
Figura 7: Modelo de Proceso MUM. 38
Figura 8: Fases, Iteraciones y duración en semanas en MUM. 40
Figura 9: Relación entre las prácticas en XP. 46
Figura 10: Interrelación entre etapas: diseño - prototipado y diseño – producción. 56
Figura 11: Comparación Metodología Genexus vs. Metodologías tradicionales. 59
Figura 12: Actores (perfiles de usuario) considerados en el Sistema de Administración
de la Asignatura. 64
Figura 13: Diagrama de casos de uso del Sistema de Administración de la Asignatura
en su conjunto. 66
Figura 14: Diagrama de Casos de Uso del Sistema de Publicación en particular. 67
Figura 15: Diagrama de comunicación Número 1 (interacción con el Usuario General). 68
Figura 16: Diagrama de comunicación Número 2 (interacción con el Usuario General). 69
Figura 17: Diagrama de comunicación Número 3 (interacción con el Consultor de TFA). 70
Figura 18: Diagrama de comunicación Número 4 (interacción con el Consultor de TFA). 70
Figura 19: Diagrama de secuencia Número 1 (interacción con el Usuario General). 71
Figura 20: Diagrama de secuencia Número 2 (interacción con el Usuario General). 72
Figura 21: Diagrama de secuencia Número 3 (interacción con el Consultor de TFA). 72
Figura 22: Diagrama de secuencia Número 4 (interacción con el Consultor de TFA). 73
Figura 23: Estructura de la transacción Profesional. 74
Figura 24: Definiciones de dominios utilizados. 75
Figura 25: Web form de la transacción Profesional. 75
Figura 26: Estructura de la transacción Proyecto. 76
Figura 27: Porción del modelo de datos que muestra las tablas creadas a partir de las
transacciones Profesional y Proyecto. 77
Figura 28: Modelo de datos completo. 79
Página 6
Figura 29: Vista en tiempo de diseño del Web Panel “BuscarTrabajosFinales”. 80

Figura 30: Vista en tiempo de diseño del Web Panel “BuscarPorOrientadores”. 81
Figura 31: Configuración de entornos en Genexus. 87
Figura 32: Interfaz principal de la Aplicación. 89
Figura 33: Interfaz de búsqueda por distintos criterios para el Usuario General. 90
Figura 34: Interfaz de búsqueda por orientadores, para el Usuario General. 91
Figura 35: Interfaz de Información del TFA para el Usuario General. 92
Figura 36: Interfaz de Información de los orientadores del TFA para el Usuario General. 93
Figura 37: Interfaz principal de la Aplicación al momento de ingresar Usuario y Contraseña.94
Figura 38: Interfaz principal de la Aplicación con opciones del Modo Docente habilitadas. 95
Figura 39: Interfaz de búsqueda por distintos criterios para el Consultor de TFA. 96
Figura 40: Interfaz de búsqueda por orientadores, para el Consultor de TFA. 97
Figura 41: Interfaz de Información del TFA para el Consultor de TFA. 98
Figura 42: Interfaz de Información de los orientadores, coordinador y jurados del TFA
para el Consultor de TFA. 99
Página 7
INDICE DE TABLAS
Tabla 1: Tecnologías soportadas por Genexus. 19

Tabla 2: Comparación metodologías ágiles y metodologías tradicionales. 43
Tabla 3: Correspondencia entre transacciones y tablas del modelo de datos. 78
Página 8
RESUMEN SINTETICO
Se expone el diseño y desarrollo de un Sistema de Publicación de Trabajos Finales

de Aplicación (TFA) para la asignatura homónima, dictada en la carrera Licenciatura en
Sistemas de Información de la Facultad de Ciencias Exactas y Naturales de la Universidad
Nacional del Nordeste.
El sistema de publicación fue concebido como una aplicación web, por lo que se
presenta una breve introducción a dicho tema. Asimismo, se incluye una síntesis de varias
metodologías que han sido estudiadas con el propósito de compararlas y elegir la más adecuada
para el desarrollo, como ser Proceso Unificado, Modularizado y Medible (basado en el Proceso
Unificado de Rational), Programación Extrema y la Metodología Genexus. Esta última, que ha
sido la empleada, fue adaptada tomando conceptos y diagramas de otros procesos, para lograr
un análisis más detallado del sistema.
La aplicación ha sido construida con el generador de código Genexus. Se mencionan

en este trabajo los conceptos fundamentales de uso de esta herramienta basada en
conocimiento.
Genexus ha resultado apto para la construcción del sistema, permitiendo lograr una
aplicación que cuenta con las funcionalidades necesarias, así como con una interfaz gráfica
agradable. Las interfaces principales y el modo de funcionamiento de la aplicación se exponen
en el último capítulo del trabajo.
Página 9
RESUMEN EXTENDIDO
En el presente informe se expone el diseño y desarrollo de un Sistema de Publicación

de Trabajos Finales de Aplicación (TFA) para la asignatura homónima, dictada en la carrera
Licenciatura en Sistemas de Información de la Facultad de Ciencias Exactas y Naturales de la
Universidad Nacional del Nordeste. Asimismo se presenta parte del análisis del Sistema de
Gestión Integral de dicha asignatura.
El sistema fue concebido como una aplicación web. Se conoce como Aplicaciones
Web (o WebApps) a aquellos programas que los usuarios pueden utilizar mediante un
navegador de Internet. Las aplicaciones web son populares debido a la ubicuidad de los
navegadores y su conveniencia de utilizarlo como “cliente ligero”. La capacidad de implementar
y mantener éstas aplicaciones web sin instalar software particular en cada computadora es otra
razón de su popularidad.
Para la construcción de este sistema se han tenido en cuenta los conceptos de la

Ingeniería Web, definida como la aplicación de sólidos principios científicos, y enfoques
disciplinados y sistemáticos para el desarrollo, despliegue y mantenimiento exitosos de sistemas
y aplicaciones de alta calidad basados en Web.
El sistema ha sido construido con la herramienta Genexus, especializada en desarrollo

rápido de aplicaciones. Puede considerarse a Genexus como un generador automático de
código para desarrollos incrementales. Esta herramienta tiene como objetivo encargarse de
todos los aspectos susceptibles de automatización, para permitir que el desarrollador centre su
atención en los procesos fundamentales del negocio. Una de las características más destacables
de este producto es la facilidad que posee para generar prototipos. Genexus puede
considerarse como una herramienta de administración del conocimiento, ya que permite
trabajar con el mismo de manera independiente a una plataforma en particular. Éste es el
producto principal de la compañía uruguaya Artech, y soporta buena parte de las tecnologías
más importantes del mercado.
Se han estudiado varias metodologías con el propósito de compararlas y elegir la más

adecuada para el desarrollo: Proceso Unificado, Modularizado y Medible (basado en el Proceso
Unificado de Rational), Programación Extrema y la Metodología Genexus.
La primer metodología investigada, el Proceso Modularizado, Unificado y Medible

(MUM), toma como bases el Proceso Unificado de Rational (RUP), Métrica versión 3, el
Página 10
Modelo de Capacidad y Madurez Integral (CMMI). MUM considera los conceptos y las
recomendaciones del proceso RUP, de la metodología Métrica versión 3 y del modelo CMMI
para mejorar la calidad del proceso en cuanto a las actividades que conforman el mismo.
Incorpora métricas para evaluar las distintas actividades del proceso particularmente, las
vinculadas a Requerimientos, Verificación, Implementación, Implantación y Administración.
MUM cuenta con una base común, y extensiones para tecnologías particulares (para desarrollos
OO y desarrollos con Genexus), este es un proceso que hace énfasis en la satisfacción del
cliente.
La segunda metodología revisada consiste en Programación Extrema adaptada a

desarrollos con Genexus. Programación Extrema es el más destacado de los Procesos Ágiles
de Desarrollo de Software. Estos proponen una fuerte colaboración del cliente en el proceso
de desarrollo, promueven iteraciones a lo largo de todo el ciclo de vida del proyecto. Los
métodos ágiles enfatizan las comunicaciones cara a cara por sobre la documentación y los
modelos, dando prioridad al individuo y las interacciones del equipo de desarrollo por encima
del proceso y las herramientas. Además promueven una planificación flexible, para poder
brindar una respuesta rápida al cambio. Programación Extrema incluye: un conjunto de
prácticas de trabajo recomendadas, los valores a ser defendidos por el equipo de trabajo, los
roles específicos de los miembros del equipo, y un proceso con acciones detalladas.
La Metodología Genexus, propuesta por los creadores de la herramienta, describe las

principales fases a ser llevadas a cabo, teniendo en cuenta los conceptos particulares de
Genexus. Esta metodología ha sido elegida para el desarrollo del sistema, y fue enriquecida con
el modelo de proceso formulado por Pressman. Se ha dividido así en cinco actividades:
comunicación y planeación, estudio de las tecnologías, modelado, construcción y
despliegue, cada una de ellas compuesta por una o más acciones o fases.
La actividad de comunicación y planeación incluye definir el objetivo del sistema,

armar el equipo humano de trabajo, obtener una imagen global del sistema en su contexto,
definir los requerimientos a ser cumplidos por la aplicación, y establecer los actores
construyendo una jerarquía de acuerdo a sus privilegios de uso. El objetivo definido es permitir
la publicación en la Web de los resúmenes sintéticos de los Trabajos Finales de la Carrera
Licenciatura en Sistemas de Información. El equipo de trabajo del sistema de gestión integral
está compuesto por dos estudiantes avanzados de la carrera, uno de ellos es el autor del
presente trabajo, y los docentes de la asignatura. Las funcionalidades principales del sistema
Página 11
de publicación son: posibilitar la divulgación de los resúmenes sintéticos de los Trabajos Finales
de la carrera, presentar información general de los TFA, alumnos, docentes orientadores, etc. y
almacenar estadísticas de consultas de los trabajos. Los actores del sistema de gestión integral
son: alumno, usuario general, y usuario administrativo, cuyo ingreso se valida mediante una
contraseña, y a partir del cual se derivan 7 subcategorías con distintos permisos de acceso. De
los mencionados, el usuario general, el administrador y el consultor de TFA interactúan con el
sistema de publicación.
La actividad de estudio de las tecnologías incluye la búsqueda de material técnico

sobre la herramienta, así como un proceso de aprendizaje desde lo básico, ya que no se tenía
conocimientos previos.
La actividad de modelado incluye las fases de Análisis, Diseño y Prototipado. En la

primera se construyen representaciones UML, específicamente diagramas de casos de uso (para
el sistema integral y para el sistema de publicación), diagramas de colaboración y de secuencia.
La fase de Diseño consiste en el diseño de transacciones (objeto fundamental de Genexus a
partir del cual infiere las tablas del modelo relacional) y el diseño de Web Panels (objetos que
permiten realizar consultas interactivas a la base de datos y cuentan con una interfaz flexible).
La fase de Prototipado permite la prueba de la aplicación en un entorno determinado, sin exigir
esfuerzo adicional al desarrollador.
Una vez corregidos los errores del prototipo se comienza la actividad de

construcción, que consiste en generar la aplicación para el entorno de producción establecido.
En el último capítulo se exponen las características principales de la aplicación

desarrollada, presentando sus interfaces, y el modo de funcionamiento. Se muestran las
interfaces correspondientes al Usuario General, y las utilizadas por el Consultor de TFA.
Como conclusión se puede mencionar que Genexus ha resultado apto para la

construcción del sistema, permitiendo lograr una aplicación que cuenta con las funcionalidades
necesarias, así como con una interfaz gráfica agradable.
Página 12
CAPÍTULO I:
INTRODUCCIÓN
En el marco del proyecto de la cátedra Trabajos Finales de Aplicación (TFA) de la

carrera Licenciatura en Sistemas de Información de la Facultad de Ciencias Exactas y Naturales
de la Universidad Nacional del Nordeste (UNNE), se presenta una de sus líneas de trabajo
propuestas por Mariño et ál. en [MHV10]. Ésta consintió en el diseño, desarrollo e
implementación del Sistema de Publicación de Trabajos Finales de Aplicación. Asimismo
se expone parte del análisis del Sistema de Gestión Integral de dicha asignatura. Cabe aclarar
que éste fue concebido desde el primer momento como una aplicación web, por lo que se trata
una breve introducción a dicho tema en este capítulo. Asimismo, se incluyen una síntesis de
varias metodologías que han sido estudiadas con el propósito de compararlas y elegir la más
adecuada para el desarrollo. La metodología seleccionada además ha sido adaptada, tomando
conceptos y diagramas de otros procesos, para lograr un análisis más detallado del sistema.
También se presenta una breve descripción de la herramienta utilizada, así como de los
principales conceptos que intervienen en su utilización.
1.1. INTRODUCCIÓN A LAS APLICACIONES WEB
Se conoce como Aplicaciones Web (o WebApps) a aquellas aplicaciones que los

usuarios pueden utilizar mediante un navegador de Internet. Ejemplos muy conocidos de
aplicaciones web incluyen el webmail, los sitios de venta y subastas por Internet, las wikis, etc.
Las aplicaciones web son populares debido a la ubicuidad de los navegadores y su

conveniencia de utilizarlo como “cliente ligero”. La capacidad de implementar y mantener éstas
aplicaciones web sin instalar software particular en cada computadora es otra razón de su
popularidad. Un motivo más, es el soporte inherente para compatibilidad entre plataformas, ya
que la aplicación se podrá ejecutar en cualquier configuración de hardware y software siempre
que se cuente con un navegador web que pueda interpretar el código en el lenguaje o lenguajes
en los que esté construido el sistema.
Las WebApps generan dinámicamente y a petición, páginas en un formato estándar,

como HTML, soportados por los navegadores web. Se utilizan lenguajes interpretados en el
Página 13
lado del cliente, como JavaScript, Flash, etc., para añadir elementos dinámicos a la interfaz de
usuario y permitir una experiencia interactiva. Es tarea del navegador interpretar y mostrar cada
página, además de permitir el ingreso de datos y órdenes por parte del usuario.
Como desventaja, este tipo de aplicaciones suelen tener funcionalidades más reducidas
que las de escritorio, que se ejecutan localmente sobre el sistema operativo. Gracias a la
aparición de nuevas tecnologías la brecha es cada vez más pequeña, aunque surge la necesidad
del agregado de complementos (plug-ins) al navegador para ejecutar estas características
avanzadas. Otro cuestionamiento reside en que la disponibilidad de la WebApp frecuentemente
depende de terceros, por ejemplo del proveedor del servicio de Internet.
1.1.1. Características de las Aplicaciones Web
En la mayoría de las WebApps se encuentran las siguientes características, si bien

algunas de éstas pueden ser halladas en otros tipos de aplicaciones [P05]:
Concurrencia: el número de usuarios que acceden al mismo tiempo a la aplicación

puede ser significativamente grande, lo que puede llevar a dificultades importantes
al momento de predecir la carga del sistema.
Desempeño: el usuario puede ser muy exigente en cuanto a esta característica en

una aplicación web, ya que si no la cumple, puede buscar la información o
funcionalidad en otro sitio similar.
Diseño estético: se puede considerar a las aplicaciones web como una mezcla entre
publicación impresa y desarrollo de software, por tal motivo cobra vital importancia
el diseño gráfico de la misma. Esta consideración es aún más relevante para sistemas
en los que el marketing constituye su objetivo principal.
Disponibilidad: al estar disponible al mundo entero, no existen horarios en los que

la aplicación pueda considerarse como no utilizada. Esta característica debe ser
particularmente tenida en cuenta al planear el mantenimiento de los sistemas.
Orientación al multimedia: una gran parte de las aplicaciones deben soportar

distintos tipos de información, como gráficos, texto, audio y video.
Página 14
Evolución continua: en numerosas WebApps el contenido se actualiza de manera

muy frecuente. Además la propia aplicación deberá evolucionar más rápidamente
que una aplicación tradicional, ya que los requerimientos serán más cambiantes.
Seguridad: por ser accesibles a través de una red, las aplicaciones web requieren de
fuertes medidas de seguridad tanto a nivel de la aplicación, como a lo largo de la
infraestructura.
1.1.2. Estructura de las aplicaciones web
Las aplicaciones web generalmente están conformadas por varios niveles o capas
lógicas, donde cada uno de ellos tiene asignada una función específica.
La estructura más utilizada es la de tres capas, las que se conocen como capa de
presentación, aplicación y almacenamiento. El navegador web constituye el primer nivel
(presentación), un servidor web capaz de soportar alguna tecnología dinámica de contenidos
(ASP, PHP, Ruby) es el nivel intermedio (lógica de la aplicación) y un gestor de base de datos
conforma el nivel de almacenamiento. En una interacción típica, el navegador envía peticiones a
la capa intermedia (servidor web), ésta solicita consultas y actualizaciones en la base de datos
(tercera capa), y construye una interfaz como respuesta a la solicitud del navegador.
1.1.3. Ingeniería Web
En Pressmann [P05] se define a la Ingeniería Web (IWeb) como la aplicación de

“sólidos principios científicos, y enfoques disciplinados y sistemáticos para el desarrollo,
despliegue y mantenimiento exitosos de sistemas y aplicaciones basados en Web de alta
calidad”.
Los grandes cambios que ha presentado la web en años recientes ha impuesto la

necesidad de utilizar herramientas y técnicas de la ingeniería de software para la construcción de
sitios web. Sin embargo, el desarrollo de aplicaciones Web posee características que lo hacen
diferente del desarrollo de software tradicional, lo que lleva a la IWeb a incluir nuevos
enfoques, herramientas y técnicas para cubrir dichos requisitos especiales, distinguiéndola de la
ingeniería de software tradicional.
Página 15
Además, la Ingeniería Web requiere contribuciones de áreas muy diferentes, como ser:
arquitectura de la información, ingeniería de requisitos, diseño gráfico, usabilidad, ingeniería de
software, ingeniería de datos, gestión de proyectos, entre otras.
Página 16
1.2. PRESENTACIÓN DE LA HERRAMIENTA GENEXUS

Genexus es una herramienta para desarrollo rápido de aplicaciones. Su objetivo es
ayudar a los analistas a implementar aplicaciones en el menor tiempo y con la mejor calidad
posible. En otras palabras puede decirse que Genexus es un generador automático de código.
Una de las características más destacables de este producto es la facilidad que posee
para generar un prototipo de la aplicación. El uso de prototipos asegura que la interpretación
de los requisitos del usuario haya sido correcta por parte de los analistas, al exhibirle formatos
de pantallas, informes, etc. Genexus va un paso más allá con este paradigma, ya que el
prototipo es una aplicación funcionalmente equivalente al producto final, hasta en los mínimos
detalles.
En Genexus, la diferencia entre prototipado y producción es que la primera se hace

necesariamente en un ambiente de computador personal, mientras que la producción se realiza
en el ambiente objeto. El diseño y el prototipado se realiza sobre sistemas Windows (NT, 2000,
XP). Cuando el prototipo es aceptado se procede a la generación de la base de datos y de los
programas de aplicación automáticamente, para el entorno de producción.
En el proceso de desarrollo de software existen tareas que son susceptibles de ser

automatizadas, esto es, realizadas por computadora, y otras en las que indefectiblemente deberá
actuar un profesional. Genexus trata de encargarse del primer tipo de tareas de la manera más
completa, para que el profesional pueda poner toda su atención en las funciones en las que es
irremplazable. Ejemplo de tareas no automatizables son la educción de requisitos, el análisis y el
diseño. Entre las tareas automatizables encontramos la implementación, la generación y
mantenimiento de la base de datos y de los programas de aplicación ([AC08] y [AC99]).
Dentro de la organización no existe una única visión de los datos necesarios, al

contrario, cada participante tendrá conocimiento de los datos con los que trabaja según la
función y el nivel que ocupa dentro de la organización. Genexus considera esta realidad y
permite representar las distintas visiones de datos de los usuarios.
Es decir, ésta es una herramienta que parte de las “visiones de los datos”, captura su
conocimiento y lo sistematiza en una base de conocimiento (Knowledge Base o KB). A partir
de esta base es capaz de diseñar, generar y mantener de manera totalmente automática la
estructura de la base de datos y los programas de aplicación (ver Figura 1). En este repositorio
se mantienen las especificaciones de diseño de manera abstracta, o sea que no depende del
Página 17
ambiente en el que se implementará el sistema, lo que permite que a partir del mismo
repositorio se puedan generar aplicaciones funcionalmente equivalentes, para ser ejecutadas en
diferentes plataformas.
Figura 1: Forma de trabajo de Genexus (Fuente: [GJ07]).
No sólo es posible desarrollar una aplicación que se ejecute sobre distintas plataformas.
Además existe la posibilidad de dividir una aplicación de manera tal que cada parte pueda ser
ejecutada en una plataforma diferente, generándose el código en el lenguaje elegido para cada
una.
Genexus soporta actualmente buena parte de los lenguajes de programación,

plataformas de ejecución y gestores de bases de datos más reconocidos del mercado. En la
Tabla 1 se mencionan las tecnologías soportadas por esta herramienta.
Página 18
Tabla 1: Tecnologías soportadas por Genexus (Fuente: [AC08])
Plataformas de ejecución:
Java, Microsoft .NET, Microsoft .NET Compact Framework
Sistemas Operativos:
IBM OS/400, LINUX, UNIX, Windows NT/2000/2003 Server,

Plataformas
Windows NT/2000/XP/CE/Vista/7
Internet:
Java, Ruby, ASP.NET, Visual Basic (ASP), C/SQL, HTML, Web

Services
IBM DB2 for iSeries y UDB, Informix, Microsoft SQL Server,

Bases de Datos
MySQL, Oracle y PostgreSQL.
Lenguajes JAVA, C#, COBOL, RPG, Visual Basic.
Servidores Web Microsoft IIS, Apache, WebSphere, etc.
Múltiples Arquitecturas de múltiples capas, basadas en web, Cliente/Servidor,

Arquitecturas centralizadas (iSeries)
1.2.1. Desarrollo Basado en Conocimiento
“¿Cuál es hoy el objetivo de Genexus? El objetivo de Genexus es conseguir un muy

buen tratamiento automático del conocimiento de los sistemas de negocios”. [GJ07]
Para explicar este concepto primeramente restringiremos la definición de conocimiento

a aquel que cumple con las siguientes condiciones [AC08]:
Es riguroso
Es representable de forma objetiva
Es operable por computadora.
Como ya se ha mencionado, la mayoría de los usuarios no conoce completamente los

datos, sin embargo, cada uno conoce muy bien las visiones de los datos que utiliza
Página 19
cotidianamente. Estas visiones pueden ser de distinto tipo: pantallas, flujos de procesos,
listados, etc. y componen el aspecto exterior de la aplicación. Es la base de conocimiento la
encargada de almacenar estas visiones. También es en la KB donde se representan las reglas del
negocio.
A partir de esta base de conocimiento se obtendrá la estructura de la base de datos,

construida en tercera forma normal, y los programas de aplicación.
Está demostrado que, dado un conjunto de visiones de datos de los usuarios, existe
siempre una base de datos mínima que las satisface, la cual, además es única. Esta parte del
proceso es automatizable porque es básicamente un problema lógico/matemático. La forma
general de trabajo en Genexus se observa en la Figura 2.
Figura 2: Obtención del conocimiento en Genexus. (Fuente: EJ01])
La base de conocimiento almacena el conocimiento de manera pura y abstracta (no está

condicionado por ningún lenguaje de programación, ni tampoco por ningún gestor de base de
datos). Esto permite:
Construir automáticamente la base de datos
Página 20
Producir de manera automática los prototipos de la aplicación.
Generar automáticamente los programas de aplicación.
Cuando se producen cambios en las visiones de los usuarios será posible:
Determinar el impacto de los cambios sobre los datos y procesos, para evaluar la
conveniencia de aplicarlos.
Generar los programas necesarios para convertir los datos a la nueva representación
en la base de datos.
Generar los programas de aplicación con las modificaciones impuestas.
Generar código más eficiente, para los programas que no han sido modificados.
Genexus trabaja con conocimiento puro, lo que permite: generar programas, permitir la
interpretación de ese conocimiento por los seres humanos (minimizando la necesidad de
documentación adicional rigurosa), y operar automáticamente con ese conocimiento. La
manera de trabajar de Genexus permite la administración de ese conocimiento, de forma
independiente de cuestiones físicas, posibilitando integrarlo con otras fuentes, difundirlo
otorgando licencias a terceros para que lo integren en sus aplicaciones, etc. Es decir, se hace
posible el “negocio del conocimiento”. Por estas razones, Genexus puede describirse como
una herramienta de administración del conocimiento en sistemas de negocios.
Este manejo abstracto del conocimiento brinda la independencia de la plataforma. Es

importante hacer notar que esta consideración se aplica no sólo a las plataformas conocidas en
la actualidad, sino también a aquellas futuras. El conocimiento plasmado en la KB será
reutilizado al crearse nuevos generadores para futuras tecnologías. Esto puede ser visto como
una gran ventaja por parte de las empresas, ante los cambios vertiginosos que afectan al medio
informático.
1.2.2. Otras características de Genexus
Además de las presentadas, se pueden mencionar las siguientes características del

producto:
Para el desarrollo de una aplicación, Genexus cuenta con un número importante de

objetos con funciones específicas. La descripción de cada tipo de objeto es
independiente de los demás, por lo que la modificación en uno de ellos no
Página 21
provocará necesariamente cambios en el resto. Esta peculiaridad se conoce como

ortogonalidad de las descripciones.
El diseño de la base de datos es siempre óptimo (se mantiene en tercera forma

normal).
Cuando surgen cambios, no se modifican los programas. Se generan otros nuevos,

“sin remiendos”, que los sustituyen.
Lenguajes de alto nivel para la utilización de las funcionalidades de los objetos. En

estos lenguajes las descripciones de los procesos se hacen sin referirse a las tablas
involucradas. Así se evita la necesidad de modificar el código ante cambios en el
diseño de tablas en la base de datos.
Fácil mantenimiento. Al realizar cambios, la compilación de los nuevos programas y

la reorganización de la base de datos (si fuese necesaria) se harán de forma 100%
automática.
El entorno de producción no se encuentra ocupado durante el proceso de

desarrollo, ya que éste se realiza en PC.
Simplicidad para el analista. Genexus utiliza recursos avanzados de Inteligencia

Artificial para facilitar el trabajo del analista y del usuario.
1.2.3. Mantenimiento de Sistemas con Genexus
Según Artech [AC08], el mantenimiento de las aplicaciones desarrolladas con Genexus

es 100% automático. Esta afirmación comercial puede resultar confusa, por lo que se harán
algunas aclaraciones. Por supuesto que el mantenimiento correctivo (solucionar desperfectos
encontrados durante la ejecución del programa), adaptativo (incluir modificaciones debido a
cambios en los requerimientos que se imponen a la aplicación) y perfectivo (cambios referidos a
mejoras del sistema) siguen requiriendo de la intervención del profesional de sistemas. Pero
estas modificaciones se realizan en el IDE (Integrated Development Environment o Entorno
de Desarrollo Integrado) de Genexus solamente, es decir, las consecuencias de estos cambios
sobre la base de datos y los programas de aplicación son tratadas automáticamente por la
herramienta, generando aplicaciones de reemplazo, además de las necesarias para modificar la
base de datos.
Página 22
Los cambios generalmente afectarán a los programas y/o a la base de datos del sistema.
En estas situaciones se realizará un análisis de impacto por parte de Genexus para ambos
aspectos, presentando en cada caso un informe sobre cuales programas deberán ser
regenerados en el primer caso, o sobre la manera en la que se realizará la reorganización de la
base de datos en el segundo caso, así como posibles problemas de conversión (inconsistencias
de los datos ya cargados con el nuevo diseño o las nuevas reglas). Con esta información, el
analista decide si sigue adelante o no.
En caso de aceptarse las modificaciones a la base de datos, se generan automáticamente

los programas para hacer la conversión de estructura y de contenido (datos ya cargados) de la
antigua a la nueva base de datos. Los programas de conversión generados se ejecutan
finalmente en el ambiente de producción. También se generan los nuevos programas de
aplicación (no son modificaciones de los programas existentes).
1.2.4. El Producto Genexus
Genexus es el producto principal de la compañía uruguaya Artech. Es comercializado

en más de 30 países, incluyendo la mayor parte de Latinoamérica y el Caribe, Estados Unidos,
países de Europa occidental como España, Italia, Francia y Portugal y los mercados chino y
japonés. Cuenta con más de 50.000 licencias vendidas en todo el mundo.
A mediados de los 80, sus creadores se proponen la construcción de una herramienta que
pueda generar de forma automática el diseño de una base de datos en tercera forma normal a
partir de las visiones de los distintos usuarios. La versión 1.0 del producto fue publicada en
febrero de 1989. La versión a la que se refiere específicamente este informe en la especificación
teórica, es Genexus X (versión 10) Evolution 1. Para el desarrollo de la aplicación se utiliza la
versión de prueba (Genexus X Evolution 1 Trial) la cual está restringida en cuanto al generador
que utiliza (sólo soporta Microsoft .NET) y al DBMS1 (Microsoft SQL Server) y permite crear
un máximo de 90 atributos y 140 objetos.
1 DBMS significa en español Sistema de Administración de Bases de Datos.
Página 23
1.3. ESTUDIO DE METODOLOGÍAS DE DESARROLLO DE

SOFTWARE
En esta sección, se sintetizan las metodologías más utilizadas para el desarrollo de

sistemas de información con Genexus. Primeramente se aborda el Proceso Modularizado,
Unificado y Medible, en segundo lugar se expone una versión de la metodología ágil
Programación Extrema adaptada para Genexus, y finalmente la metodología Genexus, diseñada
y propuesta por los creadores de la herramienta.
Todos estos procesos son válidos y han sido probados en desarrollos reales, pero
presentan diferencias que los hacen convenientes para uno u otro tipo de proyecto. La
intención es estudiarlos, sopesando sus ventajas e inconvenientes, para luego decidir cuál será
utilizado en el desarrollo del sistema.
1.3.1. PROCESO MODULARIZADO UNIFICADO Y MEDIBLE
Se presenta el Proceso Modularizado, Unificado y Medible (MUM) realizado por el

Grupo de Ingeniería de Software (Gris) de la carrera Ingeniería en Computación de la Facultad
de Ingeniería de la Universidad de la República Oriental del Uruguay [PB06].
Este proceso toma como base el Proceso Unificado de Rational (RUP), Métrica versión
3, el Modelo de Capacidad y Madurez Integral (CMMI); por lo que previamente se da una
introducción a cada uno de estos temas. Además, MUM se encuentra basado en el Proyecto
Factorizado (también llamado Factor) creado por el mismo grupo en el año 2004 [PIS07].
1.3.1.1. Proceso Unificado de Rational
El Proceso Unificado de Rational (RUP) [P05][T02][PB06] es un modelo de proceso de

desarrollo de software2 que fue creado en 1998 por J. Rambaugh, G. Booch y I. Jacobson. RUP
abarca disciplinas (modelado del negocio, requerimientos, análisis y diseño, codificación,
prueba, e instalación), disciplinas de soporte (administración de configuración y cambios,
2 En Ciencias de la Información un modelo de proceso es un conjunto de actividades necesarias para

transformar los requisitos del usuario en un sistema software.
Página 24
administración del proyecto y ambiente) y fases (inicio o factibilidad, elaboración, construcción

y transición). En cada fase, las disciplinas se ejecutan con mayor o menor énfasis (Ver Figura 3).
Figura 3: Énfasis relativo en las distintas disciplinas según la fase en RUP. (Fuente: [BL04])
RUP es un marco genérico que puede especializarse para una variedad de tipos de
sistemas, diferentes áreas de aplicación, tipos de organizaciones, niveles de aptitud y diferentes
tamaños de proyectos. El RUP es esencialmente iterativo e incremental y en donde los
artefactos del proceso de desarrollo se van refinando en el tiempo. Además está dirigido por
casos de uso, y centrado en la arquitectura.
1.3.1.1.1. Características del RUP
Dirigido por casos de uso: un caso de uso es un fragmento de funcionalidad del

sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los
requerimientos funcionales del sistema.
Los casos de uso también guían el proceso de desarrollo (diseño, implementación, y

prueba). Basándose en éstos, los desarrolladores crean una serie de modelos de diseño e
Página 25
implementación que llevan a cabo los casos de uso. De este modo no sólo sirven para iniciar el
proceso de desarrollo sino que le proporcionan un hilo conductor, ya que se avanza a través de
una serie de flujos de trabajo que parten de los casos de uso.
Centrado en la arquitectura: arquitectura se define como el conjunto de decisiones

significativas acerca de la organización de un sistema software, la selección de los elementos
estructurales a partir de los cuales se compone el sistema, las interfaces entre ellos, su
comportamiento, sus colaboraciones, y su composición.
La arquitectura de un sistema software se describe mediante diferentes vistas del sistema

en construcción. El concepto de arquitectura software incluye los aspectos estáticos y
dinámicos más significativos del sistema.
Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso
deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el desarrollo de todos
los casos de uso requeridos, actualmente y a futuro.
Iterativo e Incremental: para hacer más manejable el proyecto se recomienda dividirlo

en ciclos. Para cada ciclo se establecen fases de referencia. El RUP divide el proceso en cuatro
fases, las que se realizan en varias iteraciones en número variable según el proyecto y en las que
se hace un mayor o menor hincapié en distintas actividades.
En cada iteración los desarrolladores identifican y especifican los casos de uso

relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, para implementar
dichos casos de uso. Si la iteración cumple sus objetivos, se continúa con la próxima. Sino
deben revisarse las decisiones previas y probar un nuevo enfoque.
Desarrollo basado en componentes: el sistema se divide en componentes con

interfaces bien definidas que una vez integrados conformarán el sistema. De esta manera el
sistema se irá creando a medida que se obtienen, se desarrollen y maduren los componentes.
Proceso Integrado: RUP es un proceso integrado porque provee una estructura que
incluye: ciclos, fases, flujos de trabajo, riesgos, controles de calidad, aspectos de gestión del
proyecto y control de configuraciones.
La estructura de RUP se basa en torno a cuatro elementos:
Los roles, que definen el comportamiento y responsabilidades de un individuo o

grupo de individuos que trabajan en un equipo. Una persona puede desempeñar
varios roles en el proyecto, así como un rol puede ser ejecutado por una o varias
Página 26
personas. Las responsabilidades de un rol son llevar a cabo un conjunto de

actividades, así como ser “el dueño” de un conjunto de artefactos. Los roles sirven
para responder a la pregunta: ¿Quién?
Las actividades son las unidades de trabajo que una persona en cumplimiento de un
rol podrá ejecutar. El objetivo de una actividad es crear o actualizar un producto.
Responde a la pregunta: ¿Cómo?
Los productos o artefactos. Son trozos de información que es producida,

modificada o usada en un proceso. Los productos son los resultados tangibles del
proyecto, las cosas que se crean y utilizan hasta llegar al producto final. Responden
a la pregunta: ¿Qué?
Las disciplinas son conjuntos de actividades relacionadas vinculadas a un área

específica dentro del proyecto total. Las más importantes son: requerimientos,
análisis, diseño, codificación y prueba. El hecho de agrupar las actividades en
disciplinas favorece la comprensión del proceso. Las disciplinas responden a la
pregunta: ¿Cuándo?
1.3.1.1.2. Fases del RUP
RUP se organiza en cuatro fases, las que se exponen a continuación (ver Figura 4):
Figura 4: Fases, iteraciones y disciplinas en RUP. (Fuente: [BL04]).
Página 27
Fase de Inicio: durante la fase de inicio se desarrolla una descripción del producto
final, y se presenta el análisis del negocio. El objetivo de esta fase es ayudar al equipo del
proyecto a decidir cuáles son los verdaderos objetivos del proyecto. Las iteraciones exploran
diferentes soluciones y arquitecturas posibles.
Esta fase responde las siguientes preguntas:
¿Cuáles son las principales funciones del sistema para los usuarios más importantes?
¿Cuál podría ser la mejor arquitectura del sistema?
¿Se ha determinado con claridad el ámbito del sistema? ¿Se ha determinado lo que
va a estar dentro del sistema y fuera del sistema?
¿Cuál es el plan del proyecto y cuanto costará desarrollar el producto?
¿Se identifican los riesgos críticos? ¿Se prevé forma de mitigarlos?
¿El uso del producto justifica la relación costo-beneficio?
¿Es factible para su organización llevar adelante el proyecto?
Los artefactos que típicamente se producen en esta fase son:
Un enunciado de los mayores requerimientos planteados generalmente como casos

de uso.
Un boceto inicial de la arquitectura.
Una descripción de los objetivos del proyecto.
Una versión muy preliminar del plan del proyecto.
Un modelo del negocio.
Se obtienen acuerdo en cuanto a:
Cuál es el conjunto de necesidades del negocio, y que conjunto de funciones

satisfacen estas necesidades.
Una planificación preliminar de iteraciones.
Una arquitectura preliminar.
Fase de Elaboración: durante la fase de elaboración se especifican en detalle la

mayoría de los casos de uso del producto y se diseña la arquitectura.
Página 28
Las iteraciones en la fase de elaboración:
Establecen una firme comprensión del problema a solucionar.
Establece la fundación arquitectural para el software.
Establece un plan detallado para las siguientes iteraciones.
Elimina los mayores riesgos.
En esta fase se construyen típicamente los siguientes artefactos:
El cuerpo básico del software en la forma de un prototipo arquitectural.
Casos de prueba
La mayoría de los casos de uso (80%) que describen la funcionalidad del sistema.
Un plan detallado para las siguientes iteraciones.
Debe poder responderse a preguntas como:
¿Se ha creado una línea base de la arquitectura3? ¿Es adaptable y robusta? ¿Puede
evolucionar?
¿Se han identificado y mitigado los riesgos más graves?
¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para respaldar una
agenda, costes, y calidad realistas?
¿Proporciona el proyecto, una adecuada recuperación de la inversión?
Fase de Construcción: durante la fase de construcción se crea el producto. La línea

base de la arquitectura crece hasta convertirse en el sistema completo.
Al final de esta fase, el producto contiene todos los casos de uso implementados, sin
embargo puede que no esté libre de defectos.
Los artefactos producidos durante esta fase son:
El sistema software
Los casos de prueba

3
La línea base de la arquitectura es el esqueleto estructural del sistema. Aunque la funcionalidad no sea
completa aún, muchas de las interfaces entre los bloques de construcción son implementadas y
probadas. Esto se refiere a una arquitectura ejecutable.
Página 29
Los manuales de usuario
Se llega a acuerdos sobre:
El producto es estable para ser usado
El producto provee alguna funcionalidad de valor
Todas las partes están listas para comenzar la transición.
Fase de Transición: la fase de transición cubre el período durante el cual el producto

se convierte en la versión beta.
Las iteraciones en esta fase continúan agregando características a la aplicación. Sin

embargo las características se agregan a un sistema que el usuario se encuentra utilizando
activamente.
Los artefactos construidos en esta fase son los mismos que en la fase de construcción.
El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del
sistema desarrollado en la fase anterior.
La fase de transición finaliza con el Lanzamiento del Producto.
1.3.1.2 Métrica Versión 3
Métrica es una metodología de planificación, desarrollo y mantenimiento de sistemas de

información promovida por el Ministerio de Administraciones Públicas del Gobierno de
España para la sistematización de actividades del ciclo de vida de los proyectos software en el
ámbito de las administraciones públicas. La organización general de esta metodología se
presenta en la Figura 5.
La metodología Métrica versión 3 ofrece a las organizaciones un instrumento útil para la

sistematización de las actividades que dan soporte al ciclo de vida del software dentro del marco
que permite alcanzar los siguientes objetivos [MET]:
Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de

la organización mediante la definición de un marco estratégico para el desarrollo de
los mismos.
Página 30
Dotar a la organización de productos software que satisfagan las necesidades de los

usuarios dando una mayor importancia al análisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la

Información y las Comunicaciones, permitiendo una mayor capacidad de
adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo
posible.
Facilitar la comunicación y entendimiento entre los distintos participantes en la

producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta
su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
Facilitar la operación, mantenimiento y uso de los productos software obtenidos.
Figura 5: esquema de la metodología Métrica versión 3. (Fuente [C08]).
Página 31
1.3.1.2.1. Principales Procesos
Métrica Versión 3 tiene un enfoque orientado al proceso, ya que la tendencia general en

los estándares se encamina en este sentido.
Esta metodología ha sido concebida para abarcar el desarrollo completo de sistemas de

información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a
desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las
características particulares de cada proyecto.
La metodología descompone cada uno de los procesos en actividades, y éstas a su vez

en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales
acciones, productos, técnicas, prácticas y participantes.
Así los procesos de la estructura principal de Métrica Versión 3 son los siguientes:
Planificación de sistemas de información.
Desarrollo de sistemas de información.
Mantenimiento de sistemas de información.
En cuanto al proceso de desarrollo de sistemas de información, para facilitar la

comprensión y dada su amplitud y complejidad se ha subdividido en cinco subprocesos:
Estudio de viabilidad del sistema (EVS).
Análisis del sistema de información (ASI).
Diseño del sistema de información (DSI).
Construcción del sistema de información (CSI).
Implantación y aceptación del sistema (IAS).
1.3.1.2.2. Interfaces de Métrica Versión 3
La estructura de Métrica Versión 3 incluye también un conjunto de interfaces que

definen una serie de actividades de tipo organizativo o de soporte al proceso de desarrollo y a
los productos, que en el caso de existir en la organización se deberán aplicar para enriquecer o
influir en la ejecución de las actividades de los procesos principales de la metodología y que si
no existen habrá que realizar para complementar y garantizar el éxito del proyecto desarrollado.
Página 32
La aplicación de Métrica Versión 3 proporciona sistemas con calidad y seguridad, no

obstante puede ser necesario en función de las características del sistema un refuerzo especial
en estos aspectos, refuerzo que se obtendrá aplicando la interfaz correspondiente.
Las interfaces descritas en la metodología son:
Gestión de Proyectos (GP). Esta interfaz tiene como finalidad principal la

planificación, el seguimiento y control de las actividades y de los recursos humanos
y materiales que intervienen en el desarrollo de un sistema de información. Como
consecuencia de este control es posible conocer en todo momento qué problemas
se producen y resolverlos o atacarlos lo más pronto posible, lo cual evitará
desviaciones temporales y económicas.
Seguridad (SEG). El objetivo de esta interfaz es incorporar en los sistemas de

información mecanismos de seguridad adicionales a los que se proponen en la
propia metodología, asegurando el desarrollo de cualquier tipo de sistema a lo largo
de los procesos que se realicen para su obtención.
La interfaz de Seguridad hace posible incorporar durante la fase de desarrollo las

funciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio
proceso de desarrollo, asegurando su consistencia y seguridad, completando el plan
de seguridad vigente en la organización o desarrollándolo desde el principio.
Aseguramiento de la Calidad (CAL). El objetivo de esta interfaz es proporcionar un

marco común de referencia para la definición y puesta en marcha de planes
específicos de aseguramiento de calidad aplicables a proyectos concretos.
Gestión de la Configuración (GC). La interfaz de gestión de la configuración

consiste en la aplicación de procedimientos administrativos y técnicos durante el
desarrollo del sistema de información y su posterior mantenimiento con la finalidad
es identificar, definir, proporcionar información y controlar los cambios en la
configuración del sistema, así como las modificaciones y versiones de los mismos.
Este proceso permitirá conocer el estado de cada uno de los productos que se hayan
definido como elementos de configuración, garantizando que no se realizan
cambios incontrolados y que todos los participantes en el desarrollo del sistema
disponen de la versión adecuada de los productos que manejan.
Página 33
1.3.1.3. Modelo de Capacidad y Madurez Integral (CMMI)
El Modelo de Capacidad y Madurez Integral (CMMI) [VA06] es un modelo para la

mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de
software que describe qué debería hacer una organización para optimizar los resultados, pero
no dice cómo debería hacerlo. Los modelos CMMI no son procesos ni descripciones de
procesos, sólo proporcionan guías apropiadas para elaborar y evaluar procesos.
El CMMI al igual que el CMM (Modelo de Capacidad de Madurez) establece un

conjunto de prácticas o procesos agrupados en áreas claves. Para cada área del proceso se
definen un conjunto de buenas prácticas; definidas en un procedimiento bien documentado.
A su vez estas áreas de proceso se agrupan en cinco niveles de madurez de modo que
una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus
inferiores, se considera que ha alcanzado ese nivel de madurez. Es decir, CMMI permite una
aproximación paso a paso a la optimización de las prácticas de desarrollo de sistemas.
Los niveles establecidos, que pueden apreciarse en la Figura 6, son:
1 – Nivel Inicial. Las organizaciones en este nivel no disponen de un ambiente estable

para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de
ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se
basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y
casi siempre retrasos y sobrecostos. El resultado de los proyectos es impredecible.
2 – Nivel Repetible. En este nivel las organizaciones disponen de unas prácticas

institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable
seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada
sistemáticamente.
Los procesos a implantar en este nivel son:
Gestión de requisitos
Planificación de proyectos
Seguimiento y control de proyectos
Gestión de proveedores
Aseguramiento de la calidad
Página 34
Gestión de la configuración
3 – Nivel Definido. Además de una buena gestión de proyectos, a este nivel las
organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación
del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los
procesos. Se implementan técnicas de revisión por pares (peer reviews).
Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solución Técnica
Integración del producto
Verificación
Validación
Desarrollo y mejora de los procesos de la organización
Definición de los procesos de la organización
Planificación de la formación
Gestión de riesgos
Análisis y resolución de toma de decisiones
4 – Nivel Cuantitativamente Gestionado. Se caracteriza porque las organizaciones

disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de
modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de
alta calidad.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión cuantitativa de proyectos
Mejora de los procesos de la organización
5 – Nivel Optimizado. La organización completa está volcada en la mejora continua

de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
Página 35
Figura 6: Los niveles de CMMI. (Fuente [MT09]).
1.3.1.4. Proceso Modularizado, Unificado y Medible
El Proceso Modularizado, Unificado y Medible (MUM) se obtiene como una evolución

constante de procesos en el Grupo de Ingeniería de Software (Gris). Sus antecedentes son
[DP06]:
Año 2000: Se crean dos modelos de proceso llamados Java I y Java II, ambos
basados en el Proceso Unificado (U.P.) de Booch, Jacobson y Rumbaugh.
Año 2001: se fusionan ambos modelos en el MP Java, incluyendo como aporte al

Proceso Unificado de Rational (RUP), evolución del U.P.
Año 2002: se define MoDSGX, basado en MP Java y en RUP para desarrollo con
Genexus.
Año 2003: se construye una extensión al MP Java denominada Integrado, que

permite el trabajo de varios grupos en un mismo producto. Se realiza una
adaptación de Programación Extrema (X.P.), metodología ágil de desarrollo, para
considerar las particularidades de Genexus. Recibe el nombre GXP.
Año 2004: se fusiona los procesos MoDSGX y MPJava en un proceso llamado

Factor. Factor tiene un esqueleto común, y además dos extensiones, una para el
Página 36
desarrollo con Genexus (extensión GX) y otra para desarrollo orientado a objetos
(extensión OO)
Año 2005: se mejora el proceso Factor en cuestiones de calidad y verificación,

construyéndose el proceso Unificado. Se construye un agregado con enfoque
S.O.A. (Service Oriented Architecture) que plantea la metodología para desarrollo
de este tipo de aplicaciones.
MUM ([PB06] y [PBP06]) considera los conceptos y las recomendaciones del proceso
RUP, de la metodología Métrica versión 3 y modelo CMMI para mejorar la calidad del proceso
en cuanto a las actividades que conforman el mismo. Incorpora métricas, por ejemplo de
Aceptación de los Requerimientos, Pruebas Cubiertas, Productividad Orientada al Tamaño del
Producto, entre otras, para evaluar las distintas actividades del proceso particularmente las
actividades vinculadas a Requerimientos, Verificación, Implementación, Implantación y
Administración.
Los integrantes del grupo mencionado realizaron un relevamiento y control en cuanto a

todas las actividades consideradas por los modelos de proceso anteriores del Gris,
incorporándose y eliminándose actividades. Además determinaron qué actividades eran parte
del desarrollo con un lenguaje específico y cuáles eran independientes del lenguaje elegido. Con
ello lograron un proceso unificado, constituyendo una base común, y extensiones para
tecnologías particulares (extensiones OO y GX) (ver Figura 7).
El proceso ha sido probado por grupos de estudiantes con clientes reales, permitiendo
depurarlo, y llegando a obtener excelentes resultados. Para una especificación completa del
proceso MUM consultar [PB06] .Además, existe un sitio Web que cual permite visualizar y
acceder desde una única página todas las actividades, entregables, roles y roles involucrados en
cada disciplina [PB07].
Página 37
Figura 7: Modelo de Proceso MUM. (Fuente [PB07]).
1.3.1.4.1. Características del Proceso M.U.M.
Las principales características del proceso MUM son:
Proceso Unificado. Unifica actividades agregándolas al esqueleto común, cuando las

mismas son independientes de los lenguajes en los que se desarrolla.
Proceso Modularizado. Modularización de la información del proceso de forma que

sea sencilla la modificación o sustitución de componentes del proceso, por ejemplo las distintas
actividades de las disciplinas.
Proceso Medible. Incorporación de métricas al proceso con el fin de poder medir y

servir como elemento objetivo para cuantificar mejor la calidad de los procesos y tener una
medida fiable para comparar con futuros procesos.
Estudio de Satisfacción al Cliente. Incorporación como parte de la mejora de calidad

del proceso del estudio de satisfacción al cliente a través de encuestas y entrevista realizadas a
los mismos.
Estructura del proceso MUM. La estructura del proceso MUM se describe con los
siguientes elementos (ver Figura 8):
Dimensión temporal: al igual que en RUP se divide al desarrollo de software en

ciclos donde cada ciclo trabaja para construir una nueva Generación del Sistema y a
Página 38
su vez cada ciclo se divide en cuatro fases: Inicial, Elaboración, Construcción y

Transición. Cada fase se divide en iteraciones y tiene objetivos definidos que al
cumplirlos indican su finalización. La forma de visualizar que se alcanzaron esos
objetivos es por intermedio de los entregables de la fase.
Dimensión del modelo: se basa en cuatro elementos de modelado principales para

describir en el proceso definido, qué, quién está haciendo qué, de qué forma (cómo)
y en qué momento (cuándo). Estos elementos son las disciplinas que describen
cuándo, los roles que describen quién, las actividades que describen cómo y los
entregables que describen qué. La definición de estos elementos es análoga a la del
RUP.
Agenda: indica la duración de cada fase e iteración en semanas, especificando las

actividades del proceso para cada semana y los entregables a generar.
Roles y combinación de roles: Se incluyen en el Modelo los siguientes roles:

Analista, Arquitecto, Especialista Técnico, Implementador, Responsable de
Verificación, Administrador, Responsable de SQA, Responsable de SCM,
Documentador de Usuario y Asistente de Verificación. Así mismo según el lenguaje
que se utilice surgen roles a los efectos de mejorar la calidad de cada actividad que
se desarrolla y una distribución de los recursos en forma equitativa, como el caso de
Asistente de SQA, Asistente de consolidado para el caso de Genexus, Coordinador
de Desarrollo, etc.
Actividades: Cada actividad tiene un conjunto de entregables de entrada (pre-

condiciones para su ejecución), un conjunto de roles que la realizan, una descripción
de las tareas a realizar en la actividad y un conjunto de entregables de salida (post-
condiciones de su ejecución).
Entregables: son los productos tangibles del Proyecto, los cuales pueden ser
entrada y/o salida de las distintas actividades. Cumplen propiedades de calidad y
tienen una plantilla asociada que sirve como guía para realizarlos.
Página 39
Figura 8: Fases, Iteraciones y duración en semanas en MUM. (Fuente [PB07]).
1.3.1.4.2. Extensiones Genexus
Una lista completa de las características aplicables exclusivamente al desarrollo con

Genexus, como ser actividades especiales (en cuanto a requerimientos e implementación), una
combinación particular de roles, plantillas, y una dimensión del tiempo específica pueden
visualizarse en la subcategoría Extensiones Gx de [PB07].
1.3.2. PROGRAMACIÓN EXTREMA CON GENEXUS
El grupo Gris desarrolló en 2004 una adaptación de la metodología ágil Programación

Extrema (Extreme Programming - XP) para su uso con la herramienta Genexus. Primeramente
se dará una introducción a metodologías ágiles de desarrollo, particularmente a XP, para luego
describir las consideraciones propuestas por el Gris [P04].
1.3.2.1. Metodologías Ágiles de Desarrollo de Software
Los procesos ágiles de desarrollo de software intentan evitar los complicados y

burocráticos caminos de las metodologías tradicionales, enfocándose en la gente y los
resultados. Proponen una fuerte colaboración del cliente en el proceso de desarrollo.
El desarrollo ágil es un marco de trabajo conceptual de la ingeniería de software que

promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Los
métodos de desarrollo ágil minimizan riesgos construyendo software en cortos lapsos de
tiempo. El proceso de desarrollo está constituido por iteraciones, cada una de las cuales debe
durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de
requerimientos, diseño, codificación, revisión y documentación. Cada iteración significa el
agregado de un número reducido de nuevas funcionalidades. Al final de cada una se obtiene
Página 40
una nueva versión del producto, también en este momento el equipo vuelve a evaluar las
prioridades del proyecto.
Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la

documentación. Además priorizan el software funcional, ya que lo consideran la principal
medida del progreso, por sobre los modelos y la documentación. Los métodos ágiles son
criticados por la falta de documentación técnica.
1.3.2.1.1. Manifiesto Ágil
En 2001 diecisiete críticos de los modelos de mejora del desarrollo de software basados
en procesos, convocados por Kent Beck4 se reunieron para tratar sobre técnicas y procesos
para desarrollar software, como resultado elaboraron el Manifiesto Ágil5.
Los integrantes de la reunión resumieron los principios sobre los que se basan los
métodos alternativos, en oposición a las metodologías tradicionales, en cuatro postulados o
valores.
1.3.2.1.2. Valores del manifiesto ágil
Según el Manifiesto se valora [CLP05]:
Al individuo y las interacciones del equipo de desarrollo por encima del

proceso y las herramientas. La gente es el principal factor de éxito de un proyecto
software. Es más importante construir un buen equipo que construir el entorno.
Muchas veces se comete el error de construir primero el entorno y esperar que el
equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su
propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funcione por encima de construir una

documentación exhaustiva. La regla a seguir es “no producir documentos a
menos que sean necesarios de forma inmediata para tomar una decisión
importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.
4
Kent Beck es un Ingeniero de Software, creador de la Programación Extrema y el Desarrollo Guiado
por Pruebas (TDD). Es también uno de los pioneros en Patrones de Diseño de Software
5 Sitio Web del Manifiesto Ágil (en inglés) http://www.agilemanifesto.org/
Página 41
La colaboración con el cliente por encima de la negociación de un contrato.

Se propone que exista una interacción constante entre el cliente y el equipo de
desarrollo. Esta colaboración entre ambos será la que marque la marcha del
proyecto y asegure su éxito.
La respuesta al cambio por encima del seguimiento estricto de un plan. La

habilidad de responder a los cambios que puedan surgir a los largo del proyecto
(cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el
éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino
flexible y abierta.
1.3.2.1.3. Principios del manifiesto ágil
Los valores anteriores inspiran los doce principios del manifiesto. Son características
que diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto a metas a seguir y organización del mismo. Los principios son
[CLP05]:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de

software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga
una ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par
de meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del
proyecto, de manera cotidiana.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo

que necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal del progreso.
Página 42
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener un ritmo constante.
IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
X. La simplicidad, como arte para maximizar la cantidad de trabajo hecho, es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos auto-
organizados.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más
efectivo, y ajusta su comportamiento en consecuencia.
Tabla 2: Comparación metodologías ágiles y metodologías tradicionales (Fuente: [CLP05]).
Metodologías Ágiles Metodologías Tradicionales
Basadas en normas provenientes de

Basadas en heurísticas de prácticas de
estándares seguidos por el entorno del
producción de código
desarrollo
Especialmente preparados para
Cierta resistencia a los cambios
cambios durante el proyecto
Impuestas internamente (por el
Impuestas externamente
equipo)
Proceso menos controlado, con pocos Proceso mucho más controlado, con
principios numerosas políticas normas
No existe contrato tradicional o al
Existe un contrato prefijado
menos es bastante flexible
El cliente es parte del equipo de El cliente interactúa con el equipo de
desarrollo desarrollo mediante reuniones
Grupos pequeños (< 10 integrantes) y Grupos grandes y posiblemente
trabajando en el mismo sitio distribuidos
Pocos artefactos Más artefactos
Pocos roles Más roles
Menos énfasis en la arquitectura de La arquitectura del software es esencial y
software se expresa mediante modelos
Página 43
1.3.2.1.4. Consideraciones sobre Metodologías Ágiles
Las metodologías tradicionales han demostrado ineficiencia e inconvenientes en

proyectos de desarrollo en los que el tiempo disponible es muy reducido, o en los cuales los
requerimientos cambian de forma vertiginosa.
En este escenario, las metodologías ágiles emergen como una posible respuesta para
llenar ese vacío metodológico (ver comparación en Tabla 2). Por estar especialmente orientadas
para proyectos pequeños, las metodologías ágiles constituyen una solución a medida para ese
entorno, aportando una elevada simplificación pero sin renunciar a las prácticas esenciales para
asegurar la calidad del producto.
Una característica importante de las metodologías ágiles es su sencillez, tanto en su

aprendizaje como en su aplicación, permitiendo reducir costos de implantación en un equipo de
desarrollo. Sin embargo, también existen inconvenientes y restricciones para su aplicación, tales
como:
están pensadas a equipos pequeños o medianos,
se debe contar con instalaciones que permitan la comunicación y colaboración entre

todos los miembros del equipo durante todo el tiempo
es necesaria la predisposición tanto del equipo como de los usuarios para su

aplicación. Es especialmente imprescindible el compromiso del cliente en cuanto a
dedicación de horas al proyecto, y su esfuerzo para explicar requerimientos,
contestar dudas, y validar prototipos. La resistencia de estos actores hacia sus
prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la
colaboración y la relación contractual son claves)
es imprescindible el uso de tecnologías que soporten fácilmente el cambio.
1.3.2.2. Programación Extrema
La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería

de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles
de desarrollo de software.
Página 44
1.3.2.2.1. Prácticas XP
XP cuenta con un conjunto de prácticas recomendadas, que sustentan el cumplimiento

de los 5 valores (simplicidad, comunicación, retroalimentación, coraje y respeto). A
continuación, una concisa explicación de las prácticas (ver Figura 9):
El juego de la planificación. Hay una comunicación frecuente entre el cliente y

los programadores. El equipo técnico realiza una estimación del esfuerzo requerido
para la implementación de las historias de usuario y los clientes deciden sobre el
ámbito y tiempo de las entregas y de cada iteración.
Entregas pequeñas. Producir rápidamente versiones del sistema que sean

operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versión
ya constituye un resultado de valor para el negocio. Una entrega no debería tardar
más 3 meses.
Metáfora. El sistema es definido mediante una metáfora o un conjunto de

metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una
historia compartida que describe cómo debería funcionar el sistema (conjunto de
nombres que actúen como vocabulario para hablar sobre el dominio del problema,
ayudando a la nomenclatura de clases y métodos del sistema).
Diseño simple. Se debe diseñar la solución más simple que pueda funcionar y ser
implementada en un momento determinado del proyecto.
Pruebas automatizadas. La producción de código está dirigida por las pruebas

unitarias. Éstas son establecidas por el cliente antes de escribirse el código y son
ejecutadas constantemente ante cada modificación del sistema.
Refactorización (Refactoring). Es una actividad constante de reestructuración del

código con el objetivo de remover duplicación de código, mejorar su legibilidad,
simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. Se mejora
la estructura interna del código sin alterar su comportamiento externo.
Programación en parejas. Toda la producción de código debe realizarse con

trabajo en parejas de programadores. Esto conlleva ventajas implícitas (menor tasa
de errores, mejor diseño, mayor satisfacción de los programadores, etc.).
Propiedad colectiva del código. Cualquier programador puede cambiar cualquier

parte del código en cualquier momento.
Página 45
Integración continua. Cada pieza de código es integrada en el sistema una vez que
esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un
mismo día.
40 horas por semana. Se debe trabajar un máximo de 40 horas por semana. No se

trabajan horas extras en dos semanas seguidas. Si esto sucede, probablemente está
ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo.
Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para
el equipo. Éste es uno de los principales factores de éxito del proyecto en XP El
cliente conduce constantemente el trabajo hacia lo que aportará mayor valor de
negocio y los programadores pueden resolver de manera inmediata cualquier duda
asociada. La comunicación oral es más efectiva que la escrita.
Estándares de programación. XP enfatiza que la comunicación de los

programadores es a través del código, con lo cual es indispensable que se sigan
ciertos estándares de programación para mantener el código legible.
Figura 9: Relación entre las prácticas en XP. (Fuente: [CLP05])
Página 46
1.3.2.2.2. Valores de XP:
Los Valores originales de la programación extrema son: simplicidad, comunicación,

retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda
edición de Extreme Programming Explained. Se explicarán los 5 valores:
Simplicidad:
La simplicidad es la base de la programación extrema. Se simplifica el diseño para

agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a
sucesivas modificaciones por parte de diferentes desarrolladores hace que la complejidad
aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del
código; también se aplica la simplicidad en la documentación, de esta manera el código debe
comentarse en su justa medida, pero privilegiando la auto-documentación del código. Para ello
se deben elegir adecuadamente los nombres de las variables, métodos y clases. Aplicando la
simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura
que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema
completo.
Comunicación:
La comunicación se realiza de diferentes formas. Para los programadores el código

comunica mejor cuanto más simple sea. Si el código es complejo deberán esforzarse para
comprenderlo. Las pruebas unitarias son otra forma de comunicación ya que describen el
diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su
funcionalidad. Los programadores se comunican constantemente gracias a la programación por
parejas. La comunicación con el cliente es fluida ya que éste forma parte del equipo de
desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible
para solucionar dudas.
Retroalimentación (feedback):
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se

conoce constantemente. Al realizarse ciclos muy cortos tras los cuales se muestran resultados,
se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los
programadores a centrarse en lo que es más importante. Las pruebas unitarias proporcionan
información sobre el funcionamiento del código. Ejecutar las pruebas unitarias frecuentemente
permite descubrir fallos debidos a cambios recientes en el código.
Página 47
Coraje o valentía:
La programación en parejas puede ser difícil de aceptar, porque hace suponer que la
productividad se podría reducir a la mitad ya que sólo la mitad de los programadores está
escribiendo código, esta técnica requiere valentía por parte de los gerentes de programación.
No se debe emprender el desarrollo de grandes marcos de trabajo (frameworks) mientra el
cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el
equipo de desarrollo no recibe retroalimentación para saber si va en la dirección correcta. La
forma de construir marcos de trabajo es mediante la refactorización del código en sucesivas
aproximaciones.
Respeto:
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los
unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas
existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo
porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo
o más eficiente para la solución a través de la refactorización del código. Los miembros del
equipo respetan el trabajo del resto no haciendo menos a otros, si no orientándolos a realizarlo
mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de
producción en el equipo.
1.3.2.2.3. Roles XP
Los roles de acuerdo con la propuesta original de Beck son [CLP05]:
Programador. El programador escribe las pruebas unitarias y produce el código del

sistema.
Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su
implementación. Además, asigna la prioridad a las historias de usuario y decide
cuáles se implementan en cada iteración centrándose en aportar mayor valor al
negocio.
Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas

funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y
es responsable de las herramientas de soporte para pruebas.
Página 48
Encargado de seguimiento (Tracker). Proporciona realimentación al equipo.

Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real
dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de
cada iteración.
Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al

equipo de forma que se apliquen las prácticas XP y se siga el proceso
correctamente.
Consultor. Es un miembro externo del equipo con un conocimiento específico en

algún tema necesario para el proyecto, en el que puedan surgir problemas.
Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el

equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial
es de coordinación.
1.3.2.2.4. Las Historias de Usuario
Son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de
papel en las cuales el cliente describe brevemente las características que el sistema debe poseer,
sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy
dinámico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada
para que los programadores puedan implementarla en unas semanas. Las historias de usuario
son descompuestas en tareas de programación (task-card) y asignadas a los programadores para
ser implementadas durante una iteración.
1.3.2.2.5. Proceso XP
En un proyecto usando programación extrema se siguen los siguientes pasos:
El cliente junto al equipo de desarrollo definen qué es lo que se quiere hacer. Para ello
utilizan las historias de usuario. Se estima el esfuerzo necesario para implementar cada historia,
el tiempo necesario para cada una debe ser corto, de aproximadamente una semana. Si es más
largo, hay que partir la historia en otras más pequeñas. Luego se acomodan en el orden en que
se van a desarrollar y se establecen las mini-versiones, de forma que cada mini-versión
implementa varias de las historias de usuario.
Página 49
Esta planificación necesitará ser modificada a medida que avance el proyecto. Las
historias de usuario se modificarán, se quitarán o se añadirán nuevas sobre la marcha. Puesto
que el cliente estará presente día a día durante todo el proyecto, verá el efecto y el esfuerzo
necesario para las modificaciones pedidas y sabrá evaluar si merecen o no la pena.
Se define pruebas automáticas para controlar si la mini-versión cumple correctamente

con las historias del usuario.
Los programadores se agrupan en parejas (dos personas en la misma computadora) para

codificar esas historias. En su código hacen de la forma más sencilla posible lo mínimo
imprescindible para que se pasen las pruebas automáticas. Las parejas de programadores se
intercambian con frecuencia, de forma que todos acaban trabajando con todos.
El código no es propiedad de nadie. Cualquier pareja puede modificar y reutilizar el

código ya hecho por otras personas si lo necesita, con la condición de que después de tocarlo
las pruebas automáticas sigan pasándose correctamente y que añadan sus propias pruebas
automáticas para las correcciones realizadas.
Todos los días se hace una pequeña reunión a primera hora de la mañana con todo el
equipo en la que se comentan problemas, código que se está realizando, historias de usuario
terminadas, etc.
Cada vez que se consigue codificar y que funcione una historia de usuario, se le da al
cliente para que la vea, la pruebe y añada las posibles modificaciones para las siguientes mini-
versiones. Cuando se realiza un mini-versión completa (compuesta por varias de las historias de
usuario), se entrega al usuario final para que empiece a trabajar con ella y reportar incidencias o
mejoras.
Este ciclo se va repitiendo una y otra vez hasta que el cliente se dé por satisfecho y
cierre el proyecto.
1.3.2.3. GXP - Programación Extrema con Genexus
Programación Extrema fue ideada para desarrollos orientados a objetos. Al adaptar XP

para programación con Genexus se mantiene la esencia de los valores y las prácticas sugeridas
por Beck, pero surgen algunas consideraciones propias de las características de la herramienta y
de su modo de utilización [P04]:
Página 50
En cuanto a pruebas automatizadas será necesario utilizar herramientas específicas

para probar el código generado por Genexus. Se sugiere usar la herramienta
Rational Robot, que permite desarrollar las pruebas mediante su lenguaje
propietario: SQA Basic.
En cuanto a mantener el diseño simple, en GXP se debe tratar de tener la cantidad

mínima de objetos, diseñado sus interacciones de forma que no se incremente la
complejidad.
En cuanto a refactoring, no es aplicable directamente por el analista en Genexus. Al

surgir cambios en los requerimientos éstos se plasmarán en la base de
conocimiento, y será la herramienta la encargada de generar código nuevo y
eficiente. Por este motivo, no será necesaria la intervención humana para tratar de
mantener el código comprensible, para su posterior modificación.
La metodología GXP ha sido probada en grupos de estudiantes en la Universidad de la

República del Uruguay [P04]. Para esta situación ha recibido adaptaciones en cuanto a tiempos
y recursos disponibles a nivel académico. Según sus creadores, la experiencia por parte de los
alumnos, el cliente y el docente ha sido grata y alentadora, cumpliéndose las expectativas del
cliente en cuanto a tiempos previstos y a calidad y funcionalidad del producto obtenido.
1.3.3. METODOLOGÍA GENEXUS
“Desde un punto de vista teórico, Genexus es más una metodología de desarrollo de

aplicaciones que una herramienta de software” [AC99].
La filosofía de Genexus está basada en el concepto conocido como desarrollo

incremental. En muchos proyectos surge la necesidad de hacer cambios durante la etapa de
construcción, o cuando el sistema ya se encuentra implementado. Como motivos principales
están:
Se detectan errores en la especificación de requerimientos por incorrecta

comunicación con el usuario y/o interpretación del analista.
Han cambiado las condiciones del negocio (cambios en el entorno de la

organización) afectando a las funcionalidades requeridas del software. Esta situación
Página 51
será más probable mientras más se extienda en el tiempo el proceso de desarrollo

(proyectos grandes o errores en la planificación del mismo).
Estas situaciones tienen como principal problema el alto costo que significa desarrollar
las modificaciones. Además son causa de falencias graves en cuanto a calidad del software
modificado, y deficiencias en cuanto a documentación.
Por estos motivos, Genexus facilita la construcción de aplicaciones mediante

aproximaciones sucesivas permitiendo, una vez detectada la necesidad de cambios, su fácil
plasmado en el proyecto. En esta característica, colabora de manera importante la capacidad de
prototipado inmediato, sin incurrir en costos adicionales.
1.3.3.1. Actividades a seguir para el desarrollo de aplicaciones
Pressman [P05] describe un conjunto de 5 actividades genéricas para el marco de

trabajo del proceso. Las actividades son: comunicación, planeación, modelado, construcción y despliegue.
Las dos primeras actividades se han unificado en la actividad de comunicación y planeación, por
considerarse que es al principio del proyecto el momento en el cual se requiere una
comunicación intensiva con el usuario, y particularmente con los niveles más altos de la
organización. Es necesario aclarar que el usuario continúa colaborando con el proyecto en las
demás actividades. Para las principales actividades se referirán las acciones que las componen
[AC99].
1.3.3.1.1. Actividad de Comunicación y Planeación
Los objetivos de esta actividad son la investigación de requisitos, el establecimiento del

plan del proyecto en cuanto a recursos necesarios, tiempos estimados, productos que han de
desarrollarse y programa de trabajo; en caso de considerarse necesario se incluirá también un
análisis de riesgos.
Esta actividad incluye las siguientes acciones:
Definir el objetivo
Se debe conocer los objetivos específicos de los usuarios de la aplicación y por medio
de qué actividades planean alcanzarlos, para determinar la manera en la que el sistema puede
colaborar en su concreción. Así se definirán los objetivos de la aplicación.
Página 52
Este objetivo debe poder ser expresado en uno o dos párrafos. Si no es posible
explicitarlo, es muy probable que la idea no sea clara, o que el objetivo sea muy general. Este
documento debe ser conocido por todas las personas involucradas en el proyecto.
Definir el equipo de trabajo
Esta acción consiste en especificar los recursos humanos que serán necesarios para el
proyecto de sistemas. Como mínimo debe contar con dos personas: el analista de sistemas
(mencionado como Analista Genexus en los cursos de capacitación de Artech [AC10]) y el
usuario. El analista debe tener experiencia en la utilización de la herramienta.
Es muy importante la participación de los usuarios en todas las etapas del desarrollo. El
analista obtendrá los requerimientos interrogando al usuario, y analizará sus opiniones y
reacción al presentarle los prototipos. El usuario debe tener predisposición para estas tareas.
Esta idea (fuerte integración del cliente en el proceso) es compartida con las Metodologías
Ágiles de desarrollo.
Se recomienda el trabajo en equipos pequeños, de no más de 5 personas. Genexus

libera de la mayor parte de las tareas de codificación, por lo que el trabajo es prioritariamente de
diseño, por esta razón no serán necesarios grupos de más integrantes.
Obtener una imagen global
Se debe tener entrevistas con el nivel gerencial más alto posible, para obtener un
panorama sobre la posición e importancia relativas de la aplicación dentro del sistema
informático de la organización.
Definir el alcance de la aplicación
Es básicamente determinar la responsabilidad de la aplicación dentro del cumplimiento

del objetivo. La aplicación debe cumplir con todas las tareas imprescindibles para lograrlo.
1.3.3.1.2. Actividad de modelado
Abarca la creación de modelos que permiten al desarrollador y al cliente entender mejor

los requisitos del software.
Análisis y Diseño
Estas acciones son realizadas conjuntamente por el analista y el usuario, y consiste en

identificar y describir las visiones de datos de los usuarios. El trabajo se puede realizar en el
Página 53
ambiente del usuario final, lo que permite trabajar con un bajo nivel de abstracción, utilizando
términos y conceptos que son bien conocidos por el mismo. El objetivo es conseguir una
actitud participativa del usuario en el proyecto, logrando que considere al sistema como “su
obra”, en parte. De esta manera se obtendrá su compromiso en el trabajo de diseño, y gracias a
su seguimiento constante del proyecto, se obtendrá un incremento significativo de calidad.
Se recomienda mantener el diseño simple. La ventaja de las procesos incrementales

es la posibilidad de realizar el software en pequeñas versiones (obtenidas mediante iteraciones)
manteniendo la simplicidad del diseño. Se debe verificar la evolución del modelo
frecuentemente con el usuario.
Genexus captura el conocimiento por medio de objetos que se utilizan para representar
la realidad del usuario. Los principales tipos de objetos soportados son: Transacciones,
Procedimientos, Web Panels, Tipos Estructurados de Datos (SDT), entre otros.
La tarea de análisis y diseño consiste, principalmente, en identificar y describir estos

objetos. A partir de estas descripciones, automáticamente Genexus va construyendo la base de
conocimiento, de forma incremental.
Esta base de conocimiento es un repositorio único de toda la información del proyecto,

a partir de la cual Genexus inferirá el modelo de datos físico (tablas, atributos, índices, reglas de
integridad referencial, etc.) y los programas de aplicación.
Diseño de Transacciones
El análisis mismo comienza con la definición de las transacciones. Este es un proceso

incremental, por lo que en primer momento se encontrarán las más significativas, y luego las
complementarias. Asimismo, su estructura se irá mejorando a medida que el diseño avance.
Para empezar con la definición de las transacciones, se comenzará con un estudio de los
principales objetos, reales o imaginarios, con los que el usuario interactúa. Es posible encontrar
la mayor parte de las transacciones a partir de:
La descripción del sistema: se pueden determinar muchas transacciones a partir de

los sustantivos que el usuario utiliza durante la descripción del sistema.
Formularios existentes: probablemente por cada formulario utilizado en el sistema

exista una transacción para entrada de los mismos.
En el diseño de transacciones se incluye:
Página 54
Definir la estructura: ¿qué atributos la componen, y qué relación existe entre los
mismos?
Definir las fórmulas: ¿qué atributos son calculables a partir de otros? ¿cuál es el
cálculo necesario para cada uno?
Definir las reglas: ¿qué condiciones que debe cumplir la transacción (o sus
atributos)? Por ejemplo, establecer los valores por defecto de los atributos, y los
controles que se deben hacer sobre sus datos.
Definir la interfaz o form de la transacción: personalizar la apariencia de la interfaz

gráfica para interactuar con la transacción. Se ofrece una interfaz predeterminada
tanto en formato Windows como Web.
Definir propiedades de la transacción: establecer comportamiento general de la

misma.
Incluir ayuda: agregar texto formateado para la ayuda a los usuarios en el uso de la
transacción.
Incluir documentación: agregar texto técnico para ser utilizado como

documentación del sistema.
Además de las transacciones en esta fase se definirán los demás tipos de objetos
mencionados. Su explicación, así como mayores detalles sobre las transacciones serán dados en
capítulos posteriores.
Prototipado
La comunicación adquiere una importancia primordial en la actividad de diseño. Por

este motivo, las dificultades de la comunicación humana afectarán al proceso de desarrollo.
Entre los inconvenientes más comunes se encuentran:
El usuario olvida dar detalles más o menos importantes.
El analista no comprende correctamente lo expresado por el usuario.
El analista no toma nota de cuestiones que pueden ser relevantes.
El usuario se equivoca en algunas apreciaciones.
Página 55
Además, el desarrollo de un nuevo sistema puede extenderse en el tiempo, teniendo esta

situación como principales factores la complejidad del sistema y la cantidad de recursos
asignados al proyecto. Esto da lugar a otras consideraciones:
Si los problemas enumerados anteriormente son detectados en las pruebas finales, el

costo de solucionarlos es muy grande.
La organización está sometida a la influencia del entorno y sus cambios. Por lo

tanto no es recomendable congelar las especificaciones durante el tiempo de
desarrollo, si fuese así es probable que la solución generada sea incompleta.
Para disminuir el impacto de estas eventualidades, Genexus permite la construcción de

prototipos de forma automática. El prototipo será exhibido al usuario, para comprobar que la
comunicación, el análisis y el diseño han sido correctos, por ejemplo cuando ha surgido un
requerimiento nuevo.
Además, al no existir diferencias funcionales en los prototipos creados por Genexus,

con respecto a la aplicación final, es posible probar cuál es la repercusión de cada cambio sobre
el resto del sistema.
1.3.3.1.3. Actividad de Construcción o Producción
Consiste en producir los programas de aplicación para ser utilizados en el ambiente de

producción. La generación de los aplicativos, así como de la base de datos, es completamente
automática, por parte de Genexus.
A partir de una base de conocimiento (que contiene todas las especificaciones del
diseño) es posible generar varias implementaciones, para distintas plataformas de ejecución.
Cada una de estas versiones podrá ser optimizada para el ambiente en el cual correrá.
Al estar basada esta metodología en el desarrollo incremental, las fases de diseño y

prototipado se ejecutarán de manera repetitiva y, eventualmente se procederá a la fase de
producción, para crear una nueva versión del programa, una vez corregidos los problemas
detectados mediante prototipado (ver Figura 10).
Página 56
Figura 10: Interrelación entre etapas: diseño - prototipado y diseño – producción. (Fuente: [AC08])
1.3.3.1.4. Actividad de despliegue
El software se entrega al cliente, quien utiliza el producto recibido, y provee

información basada en el uso del mismo en el entorno de la realidad.
1.3.3.2. Metodologías Tradicionales vs. Metodología Genexus
Como se ha mencionado Genexus puede ser considerado no sólo como una

herramienta, sino como una metodología de desarrollo. En este sentido, tiene aspectos de
similitud con las metodologías tradicionales, pero aporta enfoques bastante diferentes en otros.
Al igual que en metodologías tradicionales, se prioriza la importancia del análisis y el

diseño de la aplicación, por sobre la implementación. El hecho de incluir al usuario durante la
mayor parte del proyecto de desarrollo colabora con esta idea. Las tareas de implementación
son delegadas directamente a la herramienta.
Por otra parte, existen aspectos que son bien diferentes a las metodologías más
conocidas, como por ejemplo, incluir en el análisis la creación o personalización de la interfaz,
la muy escasa referencia a la implementación física del sistema, etc.
En el análisis estructurado y otras metodologías que han quedado relegadas, el análisis

se basa primeramente en los procesos. En general, este análisis es Top-Down (descendente)
Página 57
partiendo de una definición abstracta de la función general del sistema y descomponiéndolo

luego en funciones más simples (descomposición funcional) hasta llegar a un nivel de
abstracción adecuado para implementarlas directamente.
Este enfoque presenta varios inconvenientes:
Las funciones de un sistema tienden a evolucionar rápidamente con el tiempo,

convirtiendo a este tipo en diseño en más difícil de mantener.
En aplicaciones medianas o grandes se vuelve un inconveniente tratar de definir

todo el sistema mediante una única función.
Frecuentemente se descuida el análisis de los datos.
No se ve facilitada la integración de las aplicaciones.
En otras metodologías más modernas, se encara primeramente el análisis de datos,

estudiando la realidad de forma abstracta, con el objetivo de obtener el modelo de datos de la
organización. A partir de éste se procede al diseño de la base de datos.
Realizando el análisis con orientación a los datos se pueden obtener las siguientes
ventajas:
Más estabilidad: los datos tienden a ser más estables que los procesos,
permitiendo desarrollar una aplicación más fácil de mantener.
Facilidad de integración con otras aplicaciones: en general, varias aplicaciones

colaboran dentro de la organización, es decir, no actúan de forma separada. La
mejor forma de planificar esta integración es teniendo en cuenta los datos que
comparten.
En estas metodologías, una vez analizados los datos se estudia la realidad desde el
punto de vista de las funciones (análisis funcional). Sería conveniente que la especificación
funcional lograda sólo dependiese de la realidad. Sin embargo, generalmente, se obtiene una
especificación funcional que se refiere a las entidades del modelo de datos, que son
esencialmente equivalentes a las tablas de la base de datos.
Con la base de datos diseñada y la especificación funcional realizada, se procede a la

implementación de las funciones en el lenguaje de programación o mediante generadores e
intérpretes. Al estar basando la especificación funcional en el modelo de datos se está
considerando que es posible construir un modelo de datos estable de la organización.
Página 58
Este enfoque presenta como primer inconveniente la dificultad en la práctica para construir un
modelo de datos completo, con suficiente nivel de detalle y objetividad por parte del analista.
Pero aún si fuera posible construir el modelo exacto, en toda organización será
necesario realizar cambios en los datos representados, al evolucionar la empresa. Considerando
que la especificación funcional se refiere a la base de datos, esto implicará modificar
manualmente el código de aplicación (segundo inconveniente). La principal desventaja para la
empresa en este panorama son los elevados costos de mantenimiento.
Dado que es dificultoso, en este contexto, propagar las consecuencias de los cambios en
la base de datos a los procesos, muchas veces se recurre a la alternativa de introducir nuevas
tablas redundantes, con la inevitable degradación de la calidad y el incremento mayor de las
necesidades de mantenimiento.
Para subsanar el primer inconveniente, en la metodología Genexus se considera el

enfoque de las visiones de datos de los usuarios, como ya se ha mencionado. El hecho de
concentrar el análisis en la utilización real de los datos en la organización (por cada tipo de
usuario) es una importante ventaja por la posibilidad de incluir más visiones de datos sin
modificar sustancialmente el modelo. Además se facilita la comunicación con los usuarios, al
usar una representación más intuitiva que la del modelo relacional.
Por otra parte, se entiende que no es posible construir un modelo de datos estable
de la empresa, en cambio, se utiliza la filosofía incremental y el desarrollo basado en el
conocimiento. Esto es, se sabe que los datos cambian de acuerdo a las nuevas necesidades,
por lo tanto se disminuye la dependencia de las funciones con respecto a las estructuras de
datos. Se trata de que cambios en los datos no requieran modificar el código escrito por el
analista, sino que la herramienta genere nuevo código compatible con la representación
modificada. La diferencia entre los enfoques de las metodologías tradicionales y la metodología
Genexus se ilustra en la siguiente figura:
Página 59
Figura 11: Comparación Metodología Genexus (flechas en amarillo oscuro) vs. Metodologías
tradicionales (flechas en amarillo claro). (Fuente: [EJ01])
1.3.4. ELECCIÓN DE LA METODOLOGÍA
Se utilizará la metodología Genexus por las siguientes razones:
Es la mejor adaptada para el uso con esta herramienta, esto se evidencia por
ejemplo en el hecho de que considera el diseño de transacciones, principal tipo de
objeto de Genexus, como una tarea particular dentro del diseño.
Da menos importancia a la actividad de construcción, ya que en Genexus la

codificación no es una actividad intensiva en cuanto a trabajo.
Aplica fuertemente el paradigma de desarrollo incremental, ésta es una característica

deseable ya que casi con seguridad el sistema deberá ser modificado a futuro,
probablemente por otros estudiantes o profesionales de la carrera.
Página 60
Está particularmente ideada para la realización de aplicaciones web, ya que ésta es

una de las principales características de las versiones más recientes de la
herramienta.
No exige la realización de documentación compleja, permitiendo aplicar las

facilidades de la herramienta tanto para documentación técnica, como para incluir
ayuda para el usuario.
No obstante, dicha metodología es utilizada con las adaptaciones que se consideran

necesarias y convenientes para este proyecto en particular.
Página 61
CAPÍTULO II:
METODOLOGÍA
En este capítulo se explica la aplicación y adaptación de la metodología Genexus al

desarrollo del Sistema de Información para la Publicación de las Tesinas de Grado (o Trabajos
Finales de Aplicación). Este desarrollo forma parte de un proyecto mayor, que además
contempla la gestión de alumnos, exámenes, y materiales de la asignatura Trabajo Final de
Aplicación.
A las cuatro actividades genéricas de la metodología Genexus enriquecida con el

proceso de Pressman, se le ha agregado una quinta: el estudio de las tecnologías, por
considerarla necesaria en este proyecto. Así, la metodología a aplicar queda compuesta por las
siguientes actividades: comunicación y planeación, estudio de las tecnologías, modelado,
construcción y despliegue. A continuación, se exponen las acciones llevadas a cabo en cada
una de ellas.
2.1. Actividad de Comunicación y Planeación.
Este proyecto, incluye las siguientes acciones:
2.1.1. Definir el objetivo:
A partir de la comunicación con los docentes de la asignatura Trabajo Final de

Aplicación se define el objetivo de la aplicación a desarrollar. A modo sintético, el objetivo es
permitir la publicación en la Web de los resúmenes sintéticos de los Trabajos Finales
de la Carrera Licenciatura en Sistemas de Información, que serán accesibles tanto por los
alumnos de la carrera, como por el público en general.
2.1.2. Definir el equipo de trabajo:
El equipo de trabajo está compuesto por dos estudiantes avanzados de la carrera,

uno de ellos es el autor del presente trabajo, y los docentes de la asignatura. Los docentes
proporcionan los requerimientos y participan en la prueba de los prototipos, aportando las
Página 62
consideraciones necesarias para guiar el desarrollo. Parte de la etapa de análisis, así como el
diseño de datos, son llevados a cabo en conjunto por ambos alumnos, ya que estas actividades
se realizan considerando el sistema completo. Las actividades exclusivas del Sistema de
Publicación de Tesinas son llevadas a cabo por el autor, quien ocupa el rol de analista Genexus,
encargándose del análisis, diseño de modelos, y desarrollo propiamente dicho en la herramienta
Genexus.
2.1.3. Obtener una imagen global:
La importancia del Sistema de Publicación, en el marco de la asignatura, está dada por la

necesidad de difundir los datos más generales de los TFA realizados y defendidos por los
alumnos de años anteriores, para que sirvan de base en la elección de nuevos temas de
investigación, tanto para alumnos de ésta como de otras universidades. Es importante aclarar
que no se publica el contenido de los informes producidos por los alumnos, sino sólo el
resumen sintético.
2.1.4. Definir el alcance de la aplicación:
En esta etapa se han obtenido los principales requerimientos a implementar mediante el

sistema. Pueden resumirse de la siguiente manera:
Permitir la publicación de los resúmenes sintéticos de los Trabajos Finales de la

Carrera.
Proporcionar facilidades de búsqueda de acuerdo a los criterios más importantes.
Presentar información general de los TFA, alumnos, docentes orientadores, etc.
Facilitar la descarga de archivos en formato PDF con los datos principales de los
trabajos.
Almacenar estadísticas de número de consultas de los distintos TFA.
Es conveniente aclarar que durante la ejecución de las demás actividades del desarrollo
los requerimientos pueden ser reformulados, así como pueden aparecer nuevos requerimientos.
Página 63
2.1.5. Definir los perfiles de usuario y su jerarquía
A partir de la obtención de los requerimientos es posible identificar los perfiles de

usuarios, llamados a menudo actores, y formar una jerarquía de acuerdo a la funcionalidad que
ofrecerá la aplicación para cada uno de ellos. Los actores que participan en el Sistema de
Administración de la Asignatura en su conjunto, son (ver Figura 12):
Administrador
Gestor de proyectos
Consultor de TFA
Gestor de alumnos
Gestor de exámenes
Gestor de resúmenes
Gestor de recursos
Usuario general
Alumno
El actor Usuario, en la parte superior de la jerarquía representa la categoría de usuario

administrativo más general, y es refinado niveles abajo. Para utilizar el sistema como alguna de
las subcategorías de Usuario es necesario especificar nombre y contraseña al ingresar al sistema,
por lo que este comportamiento se generaliza en el actor Usuario. Cada uno de estos roles que
especifican al Usuario gestiona un aspecto en especial del sistema, excepto el Administrador
que se encarga de todas estas funciones, así como de la creación de las cuentas de los usuarios
que pertenecen a los demás roles del nivel inferior. Por otra parte Alumno también requiere
autenticación para acceder al sistema, pero mediante su número de libreta universitaria y una
contraseña.
Página 64
Figura 12: Actores (perfiles de usuario) considerados en el Sistema de Administración de la Asignatura.
Los actores concernientes al Sistema de Publicación de Trabajos Finales son:
Usuario General: es aquel que accede a través de la Web sin contar con una cuenta
en el sistema. Sólo puede consultar los datos públicos de los trabajos.
Administrador: su función es crear las cuentas de usuario (con contraseña) de los

consultores de TFA.
Consultor de TFA: una vez iniciada la sesión especificando su nombre de usuario y

contraseña, puede acceder a todos los datos de los Trabajos Finales. Este rol
corresponderá normalmente a los docentes de la facultad.
2.2. Actividad de estudio de las tecnologías.
Si bien ésta no es una actividad de la Metodología Genexus ha sido incluida en este

trabajo, por considerarse en parte un trabajo de investigación y por su importancia para lograr
el objetivo de construir el sistema. El estudio de esta herramienta se encaró desde cero, ya que
no se había tenido contacto con ella en ningún momento durante el dictado de la carrera.
El material de estudio fue obtenido principalmente desde el sitio comercial de Genexus6

y desde el portal de acceso a recursos para usuarios Genexus: GXTechnical7, en forma de video
6 El sitio comercial de Genexus es: http://www.genexus.com/portal/hgxpp001.aspx?2
Página 65
tutoriales con ejemplos prácticos (Curso Básico Genexus X [AC09] y Curso Genexus X
[AC10]) y documentos en formato PDF ([AC08], [AC99]).
Este aprendizaje ha llevado un tiempo considerable, ya que Genexus tiene conceptos

muy particulares (como las transacciones y sus reglas) y no es parecido a ningún lenguaje de
programación de los ya estudiados. Tampoco se apega directamente a ninguno de los
paradigmas tradicionales, si bien utiliza la programación procedural e imperativa, en alguna
medida.
2.3. Actividad de Modelado
Se ha decidido dividir esta actividad en las fases separadas de análisis y de diseño, a

diferencia de lo propuesto por los creadores de la Metodología Genexus, en la cual son
realizadas en conjunto. El motivo de esta decisión es que se pretende hacer un análisis más
detallado del sistema, incluyendo adaptaciones de algunos diagramas UML, generalmente
utilizados en Análisis Orientado a Objetos.
2.3.1. Fase de Análisis
En la fase análisis se desarrollan diagramas para facilitar la comunicación en el equipo,

el entendimiento del problema, y la construcción del sistema. Particularmente se trabaja con
diagramas de casos de uso, de comunicación y de secuencia.
2.3.1.1. Construcción del diagrama de casos de uso.
Un diagrama de casos de uso representa la funcionalidad provista por el sistema a los

usuarios externos. Está compuesto por actores, nodos de caso de uso, relaciones y la
representación de los límites del sistema. La Figura 13 muestra el diagrama de casos de uso del
sistema de administración de la cátedra en su conjunto, mientras que la Figura 14 presenta el
diagrama particularizado del sistema de publicación de Trabajos Finales.
7 La dirección de GXTechnical es: http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,1,2,O,S,0,,
Página 66
Figura 13: Diagrama de casos de uso del Sistema de Administración de la Asignatura en su conjunto.
Página 67
Figura 14: Diagrama de Casos de Uso del Sistema de Publicación en particular.
2.3.1.2. Construcción de los diagramas de comunicación
Un diagrama de comunicación8 representa un comportamiento particular del sistema en

el que intervienen varios objetos. Estos diagramas están compuestos de objetos, sus vínculos y
8
El diagrama de comunicación reemplaza al diagrama de colaboración en la versión 2.0 de UML.
Página 68
los mensajes que se intercambian para definir el comportamiento. Un diagrama de

comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario
etiquetar los mensajes con números de secuencia. La explicación de los tipos de objetos
utilizados por Genexus, como los web panels, se presenta más adelante, en este trabajo.
En las Figuras 15 y 16, se presentan los diagramas de comunicación Nº 1 y 2,

respectivamente, correspondientes a la interacción con el Usuario General. En el primer caso,
este actor busca TFA por varios criterios (excepto por Orientadores) y luego obtiene
información de uno en particular. En el segundo, el mismo actor busca Trabajos Finales de
acuerdo a los Orientadores, y posteriormente consulta información particular de uno de los
resultados de la búsqueda. Como se ha mencionado, el usuario general es aquel que accede al
sistema a través de Internet sin especificar usuario ni contraseña.
Figura 15: Diagrama de comunicación Número 1 (interacción con el Usuario General).
Página 69
Figura 16: Diagrama de comunicación Número 2 (interacción con el Usuario General).
En las Figuras 17 y 18, se exhiben los diagramas de comunicación referidos a la

interacción del Consultor de TFA. En el primer caso, este actor busca Trabajos Finales de
acuerdo a múltiples criterios, en el segundo la búsqueda se realiza según los orientadores del
trabajo. Previamente este actor debe introducir su nombre de usuario y contraseña.
Página 70
Figura 17: Diagrama de comunicación Número 3 (interacción con el Consultor de TFA).
Figura 18: Diagrama de comunicación Número 4 (interacción con el Consultor de TFA).
Página 71
2.3.1.3. Construcción de los diagramas de secuencia
Un diagrama de secuencia representa una secuencia de intercambio de mensajes en el

tiempo, entre varios objetos para lograr un comportamiento particular. Permite comprender el
flujo de mensajes y de eventos que ocurren en un cierto proceso o colaboración.
Las Figuras 19 a 22 presentan los diagramas de secuencia, que se corresponden

respectivamente con los diagramas de colaboración expuestos anteriormente, es decir, los dos
primeros (Figuras 19 y 20) refieren a la interacción con el Usuario General, y los dos últimos
(Figuras 21 y 22) al Consultor de TFA.
En las Figuras 19 y 21 las transacciones Alumno, TipoTrabajo, Area y Proyecto se

agruparon en la entidad (Demás Transacciones) para simplificar el diagrama. Todas reciben el
mensaje Read(). Asimismo en las Figuras 21 y 22 las transacciones Usuario y TipoUsuario se
representan en una misma entidad.
Figura 19: Diagrama de secuencia Número 1 (interacción con el Usuario General).
Página 72
Figura 20: Diagrama de secuencia Número 2 (interacción con el Usuario General).
Figura 21: Diagrama de secuencia Número 3 (interacción con el Consultor de TFA).
Página 73
Figura 22: Diagrama de secuencia Número 4 (interacción con el Consultor de TFA).
2.3.2. Fase de Diseño
La fase de diseño incluye la creación de instancias de los objetos que Genexus provee
para representar la realidad, como por ejemplo las transacciones y los Web Panels.
2.3.2.1. Diseño de Transacciones
Esta es una tarea de fundamental importancia, ya que a partir de su realización se creará

la estructura de la base de datos. Se presenta en primer término la definición de la transacción
Profesional, y luego la de la transacción Proyecto.
Página 74
Figura 23: Estructura de la transacción Profesional.
La transacción Profesional cuenta con los atributos mostrados en la Figura 23. La

primera columna muestra el nombre de cada atributo, la segunda su tipo, la tercera una
descripción que será mostrada en pantalla para identificarlo, y finalmente la cuarta especifica si
se permiten valores nulos en dicho campo. Los atributos ProfesionalApellido,
ProfesionalNombre y ProfesionalEmail tienen como tipo de dato dominios previamente
creados (Apellido, Nombre y Email respectivamente). Se recomienda la creación de dominios
cuando un mismo tipo de dato sea utilizado para varios atributos. En la Figura 24 se observan
las definiciones de dominios.
Página 75
Figura 24: Definiciones de dominios utilizados (se incluyen dominios creados automáticamente y
creados por el analista)
A partir de la definición de la estructura de la transacción Profesional, Genexus crea el

formulario web de la Figura 25, implementando automáticamente las operaciones de alta, baja y
modificación de los datos.
Figura 25: Web form de la transacción Profesional.
Página 76
Posteriormente se define la transacción Proyecto en Genexus (Figura 26). Esta

transacción cuenta con un subnivel repetitivo llamado Profesional. Es decir, que para cada
proyecto habrá uno o más Profesionales. Estos profesionales tendrán un rol en dicho proyecto,
como coordinador, orientadores o jurados. Para un proyecto existen un coordinador, uno o dos
orientadores y dos jurados (estos últimos son cargados al emitirse la resolución
correspondiente). La estructura de la transacción Proyecto se utiliza en el Sistema de Gestión de
la asignatura para guardar información de la propuesta de Trabajo Final, y en el Sistema de
Publicación de Tesinas para difundir parte de sus datos una vez defendidos y aprobados los
trabajos.
La función de los atributos dentro de la transacción se representa mediante los

siguientes íconos:
Atributo clave principal.
Atributo descriptor, aquel que tiene mayor significado semántico para la transacción.
Atributo que actúa como clave foránea.
Atributo inferido, no se guardará en la tabla correspondiente con la transacción.
Atributo simple.
Figura 26: Estructura de la transacción Proyecto.
Página 77
La definición de la transacción Profesional da lugar a la creación de la tabla del mismo

nombre (ver Figura 27). Por otra parte la creación de la transacción Proyecto produce la
creación de dos tablas: Proyecto y ProyectoProfesional. La tabla Proyecto contiene los
atributos definidos en el nivel exterior de la transacción homónima, excepto aquellos que son
inferidos a partir de las relaciones con otras tablas, como AlumnoApellido y AlumnoNombre.
La tabla ProyectoProfesional tiene como campos los atributos creados en el subnivel de la
transacción Profesional, excepto los que pueden ser inferidos de otras tablas, como es el caso
de ProfesionalApellido y ProfesionalNombre. Al crear un subnivel Genexus interpreta que se
debe crear una nueva tabla, cuya clave compuesta estará formada por el o los atributos clave
principal (ProyectoId) del nivel externo así como el o los atributos del subnivel (ProfesionalId
en nuestro caso). Es conveniente aclarar que el modelo de datos presentado en la Figura 27 es
parcial, a fin de mostrar la correspondencia con las dos transacciones presentadas. El modelo
de datos completo se expone en la Figura 28.
Figura 27: Porción del modelo de datos que muestra las tablas creadas a partir de las transacciones
Profesional y Proyecto.
El sistema en su totalidad está compuesto las transacciones incluidas en la Tabla 3. La

definición de las estructuras de las transacciones se ha realizado para el Sistema de
Administración de la asignatura completo. A partir de éstas, la herramienta Genexus produce
Página 78
las sentencias SQL necesarias para crear la estructura de la base de datos, de acuerdo al DBMS
seleccionado.
Tabla 3: Correspondencia entre transacciones y tablas del modelo de datos.
Transacción Tabla creada

Alumno Alumno
AlumnoPracticos
AlumnoExamen
Area Area
Entrega Entrega
Examen Examen
Material Material
Práctico Práctico
Profesional Profesional
Proyecto Proyecto
ProyectoProfesional
Seguimiento Seguimiento
TipoTrabajo TipoTrabajo
TipoUsuario TipoUsuario
Usuario Usuario
Página 79
Figura 28: Modelo de datos completo. Las claves primarias se representan con el ícono y las claves
foráneas con círculo azul relleno.
2.3.2.2. Diseño de Web Panels
Esta tarea consiste en el diseño de las interfaces gráficas en formato web que componen
el sistema.
Página 80
La Figura 29 muestra el proceso de diseño de la interfaz (web form) del web panel
BuscarTrabajosFinales, el cual contiene, en su parte superior, una tabla que agrupa text blocks,
variables y combo boxs dinámicos, que actúan como criterios de filtrado; y un grid, en la parte
inferior, que presenta los datos de Trabajos Finales, orientadores y alumnos, cuando se
satisfacen las condiciones.
Figura 29: Vista en tiempo de diseño del Web Panel “BuscarTrabajosFinales”.
La Figura 30 presenta la vista de diseño del web panel BuscarPorOrientador que tiene
dos tablas, dos controles de tipo grid, varios text blocks y un control de tipo botón. El grid
superior se utiliza para mostrar los nombres de los orientadores que cumplen con la condición
de filtrado, y el grid inferior sirve para presentar los proyectos en los que trabaja dicho
coordinador, una vez se selecciona uno de los ellos, y se presiona el botón “Ver Trabajos
Finales”.
Página 81
Figura 30: Vista en tiempo de diseño del Web Panel “BuscarPorOrientadores”.
2.4. Actividad de Construcción o Producción
Esta actividad incluye las fases de codificación, prototipado, generación de la aplicación

y validación de la aplicación con datos reales.
2.4.1. Codificación
Esta tarea consiste en la implementación de las funcionalidades en la aplicación, las que

han sido identificadas en las actividades anteriores.
En Genexus, esta fase se realiza de dos maneras muy distintas, dependiendo de las
funcionalidades a implementar. La primera es la codificación declarativa, que consiste
simplemente en definir reglas a nivel de los objetos de Genexus. Esta característica es de muy
alto nivel ya que libera al analista de la necesidad de especificar cómo se debe realizar una
función del programa y tiene como ventaja principal un importante aumento de la
Página 82
productividad. A modo de ejemplo se cita la regla Error que despliega un mensaje en caso de
cumplirse una condición de error. Así la definición Error (‘No se permiten Trabajos Finales sin
título’) if ProyectoTitulo.isEmpty() evita que se cree un TFA sin indicar su título y muestra un
mensaje. Las reglas se definen en la solapa Rules de los objetos de Genexus.
El otro tipo de codificación es la programación procedural clásica. Para ello la

herramienta cuenta con un lenguaje propio, que posee instrucciones y estructuras similares a los
lenguajes de programación más difundidos. Este tipo de programación se especifica
generalmente dentro de eventos, para establecer su momento de ejecución.
2.4.2. Prototipado
La capacidad de generar prototipos de manera automática es una de las características

más importantes de Genexus. El prototipo se puede generar en un lenguaje de programación y
con un DBMS distinto al que será utilizado en el entorno de producción.
La función de prototipado se ha usado de manera intensiva en este desarrollo, ya que el

mismo ha incluido el aprendizaje de la tecnología por parte del alumno, es decir que se han
requerido muchas pruebas; y por supuesto por ser una de las mejores maneras de refinar los
requerimientos provistos por el cliente.
2.4.3. Validación de la aplicación con datos reales
Además de las pruebas realizadas mediante prototipos, en esta fase del desarrollo se
realizan pruebas con datos reales facilitados por la asignatura Trabajo Final de Aplicación.
En la validación del sistema de información se emplearon como datos la base de la

asignatura TFA y los resúmenes de los trabajos defendidos en el año 2009, compilados y
difundidos en Mariño et. al [MHV10].
2.4.4. Generación de la Aplicación
Una vez que el prototipo cumple correctamente con los requerimientos se procede a la
construcción de la aplicación que se utilizará en el ambiente de producción.
Página 83
Para esta actividad es necesario:
definir un nuevo Environment en Genexus, si es que no se utilizará en la fase de

producción el mismo usado para prototipado, y
especificar la interfaz principal de la aplicación que reemplazará al Developer

Menu de la fase de prototipado.
Como se ha mencionado, es posible generar la misma aplicación para entornos de

producción que trabajen con diferentes tecnologías, siempre que Genexus cuente con el
generador correspondiente y soporte el DBMS a utilizar.
Página 84
CAPITULO III
HERRAMIENTA UTILIZADA
Como se mencionó, el Sistema de Publicación de Trabajos Finales ha sido construido

con la herramienta Genexus. Por tal motivo en este capítulo se presenta un resumen de los
principales objetos provistos por este generador, y utilizados en el desarrollo del sistema, así
como una breve explicación de la capacidad de creación de prototipos de la herramienta.
3.1. Transacciones
Una transacción es un proceso interactivo con una interfaz (Interfaz Windows o Web)
que permite a los usuarios crear, modificar o eliminar información de la base de datos, es decir
implementa automáticamente los procesos de alta, baja y modificación de registros. Estas
diferentes operaciones se realizan en una misma interfaz, con un diseño atractivo, sin la
necesidad de acceder a un menú para hacer una u otra. Es a partir de la estructura de las
transacciones como Genexus infiere la organización de la base de datos relacional, siempre
llevando los datos a una representación en tercera forma normal, sin redundancias.
Los principales elementos de una transacción son:
Estructura: permite definir los atributos (campos) que componen la transacción y la

relación entre ellos. A partir de esta estructura, Genexus inferirá las tablas, claves, índices, etc.
de la base de datos. Ver Figuras 23 y 26.
Web Form: es la interfaz con la que interactúa el usuario. Cada transacción contiene un
Web Form (pantalla) mediante el cual se realizarán las altas, bajas y modificaciones en ambiente
Web. Las transacciones y otros objetos poseen un Web Form predeterminado, pero siempre es
posible agregar otros controles de usuario, variables y atributos a ser mostrados en pantalla, etc.
En ambientes Windows en lugar del Web Form se utiliza el Win Form. Ver Figura 25.
Reglas: las reglas permiten definir el comportamiento particular de las transacciones.

Por ejemplo, permiten definir valores por defecto para los atributos, definir chequeos sobre los
datos, etc. El hecho de posibilitar la especificación de este comportamiento de manera
declarativa es considerado una ventaja de Genexus con respecto a los lenguajes de
Página 85
programación tradicionales. Otro uso frecuente de las reglas es para especificar los parámetros
de entrada y salida que posee un objeto Genexus.
Eventos: las transacciones soportan la programación orientada a eventos. Este tipo de

programación permite definir código ocioso, que se activa en respuesta a ciertas acciones
provocadas por el usuario o por el sistema.
Variables: posibilita la definición de variables que serán locales a la Transacción.
Ayuda: permite la inclusión de texto de ayuda, para ser consultado por los usuarios en
tiempo de ejecución de la transacción.
Documentación: provee la posibilidad de la inclusión de texto técnico, para ser

utilizado como documentación del sistema.
Patrones: son componentes prediseñados para aplicar funcionalidades específicas a las

transacciones sin requerir programación por parte del usuario. Los patrones se implementan
mediante Web Panels. El patrón incluido en Genexus más conocido es Work With, el cual
permite aplicar fácilmente filtros, órdenes e interfaces gráficas prediseñadas para acceder a los
datos.
Propiedades: Permiten definir ciertos detalles referentes al comportamiento de la

transacción.
3.2. Web Panels
Los Web Panels son objetos Genexus que permiten al usuario realizar consultas
interactivas a la base de datos a través de una interfaz en tiempo de ejecución. Son flexibles, por
lo que se prestan para múltiples usos.
Los siguientes elementos, ya explicados para las transacciones, también se utilizan en los
Web Panels: Web Form, reglas, eventos, variables, ayuda, documentación y propiedades.
Además el Web Panel cuenta con el elemento Condiciones, que permite definir filtros que
deben cumplir los datos a ser tratados en dicho Web Panel.
El diseño de un web panel consiste en crear su interfaz con los controles provistos por
Genexus, como text blocks, tables, grid, etc. y las variables a ser utilizadas para entrada y/o
salida de datos en pantalla (Ver Figuras 29 y 30). Posteriormente en la solapa Events se
introduce el código necesario, siguiendo el modelo de eventos proporcionado por este
Página 86
generador. Al tratarse de un desarrollo para ambiente Web, existen una secuencia de eventos
predeterminada que se ejecuta al producirse un GET o un POST al servidor Web. Además
algunos tipos de controles tienen eventos característicos, como el evento Load de un grid (que
permite cargarlo con datos), y otros controles permiten la definición de eventos de usuario. La
codificación se realiza en un lenguaje propio de Genexus, permitiendo luego la generación de
código en varias tecnologías, y la utilización de distintos DBMS.
En los web panels la solapa Rules (reglas) generalmente se utiliza para definir los
parámetros de entrada y/o salida necesarios, mediante la regla Parm. Por ejemplo la definición
Parm(in:&ProyectoId, in:&TabCode) del web panel VerTrabajoFinal, indica dos parámetros de
entrada: ProyectoId y TabCode. En esta solapa solo pueden incluirse reglas de manera
declarativa, es decir, no se permite código procedural.
Un web panel puede ser definido como Web Component mediante su propiedad Type,
con el fin de permitir que sea utilizado dentro de los web forms de otros web panels o
transacciones, así como por separado. El objetivo de esta característica es permitir la
reutilización de la interfaz y el comportamiento del web panel.
3.3. Capacidad de Prototipado
Para crear un prototipo solamente es necesario configurar un Environment (entorno)

en Genexus, el que está compuesto por uno o más generadores (por ejemplo Ruby, C#, Java) y
por uno o más DBMS (SQLServer, MySQL, etc.) representados bajo el nombre de Data Stores
(almacenes de información) (Ver Figura 31). Al trabajar en ambiente Web (propiedad que se
configura al crear la base de conocimiento) es necesario tener instalado además un servidor web
(Internet Information Services, Apache, etc. de acuerdo al generador elegido).
Al elegir la opción Run Developer Menu (o presionar F5) del menú Build se procede a
la especificación, y posteriormente la generación de código, de los objetos contenidos en la base
de conocimiento que hayan sufrido modificaciones desde la última especificación/generación.
Al terminar este proceso se ejecuta el prototipo de la aplicación, para evaluar su desempeño,
iniciándose el Developer Menu. El Developer Menu, o menú del desarrollador, es una interfaz
web creada por Genexus para permitir al programador probar los objetos creados sin necesidad
de armar previamente la aplicación completa.
Página 87
Figura 31: Configuración de entornos en Genexus.
Página 88
CAPITULO IV:
UN SISTEMA DE PUBLICACIÓN DE TESINAS DE GRADO
En este capítulo se exponen las características principales de la aplicación desarrollada,

presentando sus interfaces, y el modo de funcionamiento. Primeramente se presentan las
correspondientes a los usuarios pertenecientes al perfil Usuario General, y luego las utilizadas
por los usuarios incluidos en el perfil Consultor de TFA. Las interfaces correspondientes a este
segundo actor se distinguen en pantalla por la leyenda “Modo Docente”.
4.1. Utilización por parte del Usuario General
La Figura 32 muestra la interfaz principal de la aplicación en la que se cuenta con dos

controles de tipo Grid (grilla) para listar los trabajos más visitados (grilla superior) y los trabajos
más recientes (grilla inferior). Además, para estos trabajos, es posible la descarga de su resumen
sintético de manera directa. Por tratarse de una sesión de un Usuario General las acciones del
Modo Docente se encuentran deshabilitadas.
Página 89
Figura 32: Interfaz principal de la Aplicación.
Las Figuras 33 y 34 muestran las interfaces utilizadas para la búsqueda de Trabajos

Finales. La primera permite buscar aplicando diversos criterios, y la segunda hallar trabajos de
acuerdo a los profesores orientadores.
Página 90
Figura 33: Interfaz de búsqueda por distintos criterios para el Usuario General.
Página 91
Figura 34: Interfaz de búsqueda por orientadores, para el Usuario General.
Las Figuras 35 y 36 presentan las interfaces de información del Trabajo Final y de sus
orientadores (mediante pestañas). Obsérvese que sólo se muestran los datos más generales del
trabajo y del orientador.
Página 92
Figura 35: Interfaz de Información del TFA para el Usuario General.
Página 93
Figura 36: Interfaz de Información de los orientadores del TFA para el Usuario General.
4.2. Utilización por parte del Consultor de TFA
En la Figura 37 se presenta la interfaz principal, en la que el Consultor de TFA debe

introducir su nombre de usuario y contraseña. En la Figura 38 se observa la habilitación de las
opciones del “Modo Docente” una vez validado el usuario.
Página 94
Figura 37: Interfaz principal de la Aplicación al momento de ingresar Usuario y Contraseña.
Página 95
Figura 38: Interfaz principal de la Aplicación, con las opciones del Modo Docente habilitadas.
Las Figuras 39 y 40 exhiben las interfaces de búsqueda, por distintos criterios en el

primer caso, y por orientadores en el segundo. Obsérvese que se permiten más criterios de
búsqueda ya que el usuario con perfil Consultor de TFA tiene acceso a mayor cantidad de
información de los trabajos.
Página 96
Figura 39: Interfaz de búsqueda por distintos criterios para el Consultor de TFA.
Página 97
Figura 40: Interfaz de búsqueda por orientadores, para el Consultor de TFA.
Las Figuras 41 y 42, muestran las interfaces de Información del TFA y de los
profesionales (orientadores, jurados y coordinador) que intervienen de alguna manera en el
Trabajo Final. Por tratarse de una interfaz para el Consultor de TFA se exhibe toda la
información del TFA, así como la correspondiente con los jurados y el coordinador, a
diferencia de las interfaces para el Usuario General.
Página 98
Figura 41: Interfaz de Información del TFA para el Consultor de TFA.
Página 99
Figura 42: Interfaz de Información de los orientadores, coordinador y jurados del TFA para el
Consultor de TFA
Página 100
CAPITULO V:
CONCLUSIONES
En este trabajo se han cumplido con los objetivos de construir un Sistema de

Publicación de los Trabajos Finales de Aplicación de las carreras Licenciatura en Sistemas y
Licenciatura en Sistemas de Información, así como colaborar en el análisis del Sistema de
Gestión Integral de dicha Asignatura.
El Trabajo Final de Aplicación tiene como objetivo primordial “lograr la aplicación e

integración de los conocimientos adquiridos durante el transcurso de la carrera”. Por este
motivo, se ha considerado fundamental dotar a la cátedra que guía su concreción, de un sistema
de gestión integrado que mejore el tratamiento de toda la información referente a la asignatura.
Particularmente, el Sistema de Publicación de los TFA colabora en la divulgación del

conocimiento, propósito primordial de la Universidad. Es importante destacar que favorece
además a la región ya que desde la asignatura se hace énfasis en desarrollar trabajos aplicables al
medio, los que ahora se hacen accesibles para otros actores de la comunidad.
En cuanto a la construcción de los sistemas se ha hecho hincapié en: evaluar y aplicar

metodologías modernas de desarrollo de software, utilizar tecnologías adecuadas para el tipo de
desarrollo propuesto, facilitar la interacción con el usuario mediante interfaces intuitivas y
homogéneas y garantizar la protección de la información mediante la creación de perfiles de
usuario.
En lo personal, la realización ha permitido la utilización de diversos conocimientos

adquiridos durante el transcurso de la carrera, así como el entendimiento de cuestiones del
desarrollo de software que se presentan en la realidad, como el trabajo coordinado en equipo,
los cambios circunstanciales de los requerimientos, y la necesidad del estudio profundo de
distintas tecnologías y metodologías de desarrollo.
Como líneas de trabajo futuras surgen las siguientes propuestas:
• La posibilidad de ayudar al alumno en la elección de su tema de TFA puede

fortalecerse promoviendo desde el sistema de publicación la obtención de información
sobre posibles temas de desarrollo. De esta manera otros actores del medio, como las
empresas, propondrían desarrollos de acuerdo a sus necesidades, y en algunos casos
Página 101
sería posible establecer comunicación entre estas organizaciones y alumnos en busca de

una temática para la construcción de su TFA.
• La utilización del Sistema de Publicación podría extenderse a otras carreras de la

Universidad que cuenten con Trabajos Finales, tesinas o de tesis para su conclusión.
• Avanzar hacia la construcción de un Almacén de Datos (Data Warehouse) que sirva

como soporte para obtener conocimiento útil mediante técnicas especiales, por
ejemplo minería de datos.
Página 102
REFERENCIAS BIBLIOGRÁFICAS
[AC08] ARTech Consultores S.R.L. (2008). “Visión General de Genexus”. ARTech.

Uruguay. Disponible en :
http://www.genexus.com/portal/agxppdwn.aspx?2,61,1006,O,S,0,22791%3bS%3b1%3b
2315, Fecha de consulta: Abril de 2010.
[AC09] ARTech Consultores S.R.L. “Curso Genexus X”. Disponible en:

http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,5,296,O,S,0,MNU;E;66;1;MNU
;, Fecha de consulta: Mayo de 2010.
[AC10] ARTech Consultores S.R.L. “Curso Genexus X”. Disponible en:

http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,5,298,O,S,0,MNU;E;38;33;MN
U;, Fecha de consulta: Abril de 2010.
[AC99] ARTech Consultores. (1999). “Genexus: Diseño de Aplicaciones”. ARTech.

Uruguay. Disponible en:
http://www.exa.unicen.edu.ar/catedras/modysim/tutoriales/manual_de_genexus.pdf
Fecha de consulta: Abril de 2010.
[BL04] Baño, A., Lasso, A. (2004). “Proceso Unificado. Un Caso Práctico”. Disponible en:
http://www.microsoft.com/Argentina/conferencias_tecnicas/download/ProcesoUnifica
do.PPT Fecha de consulta: Abril de 2010.
[C08] Chacon, J. M. (2008). “Modelo Metrica 3”. Disponible en:

http://juanmarcosteoria2.blogspot.com/2008/01/modelo-metrica3.html Fecha de
consulta: Abril de 2010.
[CLP05] Canós, J. H., Letelier, P., Penadés, M. C. (2005). “Metodologías Ágiles en el

Desarrollo de Software”. DSIC – Universidad Politécnica de Valencia. España.
[DP06] Delgado, A., Pérez, B. (2006) “Modelo de Desarrollo de Software OO”. Grupo de
Ingeniería de Software. Universidad de la República. Uruguay. Disponible en:
http://www.fing.edu.uy/~bperez/public/ModOOJIISIC.pdf Fecha de consulta: Abril de
2010.
Página 103
[EJ01] Etayo, A. M., Jodal, N. (2001) “Genexus: Simplificando lo Complejo”. Uruguay.

Disponible en:
http://www.microsoft.com/spanish/msdn/spain/eventos/descargas/talleres/GeneXus
Microsoft.ppt Fecha de consulta: Abril de 2010.
[GJ07] Gonda, G., Jodal, N. (2007). “Desarrollo Basado en Conocimiento: Filosofía y

Fundamentos Teóricos de Genexus”. ARTech. Uruguay. Disponible en:
http://www.genexus.com/portal/agxppdwn.aspx?2,61,1006,O,S,0,22885%3bS%3b1%3b
2315, Fecha de consulta: Abril de 2010.
[GJ09] Gonda, B., Jodal, N. (2009). “Genexus: Filosofía”. ARTech. Uruguay. Disponible en:
http://inti.browse.cl/gxpfiles/site001/design/style000001/00000000050000000747.pdf
Fecha de consulta: Abril de 2010.
[GJS96] Gonda, B., Jodal, N., Santo, K. (1996) “Desarrollando y Manteniendo Grandes
Aplicaciones Corporativas con Genexus”. ARTech. Uruguay. Disponible en:
http://genexus.es/documentos/pub/ARTech%20Desarrollo%20y%20manto%20de%20
grandes%20aplicaciones.PDF Fecha de consulta: Abril de 2010.
[MHV10] Mariño, S. I., Herrmann, C. F y Vanderland, M. A. (2010). “Avances en el

desarrollo de un catálogo digital de resúmenes de los Trabajos Finales de
Aplicación de la FaCENA – UNNE. Cohortes 2005-2009”. Revista Quaderns
Digitals. Aceptado para su publicación. Disponible en:
http://www.quadernsdigitals.net/index.php?accionMenu=hemeroteca.VisualizaArticuloI
U.visualiza&articulo_id=10944 Fecha de consulta: Junio de 2010.
[MET] Ministerio de la Presidencia, Gobierno de España. “Métrica Versión 3:

Introducción.” España. Disponible en:
http://www.csi.map.es/csi/metrica3/introduccion.pdf Fecha de consulta: Abril de 2010.
[MT09] M&T Consulting. (2009). “Capability Maturity Model Integration (CMMI)”.

Disponible en: http://www.myt.com.pe/principal/Eva_CMMi.php Fecha de consulta:
Abril de 2010.
Página 104
[P04] Pérez, B. (2004). “GXP – Adaptación y Aplicación de eXtreme Programming”.

Grupo de Ingeniería de Software. Universidad de la República. Uruguay. Disponible en:
http://www.fing.edu.uy/~bperez/public/GXP.pdf Fecha de consulta: Abril de 2010.
[P05] Pressman, R. S. (2005). “Ingeniería de Software: Un Enfoque Práctico”. Sexta

Edición. Ed. Mac Graw Hill. España.
[PB06] Pedrana Murolas, M., Bellini Pazos, M. (2006). “Proceso Modularizado Unificado y
Medible”. Instituto de Computación. Universidad de la República. Uruguay. Disponible
en: http://www.fing.edu.uy/~bperez/grado/Informe_final-Bellini-Pedrana.doc Fecha
de consulta: Abril de 2010.
[PB07] Pedrana Murolas, M., Bellini Pazos, M. (2007). “Sitio del Proceso Modularizado
Unificado y Medible”. Instituto de Computación. Universidad de la República.
Uruguay. Disponible en:
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/proceso/MUM/index.htm Fecha de
consulta: Abril de 2010.
[PBP06] Pedrana, L., Bellini, M., Pérez, B. (2006). “MUM - Proceso de Desarrollo de
Software Modularizado, Unificado y Medible”. Instituto de Computación.
Universidad de la República. Uruguay. Disponible en:
http://www.fing.edu.uy/~bperez/public/Proceso%20de%20desarrollo%20de%20Softw
are%20Modularizado%20Unificado%20y….pdf Fecha de consulta: Abril de 2010.
[PIS07] Proyecto de Ingeniería de Software. (2007). “Listado de Modelos de Proceso”.

Instituto de Computación. Universidad de la República. Uruguay. Disponible en:
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/procesos.htm Fecha de consulta: Abril
de 2010.
[T02] Torossi, G. (2002) “El Proceso Unificado de Desarrollo de Software”. Universidad

Tecnológica Nacional. Argentina. Disponible en:
http://www.chaco.gov.ar/UTN/disenodesistemas/apuntes/oo/ApunteRUP.pdf Fecha
de consulta: Abril de 2010.
[VA06] Villagra, S., Axentia (2006). “White Paper: Una Introducción a CMMI”. Disponible
en:
Página 105
http://www.sergiovillagra.com/Contenidos/Recursos/WP03%20Una%20Introduccion
%20a%20CMMI.pdf Fecha de consulta: Abril de 2010.
Página 106

Stma de Publicación de Tesinas (En Genexus)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Stma de Publicación de Tesinas (En Genexus)

Caricato da

Copyright:

Formati disponibili

Universidad Nacional del Nordeste

Facultad de Ciencias Exactas, Naturales y Agrimensura.

TRABAJO FINAL DE APLICACION

Diseño de un Sistema de Información

Autor: Luis Fernando Dellamea Liva

Profesora Orientadora: Mgter. Sonia I. Mariño.

Profesor Coordinador: Agr. Castor Herrmann.

A mi familia, por el apoyo incondicional que me ha brindado.

La asignatura Trabajo Final de Aplicación establece las condiciones para la elaboración

Este informe expone el diseño y desarrollo de un Sistema de Publicación de

1.1. Introducción a las Aplicaciones Web. 13

1.2. Presentación de la Herramienta Genexus. 17

1.3. Estudio de Metodologías de Desarrollo de Software. 24

1.3.2.1.4. Consideraciones sobre Metodologías Ágiles . 44

CAPÍTULO II: METODOLOGÍA. 62

2.1. Actividad de Comunicación y Planeación. 62

2.2-Actividad de estudio de las tecnologías. 65

2.4. Actividad de Construcción o Producción. 82

CAPITULO III: HERRAMIENTA UTILIZADA. 85

3.2. Web Panels. 86

3.3. Capacidad de Prototipado. 87

CAPITULO IV: UN SISTEMA DE PUBLICACIÓN DE TESINAS DE GRADO. 89

4.1. Utilización por parte del Usuario General. 89

4.2. Utilización por parte del Consultor de TFA. 94

CAPITULO V: CONCLUSIONES. 101

REFERENCIAS BIBLIOGRÁFICAS. 103

Figura 1: Forma de trabajo de Genexus. 18

Figura 29: Vista en tiempo de diseño del Web Panel “BuscarTrabajosFinales”. 80

Tabla 1: Tecnologías soportadas por Genexus. 19

Se expone el diseño y desarrollo de un Sistema de Publicación de Trabajos Finales

La aplicación ha sido construida con el generador de código Genexus. Se mencionan

En el presente informe se expone el diseño y desarrollo de un Sistema de Publicación

Para la construcción de este sistema se han tenido en cuenta los conceptos de la

El sistema ha sido construido con la herramienta Genexus, especializada en desarrollo

Se han estudiado varias metodologías con el propósito de compararlas y elegir la más

La primer metodología investigada, el Proceso Modularizado, Unificado y Medible

La segunda metodología revisada consiste en Programación Extrema adaptada a

La Metodología Genexus, propuesta por los creadores de la herramienta, describe las

La actividad de comunicación y planeación incluye definir el objetivo del sistema,

La actividad de estudio de las tecnologías incluye la búsqueda de material técnico

La actividad de modelado incluye las fases de Análisis, Diseño y Prototipado. En la

Una vez corregidos los errores del prototipo se comienza la actividad de

En el último capítulo se exponen las características principales de la aplicación

Como conclusión se puede mencionar que Genexus ha resultado apto para la

En el marco del proyecto de la cátedra Trabajos Finales de Aplicación (TFA) de la

1.1. INTRODUCCIÓN A LAS APLICACIONES WEB

Se conoce como Aplicaciones Web (o WebApps) a aquellas aplicaciones que los

Las aplicaciones web son populares debido a la ubicuidad de los navegadores y su

Las WebApps generan dinámicamente y a petición, páginas en un formato estándar,

1.1.1. Características de las Aplicaciones Web

En la mayoría de las WebApps se encuentran las siguientes características, si bien

Concurrencia: el número de usuarios que acceden al mismo tiempo a la aplicación

Desempeño: el usuario puede ser muy exigente en cuanto a esta característica en

Disponibilidad: al estar disponible al mundo entero, no existen horarios en los que

Orientación al multimedia: una gran parte de las aplicaciones deben soportar

Evolución continua: en numerosas WebApps el contenido se actualiza de manera

1.1.2. Estructura de las aplicaciones web

1.1.3. Ingeniería Web

En Pressmann [P05] se define a la Ingeniería Web (IWeb) como la aplicación de

Los grandes cambios que ha presentado la web en años recientes ha impuesto la

1.2. PRESENTACIÓN DE LA HERRAMIENTA GENEXUS

En Genexus, la diferencia entre prototipado y producción es que la primera se hace

En el proceso de desarrollo de software existen tareas que son susceptibles de ser