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

Página 1

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



Página 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

� 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 16

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 17

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 18

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 19

Tabla 1: Tecnologías soportadas por Genexus (Fuente: [AC08])

Plataformas

Plataformas de ejecución:

Java, Microsoft .NET, Microsoft .NET Compact Framework

Sistemas Operativos:

IBM OS/400, LINUX, UNIX, Windows NT/2000/2003 Server,

Windows NT/2000/XP/CE/Vista/7

Internet:

Java, Ruby, ASP.NET, Visual Basic (ASP), C/SQL, HTML, Web

Services

Bases de Datos IBM DB2 for iSeries y UDB, Informix, Microsoft SQL Server,

MySQL, Oracle y PostgreSQL.

Lenguajes JAVA, C#, COBOL, RPG, Visual Basic.

Servidores Web Microsoft IIS, Apache, WebSphere, etc.

Múltiples

Arquitecturas

Arquitecturas de múltiples capas, basadas en web, Cliente/Servidor,

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 20

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 21

� 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 22

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 23

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 24

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 25

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 26

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 27

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 28

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 29

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 30

� 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 31

� 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 32

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 33

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 34

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 35

� 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 36

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 37

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 38

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 39

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 40

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 41

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 42

� 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 43

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 heurísticas de prácticas de producción de código

Basadas en normas provenientes de estándares seguidos por el entorno del

desarrollo

Especialmente preparados para cambios durante el proyecto

Cierta resistencia a los cambios

Impuestas internamente (por el equipo)

Impuestas externamente

Proceso menos controlado, con pocos principios

Proceso mucho más controlado, con numerosas políticas normas

No existe contrato tradicional o al menos es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo

El cliente interactúa con el equipo de desarrollo mediante reuniones

Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio

Grupos grandes y posiblemente distribuidos

Pocos artefactos Más artefactos

Pocos roles Más roles

Menos énfasis en la arquitectura de software

La arquitectura del software es esencial y se expresa mediante modelos



Página 44

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 45

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 46

� 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 47

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 48

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 49

� 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 50

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 51

� 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 52

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 53

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 54

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 55

� 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 56

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 57

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 58

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 59

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 60

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 61

� 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 62

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 63

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 64

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 65

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 66

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 67

Figura 13: Diagrama de casos de uso del Sistema de Administración de la Asignatura en su conjunto.



Página 68

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 69

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 70

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 71

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 72

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 73

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 74

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 75

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 76

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 77

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 78

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 79

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 80

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 81

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 82

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 83

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 84

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 85

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 86

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 87

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 88

Figura 31: Configuración de entornos en Genexus.



Página 89

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 90

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 91

Figura 33: Interfaz de búsqueda por distintos criterios para el Usuario General.



Página 92

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 93

Figura 35: Interfaz de Información del TFA para el Usuario General.



Página 94

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 95

Figura 37: Interfaz principal de la Aplicación al momento de ingresar Usuario y Contraseña.



Página 96

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 97

Figura 39: Interfaz de búsqueda por distintos criterios para el Consultor de TFA.



Página 98

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 99

Figura 41: Interfaz de Información del TFA para el Consultor de TFA.



Página 100

Figura 42: Interfaz de Información de los orientadores, coordinador y jurados del TFA para el

Consultor de TFA



Página 101

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 102

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 103

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 104

[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 105

[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 106

http://www.sergiovillagra.com/Contenidos/Recursos/WP03%20Una%20Introduccion

%20a%20CMMI.pdf Fecha de consulta: Abril de 2010.

stma de publicación de tesinas (en genexus)

Documents