Indice general

PRESENTACION

6

1. Antecedentes 1.1. Antecedentes del Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Fases precursoras del SITEM . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 9

1.2.1. Sistema de Informacin para Telemedicina Fase I . . . . . . . . . . . . 11 o 1.2.2. Sistema de Informacin para Telemedicina Fase II . . . . . . . . . . . 12 o 1.2.3. Sistema de Informacin para Telemedicina Fase III . . . . . . . . . . . 14 o

2. Contexto Terico o

16

2.1. Telemedicina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.1. Componentes Tecnolgicos de los Sistemas de Telemedicina . . . . . . . 17 o 2.2. Marco Legislativo y Normativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.1. En el Ambito de los Servicios Mdicos . . . . . . . . . . . . . . . . . . . 21 e 2.2.2. En el Ambito del Desarrollo de Redes Teleinformticas . . . . . . . . . . 23 a 2.3. Ingenier de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 a 2.3.1. Proceso de Desarrollo del Software . . . . . . . . . . . . . . . . . . . . . 25

1

2.3.2. Principios de Diseo y Desarrollo . . . . . . . . . . . . . . . . . . . . . . 26 n 2.3.3. Proceso de Desarrollo de Software de Cdigo Abierto . . . . . . . . . . . 28 o 2.4. UML: Lenguaje de Modelado Unicado . . . . . . . . . . . . . . . . . . . . . . 37 2.5. Portales de Informacin y Conocimiento . . . . . . . . . . . . . . . . . . . . . . 38 o 2.5.1. Benecios y obstculos para la implementacin de portales basados en a o aplicaciones web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.5.2. Ciclo de Vida de los Portales . . . . . . . . . . . . . . . . . . . . . . . . 40 2.5.3. Aplicaciones Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.6. Aspectos Claves en la Gestin y Direccin del Conocimiento . . . . . . . . . . . 43 o o 2.6.1. Acerca del conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.6.2. Ciclo de Conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.6.3. Tecnolog del Conocimiento . . . . . . . . . . . . . . . . . . . . . . . . 45 as 2.6.4. Gestin de conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 o

3. Sistema de Informacin para Proyectos de Telemedicina o

51

3.1. Caracter sticas innovadoras del SITEM . . . . . . . . . . . . . . . . . . . . . . . 53 3.2. Arquitectura del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.2.1. Subsistema Entidades de Salud . . . . . . . . . . . . . . . . . . . . . . . 54 3.2.2. Subsistema Tecnolog de Interconexin . . . . . . . . . . . . . . . . . . 54 as o 3.2.3. Subsistema Equipos y Tecnolog as . . . . . . . . . . . . . . . . . . . . . 56 3.2.4. Subsistema Operadores de Telecomunicaciones . . . . . . . . . . . . . . 56 3.2.5. Subsistema Organizaciones y Proyectos . . . . . . . . . . . . . . . . . . 57 3.2.6. Subsistema Servicios Mdicos . . . . . . . . . . . . . . . . . . . . . . . . 57 e 3.2.7. Subsistemas Entornos de Aprendizaje . . . . . . . . . . . . . . . . . . . 57 2

3.3. Aspectos Relativos a la Fase de Transicin . . . . . . . . . . . . . . . . . . . . . 59 o 3.3.1. Fuentes de Informacin Primaria . . . . . . . . . . . . . . . . . . . . . . 61 o

4. Desarrollo del SITEM

63

4.1. Modelos de Desarrollo del SITEM . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.1. Modelo de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.1.2. Modelo de Anlisis y Diseo a n . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1.3. Modelo de Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . 70 o 4.1.4. Modelo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.1.5. Interfaz grca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 a 4.1.6. Entregables del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A. Declaracin de Riesgos o

93

B. GNU General Public License

97

B.1. PREAMBULO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.2. TERMINOS Y CONDICIONES PARA COPIA, MODIFICACION Y DISTRIBUCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

C. Modelo de Requisitos

104

C.1. Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 C.1.1. Caracter sticas Generales de los Actores . . . . . . . . . . . . . . . . . . 104 C.1.2. Casos de Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

D. Modelo de Anlisis y Dise o a n

114

D.1. Especicaciones de Casos de Usos . . . . . . . . . . . . . . . . . . . . . . . . . . 114

3

E. Modelo de Implementacin o

126

E.1. Cdigo Fuente del SITEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 o E.1.1. Clase Pgina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 a

F. Modelo de Datos

130

G. Modelo de Despliegue

132

H. Instrumento Preliminar para la Fase de Transicin o H.1. Presentacin o

134

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

H.1.1. Indicaciones Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 H.1.2. Contexto Cl nico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 H.1.3. Contexto de servicio / relacin con el entorno . . . . . . . . . . . . . . 137 o H.1.4. Consideraciones Tecnolgicas . . . . . . . . . . . . . . . . . . . . . . . . 139 o H.1.5. Consideraciones de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . 141 H.1.6. Aceptacin del servicio de salud brindado en la modalidad de telemedicina142 o H.1.7. Aspectos de Construccin y Persistencia del sistema de telemedicina . . 143 o H.1.8. Pol ticas de la Organizacin . . . . . . . . . . . . . . . . . . . . . . . . . 144 o H.1.9. Consideraciones acerca de la informacin . . . . . . . . . . . . . . . . . 145 o H.1.10. Procesamiento de informacin . . . . . . . . . . . . . . . . . . . . . . . . 146 o

I. Otros Entregables Nucleares del SITEM

147

I.1. Visin - Resumen Ejecutivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 o I.1.1. I.1.2. Propsito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 o Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

4

I.1.3. I.1.4. I.1.5. I.1.6. I.1.7. I.1.8. I.1.9.

Posicionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Participantes en el Proyecto y Usuarios . . . . . . . . . . . . . . . . . . 149 Entorno de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Suposiciones y dependencias . . . . . . . . . . . . . . . . . . . . . . . . . 151 Descripcin Global del SITEM . . . . . . . . . . . . . . . . . . . . . . . 151 o Otros Requisitos del Producto . . . . . . . . . . . . . . . . . . . . . . . 151 Lineamientos de codicacin para la organizacin de los mdulos . . . . 152 o o o

J. Manual Bsico de Usuario a

153

5

PRESENTACION

Lejos ya del delirio inicial que foment la incursin del tema de la Telemedicina en los pa o o ses subdesarrollados, en donde muchos la conceb como panacea para la problemtica en el an a cubrimiento y la calidad de los servicios de salud prestados a la poblacin, con un mayor o aplomo y madurez terica prctica se implementa la tercera fase de desarrollo del Sistema o a Integrado de Informacin en Telemedicina. Es claro que la equidad en la prestacin o o de servicios de salud va ms all del mero despliegue de redes de telecomunicaciones y debe a a involucrar cambios, que evidentemente se estn presentando, en la legislacin, las prcticas, a o a mtodos operativos, la educacin y la integracin multidimensional de nodos humanos, tcnie o o e cos y tecnolgicos en las denominadas redes de telemedicina de tercera generacin. o o En los ultimos aos el diseo, desarrollo e implementacin de pol n n o ticas innovadoras en el rea a de la prestacin de servicios de salud perjudiciales o no, ha logrado que las instituciones y o entidades optimicen sus procesos para el manejo y la gestin eciente de los recursos mdicos, o e nancieros y operativos. Sin embargo, las reglas que fomentan la competencia entre prestadoras de servicios de salud genera que, en busca del ideal benecio del usuario, se segregue la condicin humana en aras de una mayor rentabilidad. o El presente documento contiene los resultados obtenidos en el desarrollo del proyecto: Sistema Integrado de Informacin en Telemedicina, intentando abarcar con enfoque hol o stico su evolucin conceptual, terica y arquitectnica. En la tercera fase el sistema transciende de o o o la dimensin tcnica, y se consolida como un modelo para el desarrollo de soluciones costo o e efectivas en el rea de la telesalud, la administracin de servicios mdicos y la telemedicina. a o e

Lilia Edith Aparicio Pico Grupo de Investigacin en Telemedicina o Universidad Distrital Francisco Jos de Caldas e

6

Cap tulo 1

AntecedentesA partir de los estudios realizados por el Grupo de Investigacin en Telemedicina de la o Universidad Distrital Francisco Jos de Caldas [Gonzlez y Torres,2002] [Guarin et al,2003] e a [Duque et al,2002] [Ardila,2001], se detectaron algunas necesidades y obstculos para el dea spliegue de redes de telemedicina[Aparicio-Ramirez,2003]. La imposibilidad de tener una caracterizacin de los componentes de las redes de telemedicina, unido al bajo nivel de conciencia o en el gobierno de las entidades de salud con respecto a las posibilidades de la telemedicina y la telesalud, pusieron de maniesto la necesidad de socializar los hallazgos y buscar un mecanismo para integrar a profesionales interesados en el desarrollo de estas disciplinas en el pa s. En el ao 2005, GITEM propuso el proyecto para la denicin de un modelo de gestin de n o o conocimiento que permitiera preservar y socializar, de forma innovadora para la institucin, o las experiencias y conocimiento adquirido por el grupo. Para tal efecto se inicia la elaboracin o del modelo de gestin que contribuya a potenciar los ciclos de integracin, creacin, reproo o o duccin y diseminacin del conocimiento. En el ao 2008, el modelo se concreta en el portal o o n piloto especializado SITEM KM, cuyos subsistemas implementan los componentes principales. A partir de esa fecha y fruto de un proceso de mejora continua, el modelo y por ende el portal, se han depurado para renar sus caracter sticas.

1.1.

Antecedentes del Dominio

El estudio preliminar de diagnstico desarrollado por el grupo de investigacin GITEM, ten o o a en mente problemas puntuales para la implementacin de servicios mdicos prestados a travs o e e de medios teleinformticos en el Distrito Capital [Aparicio,2000]: a

En el momento no existe un diagnstico real sobre los servicios requeridos en o 7

el rea de telemedicina, razn suciente para iniciar un trabajo de campo que a o establezca la situacin actual de servicios mdicos y la demanda real, as como la o e posibilidad de conocer a corto, mediano y largo plazo cules ser los costos de a an inversin que permitir dar soluciones al problema de cobertura. o an La socializacin del conocimiento alrededor de las tecnolog aplicadas al desaro as rollo de la medicina, es uno de los valores que lleva al xito de soluciones efectivas e en el sector salud, por tal motivo es necesario desarrollar un plan de alfabetizacin o en el sector salud y en el sector gubernamental y acadmico. e En el pa no existen estrategias de investigacin en esta rea del conocimiento s o a para llevar a cabo un estudio real que permita dar el paso a soluciones verdaderas sobre desarrollo tecnolgico o experimental para poder implementar centros de o investigacin en Telemedicina. o La Universidad Distrital tiene el recurso humano, el conocimiento y la experiencia cient ca y tecnolgica, capaz de dar soluciones tangibles a estas necesidades; o unida al conocimiento y experiencia de entidades como cl nicas y hospitales y con la participacin de operadores de comunicaciones, puede desarrollar soluciones o efectivas a los problemas de salud que afronta la sociedad colombiana.

El estudio creo la necesidad de nuevos proyectos que permitieran aprovechar y diseminar ecientemente los resultados obtenidos. As para brindar una estructura formal a la docu, mentacin, brindar un acceso eciente de entidades al estudio, y gestionar los riesgos asociados o a la complejidad en la generacin estudios comparativos o de apoyo a la toma de decisiones, o se cre al interior del grupo un proyecto de grado denominado Sistema de Informacin o o en Telemedicina que en sus primeras fases de desarrollo dio solucin parcial, al marcar las o pautas hacia la integracin de informacin para el GITEM. Con este proyecto tambin se o o e presentaron adelantos en el tema del desarrollo de software distribuido e interoperable basado en la losof del software libre[Coronado y Galindo,2005]. a De forma paralela el grupo de investigacin implement, en convenio con Colciencias, el o o Sistema de Referencia y Contrarreferencia para el Distrito Capital, utilizando herramientas de desarrollo propietarias espec camente el middleware .NET de Microsoft con lo que el grupo adquiri experiencia en la desarrollo de aplicaciones siguiendo metodolog para la o as construccin de software. Junto con estos proyectos se desarrolla la ctedra en el rea de o a a Telemedicina, ofrecida como seminario inscrito dentro del plan de estudios de la Maestr en a Ciencias de la Informacin y las Comunicaciones, lo que ha fomentado el inters investigativo o e y la formacin de profesionales especializados. Esto contribuy a la construccin de nuevos o o o saberes en la materia que se demuestra en la cantidad creciente de proyectos asociados a la l nea de investigacin. o

8

1.2.

Fases precursoras del SITEM

En un primer acercamiento el proyecto de investigacin se puede asociar a un holotipo o proyectivo[Hurtado,2000] cuyo estadio actual se ha logrado a partir de actividades investigativas que abordan distintos aspectos de la proyeccin, en la dimensin tecnolgica, de los o o o sistemas de Telemedicina. La idea fundamental que siempre ha guiado el proyecto es la de generar un proceso iterativo basado en la construccin y deconstruccin gradual, hermenutio o e co e incremental de un sistema informtico que apoye las labores de consultor y diseo de a a n redes Telemdicas ahondando de forma as e ncrona en cada uno de sus diferentes componentes. El proyecto tiene como particularidad tener que cumplir con ambiciosas metas de desarrollo con reducidos recursos tcnicos y nancieros los cuales deben ser administrados dentro de e un ambiente de alta regulacin burocrtica. El escenario comn ha sido el bajo tiempo de o a u permanencia de los integrantes, la ejecucin constante de tareas de capacitacin, el uso ino o tensivo de tecnolog de la comunicacin, el teletrabajo y la escasa interaccin persona a as o o persona. El SITEM inicialmente ten que ser de calidad, econmico y desarrollado rpia o a damente. Pero teniendo en cuenta lo que [Larman,2003] nos citaba: Rpido, barato, bueno: a elija dos cualquiera; con los pies rmemente puestos en el suelo, dejando a un lado las fuertes esperanzas, deb amos sacricar un aspecto y el unico que se dispon era la rapidez en que a versiones estables del proyecto habr de ver la luz - los conceptos fundamentales de desaran rollo de aplicaciones de software libre aportar varias claves para minimizar el impacto de an este sacricio. Con esto como patrn fundamental el grupo de desarrollo plantea un modelo general en donde o los objetivos de producir datos, consumir informacin y compartir conocimiento en el rea de o a inters ser alcanzado en varias fases1 de las cuales se describen los alcances de aquellas que e a han culminado. La gura 1.1 muestra el proceso de estructuracin de un sistema de telemedicina como una o sucesin de fases que generan las dimensiones de datos, informacin y conocimiento de un o o grupo de componentes dado. El sistema visto como un holos presenta al investigador una gran cantidad de datos que en la medida que se descubren, recolectan, observan y registran se van convirtiendo en informacin susceptible de ser descrita, analizada, integrada y comparada o acercndose cada vez ms a un conocimiento renado. El carcter de discernible - el momento a a a en que las dimensiones se solapan en grado sumo, se evidencia con el aumento colectivo de especializacin en la materia y en nuestro caso, con el grado de inmersin de los usuarios en o o el SITEM. En el transcurso de las fases solo se manejan ciertos aspectos que incremental y constructivamente se suman para crear un modelo cada vez ms exacto del sistema con base en las a diferentes mrulas de datos, informacin y conocimiento generadas. Aunque en el grco se o o a muestra un tanto discretos y exactos, los l mites existentes entre las tres mrulas principales oA travs del presente documento se utilizan los trminos de fase en el proceso investigativo y fases del e e Proceso de Desarrollo del Sistema Software. Las dos se suponen diferentes y su interpretacin e importancia o estn asociados al contexto en el que se ubican. a1

9

Figura 1.1: Aproximacin incremental a un sistema de Gestin de Conocimiento o o

10

- datos, informacin, conocimiento; son en la realidad difusos. Esto diculta la consecucin o o del objetivo de cada fase que es tratar de profundizar en uno o varios componentes del holos - conseguir especicidad en el modelo. Si se consideran los aspectos meramente tcnicos del SITEM se corre el riesgo inminente de e diseminacin en regiones poco profundas del sistema - dispersin en la mrula de datos - razn o o o o por la cual la herramienta software se ha convertido en un artefacto intermedio y no en el n ultimo de la investigacin. o

1.2.1.

Sistema de Informacin para Telemedicina Fase I o

Con la primera fase de desarrollo del SITEM se logr un conocimiento amplio de los como ponentes de las redes de telemedicina y sus interrelaciones basado en una investigacin exo ploratoria y descriptiva realizada por los integrantes del grupo GITEM. Tambin se determinaron las caracter e sticas esenciales de diferentes portales que implementaban en cierto grado la funcionalidad esperada para el SITEM vislumbrando con este estudio la necesidad de crear un producto software adaptado a las necesidades del entorno distrital, teniendo en cuenta que ninguno de los portales analizados brindaba acceso a informacin pero tinente, conable, actualizada y estructurada en torno a las redes de telemedicina en idioma espaol. n La cuestin fundamental que se resolvi en esta fase fue la denicin de un modelo para la o o o estructuracin y administracin de informacin relevante para los participantes en el diseo, o o o n anlisis y desarrollo de las redes de Telemedicina. Adems se deni un modelo de negocios a a o que lograba mostrar las interrelaciones que tendr el sistema con los proyectos del grupo y a un conjunto representativo de portales relacionados temticamente; encontrando un costo de a oportunidad adecuado. En la actualidad dicho modelo de negocios cobra mayor vigencia con la tendencia generalizada de desmonte de inversin en los portales ms importantes a nivel o a mundial siendo quizs ipath, tambin basado en la losof del software libre, uno de los a e a unicos que continan activos y en crecimiento, demostrando de paso que el esquema propuesto u - gestionado ecientemente, es adecuado para el desarrollo y mantenimiento de sistemas de esta clase. Al momento de desarroll de esta fase el grupo de investigacin no contaba ni siquiera con un o o portal web por lo que la arquitectura propuesta incluy al portal del grupo como un subsistema o del SITEM compartiendo de esta forma tanto la plataforma tecnolgica como el modelo o conceptual, lo que difumin un poco los alcances reales del Sistema y su implementacin no o o pas de ser un prototipo de baja funcionalidad. o Los alcances y logros efectivos de esta fase fueron:

Descripcin del Modelo de Negocio. o 11

Propuesta de Desarrollo Creacin de la Arquitectura general del Sistema. o Desarrollo del sitio web del grupo GITEM e integracin conceptual del SITEM dentro o de los proyectos del grupo. Elaboracin de los Modelos bsicos de Requisitos, anlisis y diseo. o a a n Estudios sobre losof de Software Libre. a Construccin de un Prototipo de baja funcionalidad conocido como SITEM versin 0.1, o o bautizada internamente como Kauil.

1.2.2.

Sistema de Informacin para Telemedicina Fase II o

Los modelos de requisitos, anlisis y diseo de la primera fase sirven de base para proponer a n arquitectura general para el Sistema de Informacin para Proyectos de Telemedicina y con o el inicio de la segunda fase se emprenden las actividades necesarias para la construccin de o los componentes de software que concretaban dicha arquitectura. Para poder minimizar los riesgos asociados al proyecto se adapt el Proceso Unicado de Desarrollo de Software a o las especicidades de desarrollo del Sistema, lo que favoreci efectivamente su elaboracin, o o implementacin, mantenimiento y crecimiento. o La arquitectura general se vio poco afectada pero cada uno de los subsistemas componentes fueron ms nadamente caracterizados resultando en un modelo de anlisis y diseo mejor a a n denido que integraba elementos no tratados en la fase inicial. Debido a la naturaleza del SITEM, el grupo de investigacin decide separar los hilos de desarrollo del Sistema y del o proceso de estructuracin del sitio web del grupo. El SITEM por primera vez se puede acceder o desde Internet gracias al despliegue que se realiza sobre la plataforma de hardware y software brindada por la Universidad Distrital. En esta fase se realiza el modelado de datos y se esbozan las primeras rutinas de manejo se seguridad. Para la construccin de componentes se utilizan herramientas de software libre y o el grupo de desarrollo aumenta a cinco integrantes. El trabajo se encuentra, con excepcin o del director del proyecto, soportado y ejecutado por estudiantes de pregrado del proyecto curricular de Ingenier Electrnica convirtindose en el primer proyecto de desarrollo a o e de software libre realizado por el GITEM e involucra la formacin transdisciplinar de o un grupo de sus integrantes. Los alcances de esta fase fueron: Arquitectura Mejorada del Sistema Modelo depurado de Requisitos 12

Figura 1.2: Fases transcurridas en el desarrollo del SITEM

13

Modelo de Anlisis - Segunda Versin a o Modelo de Diseo n Construccin de Componentes software soportado en su totalidad por herramientas de o software libre. Diseo de Interfaz Grca n a Versin estable 1.0 y bautizada internamente como Gucumatz. o Adaptacin del Proceso Unicado de Desarrollo de Software a las especicidades del o SITEM. Conguracin de la plataforma tecnolgica de despliegue del sistema. o o Al nal de la fase se obtiene un aplicativo que presenta avances en todos los subsistemas propuestos.

1.2.3.

Sistema de Informacin para Telemedicina Fase III o

El almacn de datos obtenido en la segunda fase aunque interesante es poco funcional cuando e se trata de aplicar directamente al apoyo de la implementacin de soluciones basadas en o software telemdico. Estos proyectos presentan retos adicionales en la medida que deben pasar e por procesos de consultor complejos y costosos que muchas entidades de salud pblicas son a u incapaces de costear. Otros riesgos estn asociados a la desinformacin que injusticada y a o deliberadamente mantiene la empresa privada en cuanto a que con software libre no se siguen buenas prcticas de desarrollo de software, ni se obtienen sistemas seguros que garanticen la a integridad de los datos - conceptos totalmente alejados de la realidad que pueden minar el juicio objetivo de administradores mdicos no especializados en telemedicina - y mucho menos e en teleinformtica, en cuanto a la posibilidad de alcanzar sistemas ecientes y ecaces sin la a inversin de exorbitantes sumas de dinero. o Es comn encontrar en el mbito colombiano casos de xito de aplicaciones telemdicas en u a e e entidades de salud privadas pero son escasas las aplicaciones en entidades pblicas de segundo u o tercer nivel. Evidentemente el uso, promocin y difusin de software libre es una prctica o o a necesaria para poder implementar aplicaciones con altos niveles de calidad que benecien al grueso de la poblacin. o SITEM en esta fase genera una herramienta que ordena la informacin lgicamente y pero o mite su acceso personalizado en reas del conocimiento que tienen inferencia sobre las redes a de telemedicina: medicina bsica, tecnolog de interconexin, equipos de telemedicina, ina as o stituciones de salud, entidades prestadores de servicios de telecomunicaciones, entre otras; as mismo integra una serie de servicios en l nea que propenden por la consolidacin de una o comunidad en Telemedicina basada en Internet, gura 1.3 .

14

Figura 1.3: Sistema de Informacin para proyectos de Telemedicina. Interfaz de Usuario en la o Fase III Se consolida un proceso de desarrollo de software adaptado a las especicidades del grupo de investigacin el cual trata de extraer lineamientos de las prcticas mundialmente aceptadas de o a procesos y mtodos como son el Proceso Unicado, Mtrica 5, Normas de Calidad ISO 9000 y e e EFQM. Se trata de buscar el aseguramiento de la calidad en el desarrollo, la interoperabilidad, escalabilidad y el uso extensivo de software libre. Se documenta todas las etapas involucradas en la creacin de la aplicacin para que sirva de plantilla a sistemas relacionados y se formaliza o o las reas de capacitacin a partir de ciclos genricos de transferencia de conocimiento apoyados a o e en tecnolog de la informacin. as o

15

Cap tulo 2

Contexto Terico oNo son los aspectos tcnicos para la creacin de sistemas de informacin los que distinguen e o o al SITEM sino las nuevas estructuras de informacin -y su correlacin, las que brindan una o o novedad en el contexto de la proyeccin de soluciones en Telemedicina. El presente cap o tulo provee la base terica que sustenta dichas estructuras y relaciones, abordando el marco lego islativo y dems temticas que son necesarias para caracterizar los componentes primordiales a a de los Sistemas de Telemedicina. Teniendo en cuenta el caracter evolutivo del proyecto software y como referencia para posteriores desarrollos soportados en el SITEM, tambin se tratan cuestiones relevantes al proceso e de ingenier que gui el anlisis, diseo y elaboracin del sistema. a o a n o

2.1.

Telemedicina

La Telemedicina [AIM,1993], [Bashshur,1977], [BDT,1999] se ha convertido rpidamente en un a concepto que extiende sus raices etimolgicas. El Ministerio de Proteccin Social colombiano o o con la Resolucin 1448 del 8 de mayo de 2006 dene a la Telemedicina como: o la provisin de servicios de salud a distancia, en los componentes de promocin, o o prevencin, diagnstico, tratamiento o rehabilitacin, por profesionales de la salud o o o que utilizan tecnolog de la informacin y la comunicacin, que les permiten as o o intercambiar datos con el propsito de facilitar el acceso de la poblacin a servicios o o que presentan limitaciones de oferta, de acceso a los servicios o de ambos en su a rea geogrca. a Es por tanto un campo multidisciplinar que integra componentes de diferentes reas del saber a que incluye entre otros a la medicina, la ingenier electrnica, la telemtica, la informtica, a o a a 16

la ingenier de sistemas, la inteligencia articial, la binica, la sicolog la sociolog y la a o a, a antropolog Las redes actuales de Telemedicina consideran elementos que van mucho ms alla a. a del simple despliegue de redes tecnolgicas de intercomunicacin y evidentemente se plantean o o como redes de interaccin social cuyo objetivo primario - ms no el unico, es la prestacin de o a o servicios mdicos apoyadas en las TIC. e Dependiendo el grado en que se presente cada uno de los elementos mostrados en la gura 2.1 y de la mayor o menor correlacin entre ellos, se pueden crear sistemas de Telemedicina o que se acerquen al ideal de proveer servicios de salud de alta calidad. Dichos sistemas, aunque dinmicos y evolutivos, debern mantener una estructura nuclear cuyas propiedades generales a a son segn [Bashshur,1995]: u 1. Separacin geogrca entre el proveedor y el cliente durante un encuentro cl o a nico o entre dos o ms proveedores. a 2. Utilizacin de tecnolog informticas y de comunicaciones para realizar la interaccin. o as a o 3. Equipo humano/tcnico de gestin del sistema. e o 4. Desarrollo de una infraestructura organizacional. 5. Desarrollo de protocolos cl nicos para orientar a los pacientes hacia diagnsticos y fuentes o de tratamiento apropiados. 6. Normas de comportamiento que reemplazan las normas del comportamiento presenciales. La Telemedicina es catalogada siguiendo bsicamente criterios de [Salazar,2002]: sincronizacin a o temporal entre el proveedor y el cliente -diferida o en tiempo real; servicios de salud que se presten [Aparicio,2000] - consulta, diagnstico, atencin, seguimiento, educacin, adminiso o o tracin, etc; o especialidad mdica que se trate - radiolog patolog cardiolog dermao e a, a, a, tolog etc. La catalogacin siempre es independiente de la red tecnolgica y de comunicaa, o o ciones sobre la cual se despliegue.

2.1.1.

Componentes Tecnolgicos de los Sistemas de Telemedicina o

La fase actual del SITEM se centra en dos conjuntos bsicos de componentes de los sistemas a de Telemedicina, los mdicos y los tecnolgicos. Debido al perl de profesionales que han e o participado en el desarrollo, los elementos tecnolgicos han sido mejor caracterizados hasta el o momento. Para efectos de facilitar su anlisis y modelado, en la dimensin puramente tecnolgica, un a o o sistema de Telemedicina puede reducirse a cuatro subsistemas [Aparicio-Ramirez,2003]:

17

Figura 2.1: Elementos genricos y reas del saber de una red de Telemedicina e a

18

Figura 2.2: Subsistemas Tecnolgicos Bsicos en un Sistema de Telemedicina o a

19

Captura de datos: Conformado por los dispositivos de hardware, los protocolos y aplicaciones software que trabajan conjuntamente para transformar informacin mdica o e en datos susceptibles de ser administrados usando tcnicas digitales. e Transmisin de Datos: Hacen parte de este subsistema los dispositivos de hardware, o las tecnolog de interconexin, los protocolos y aplicaciones que permiten estructurar as o redes de transmisin de datos digitales de una manera able en tiempos aceptables para o un servicio espec co. Gestin de Informacin: Dispositivos de hardware - computadores, sistemas de almao o cenamiento masivo, etc; y sistemas de informacin que almacenan, procesan, distribuyen o y analizan la informacin proveniente de los subsistemas de captura de datos. o Despliegue de informacin: Elementos de hardware (pantallas, transductores, siso temas de audio, etc), aplicaciones software y protocolos asociados que permiten recibir y reproducir la informacin mdica. o e

Todos ellos necesariamente interrelacionados por medio de interfaces y protocolos denidos; El uso de estndares abiertos es de vital importancia para permitir que los sistemas de Telemedica ina puedan ser interoperables, esto se ha logrado en gran medida en el subsistema de transmisin de datos pero an se encuentran serios problemas en los dems subsistemas debido al o u a sinnmero de patentes y protocolos propietarios que las empresas fabricantes de dispositivos u mdicos an ostentan. e u

2.2.

Marco Legislativo y Normativo

El SITEM es un sistema que gestiona informacin sobre diferentes reas del saber estando la o a mayor de ellas reguladas en un marco jur a dico concreto o por medio de estndares y normas a de conocimiento, uso extendido y de facto aceptado en el mundo. La informacin del SITEM o debe ser de acceso pblico por lo que no podr incluirse ningn tipo de informacin que u a u o est protegida por derechos de autor[Ley 565,2000],[Ley 23,1982] que restrinjan su difusin. e o De forma anloga debido a que el SITEM es un proyecto de software libre ha de ceirse en todo a n momento a la normatividad expresada en [Ley 565,2000],[Ley 44,1993],[Dec 1360,1989] para garantizar que todos los aspectos tanto tcnicos como conceptuales son de dominio pblico e u o, en el caso de aquellos inditos, estn debidamente registrados. En la actualidad el grupo e a GITEM cursa el requerimiento para obtener el registro correspondiente del software. La relacin puntual de la normatividad trasciende el objetivo del presente documento siendo o descritas a continuacin solo aquellas que ms incidencia han tenido en el modelado del o a sistema.

20

2.2.1.

En el Ambito de los Servicios Mdicos e

El Derecho a la Salud ha sido reconocido por normas y pactos internacionales contenidos en tratados sobre Derechos Humanos, Econmicos, Sociales, y Culturales (DHESC) y raticados o por Colombia para su cumplimiento y exigibilidad como un derecho meritorio por cualquier ciudadano. La Corte Constitucional; ha sealado que el inciso segundo del art n culo 93 de la Carta Pol tica conere rango constitucional a todos los tratados de derechos humanos, econmicos, sociales y culturales, raticados por Colombia y referidos a derechos que ya o aparecen en la Carta[Corte1319,2001] como ocurre con el Derecho a la Salud. Al Ministerio de la Proteccin Social - antes Ministerio de la Salud, le corresponde expedir o las normas tcnicas y administrativas de obligatorio cumplimiento para las Entidades Promoe toras de Salud del rgimen contributivo, las Instituciones Prestadoras de Salud del Sistema e General de Seguridad Social en Salud, las Administradoras del Rgimen Subsidiado y para las e Direcciones Seccionales, Distritales y Locales de Salud en cuanto al objetivo de cumplimiento en el desarrollo de actividades de proteccin espec o ca, deteccin temprana y atencin de o o enfermedades de inters en Salud Pblica. e u A continuacin se registra la normatividad que se tuvo en cuenta al momento de denir o los componentes actuales del subsistema de servicios mdicos en cuanto a la relevancia que e se tiene tanto para la proyeccin de nuevas redes de telemedicina como para el apoyo de o sistemas bsicos ya existentes. Es de anotar que lo contemplado en las leyes nacionales es en a su mayor derivado de normas internacionales las que han sido objeto de detallados estudios a y reconocidas tcnicamente con base en las experiencias vividas por los profesionales de esta e a rea.

Resolucin 2182 de julio 9 de 2004 Con esta resolucin se den las Condiciones de o o an Habilitacin para las instituciones que prestan servicios de salud bajo la modalidad de o Telemedicina. Fue derogada por el art culo 11 de la resolucin 1043 de 2006, con o la cual se establecen las condiciones que deben cumplir los Prestadores de Servicios de Salud para habilitar sus servicios e implementar el componente de auditor para el a mejoramiento de la calidad de la atencin y se dictan otras disposiciones. o Posteriormente, con la Resolucin 1448 de 8 de Mayo de 2006 se regula la prestacin o o de servicios de salud bajo la modalidad de telemedicina y establece las condiciones de habilitacin de obligatorio cumplimiento para las instituciones que prestan servicios de o salud. Es en esta resolucin que aparece la denicin aceptada en el presente documento o o para Telemedicina. Esta resolucin aclara que las actuaciones de los mdicos en el ejero e cicio de la prestacin de servicios bajo la modalidad de telemedicina se sujetarn a las o a disposiciones establecidas en la Ley 23 de 1981 y dems normas que la reglamenten, a modiquen, adicionen o sustituyan. Resolucin 1896 de noviembre 19 de 2001 Con esta resolucin el Ministerio de Salud o o Ahora Ministerio de Proteccin Social, adopta una Clasicacin Unica de Procedimieno o tos en Salud (CUPS) la cual ...corresponde a un ordenamiento lgico y detallado de o 21

los procedimientos e intervenciones que se realizan en Colombia, identicados por un cdigo y descritos por una nomenclatura validada por los expertos del pa independio s, entemente de la profesin o disciplina del sector salud que los realice as como del mbito o a de realizacin de los mismos. La utilizacin adecuada de sta clasicacin es de gran o o e o ayuda para estandarizar los datos que consolidan el Sistema Integral de Informacin, o proveer un lenguaje homogneo entre los diferentes integrantes del Sistema General de e Seguridad Social en Salud -SGSSS-, facilitando tanto la denicin de Planes de Beno ecios y sus alcances como el seguimiento del desempeo del sector bajo parmetros n a de comparacin.[MINSALUD-1896,2001]. La Clasicacin Unica de Procedimientos en o o Salud adaptacin para Colombia, se adopta por Resolucin 365 de 1999. Su primera o o publicacin se presenta en un solo volumen que contiene la Lista Tabular y el o Indice Alfabtico. A partir de dicha resolucin se realiz la primera actualizacin de la CUPS e o o o (1 A-CUPS) adoptada mediante la Resolucin 2333 de 2000. o Resolucin 1830 de junio 23 de 1999 adopta para Colombia, Las codicaciones unicas o de especialidades en salud, ocupaciones, actividades econmicas y medicamentos eseno cialespara el Sistema Integral de Informacin del SGSSS - SIIS o Resolucin 1895 de noviembre 19 de 2001 por la cual se adopta para la codicacin de o o morbilidad en Colombia, La Clasicacin Estad o stica Internacional de Enfermedades y Problemas Relacionados con la Salud - Dcima revisin. e o Considerando que en la 43a. Asamblea Mundial de la Salud llevada a cabo en 1990, fue aprobada por la Conferencia Internacional la Clasicacin Estad o stica Internacional de Enfermedades y Problemas Relacionados con la Salud Dcima revisin -, (CIE-10) en la cual Colombia no expres objeciones y e o o adquiri el compromiso de implementarla. Resuelve Adoptar para la codio cacin de morbilidad en Colombia, la Clasicacin Estad o o stica Internacional de Enfermedades y Problemas Relacionados con la Salud -Dcima revisin-, e o contenida en la publicacin cient o ca No.554 de la Organizacin Panamerio cana de la Salud, presentada en tres volmenes: V1. Lista de Categor V2 u as; Manual de Instrucciones; V3 Indice Alfabtico. e Resolucin 1995 de julio 8 de 1999 por la cual se establecen normas para el manejo de o la Historia Cl nica. La Historia Cl nica es un documento de vital importancia para la prestacin de los sero vicios de atencin en salud y para el desarrollo cient o co y cultural del sector, es un documento privado, obligatorio y sometido a reserva, en el cual se registran cronolgicao mente las condiciones de salud del paciente, los actos mdicos y los dems procedimientos e a ejecutados por el equipo de salud que interviene en su atencin. Dicho documento unicao mente puede ser conocido por terceros previa autorizacin del paciente o en los casos o previstos por la ley. Circular 015 de abril 4 de 2002 estndar de historias cl a nicas y registros, establece la obligatoriedad de denir procedimientos para utilizar una historia unica institucional. Ello implica que la institucin cuente con un mecanismo para unicar la informacin de o o cada paciente y su disponibilidad para el equipo de salud. No es restrictivo en cuanto 22

al uso de medio magntico para su archivo, y s es expreso en que debe garantizarse e la condencialidad y el carcter permanente de registrar en ella y en otros registros a asistenciales. Decreto 2092 de 2 de Julio de 1986 , Por el cual se reglamenta parcialmente los T tulos VI y XI de la Ley 09 de 1979, en cuanto a la elaboracin, envase o empaque, o almacenamiento, transporte y expendio de Medicamentos, Cosmticos y Similares. Se e dan las Disposiciones Generales y Deniciones, el Registro Sanitario de Medicamentos, Cosmticos y Similares. e

2.2.2.

En el Ambito del Desarrollo de Redes Teleinformticas a

Documento CONPES 3072 Aunque no es una norma regulatoria, es una declaracin oo cial del gobierno colombiano acerca de la necesidad de fomentar las Tecnolog de la as Informacin para potenciar la absorcin, creacin y divulgacin del conocimiento por o o o o medio del desarrollo sostenible en las infraestructuras f sica, de informacin y social. o Segn [CONPES3072,2000]: ... para que el pa pueda ofrecer un entorno econmico u s o atractivo y participar en la econom del Conocimiento, resulta indispensable desarrollar a una sociedad en la que se fomente el uso y aplicacin de las Tecnolog de la Informao as cin. A travs de estas Tecnolog se puede efectuar un salto en el desarrollo en un o e as, tiempo relativamente breve, mucho menor del que se necesita para superar el dcit de e infraestructura f sica.. El documento CONPES brinda un referente vlido pues la mayor de los objetivos a a estratgicos del SITEM contienen el esp e ritu expresado en diferentes partes del mismo. Resolucin 087 de 1997 Por medio de la cual se regula en forma integral los servicios de o Telefon Pblica Bsica Conmutada (TPBC) en Colombia. En donde claramente se a u a expresa que: Los servicios de TPBC debern ser utilizados como instrumento para impulsar a el desarrollo pol tico, econmico y social del pa con el objeto de elevar el nivo s el y la calidad de vida de los habitantes en Colombia. Los servicios de TPBC sern utilizados responsablemente para contribuir a la defensa de la democa racia, a la promocin de la participacin de los colombianos en la vida de la o o Nacin y la garant de la dignidad humana y de otros derechos fundameno a tales consagrados en la Constitucin Pol o tica, y para asegurar la convivencia pac ca. Esta resolucin presenta particular importancia para la extraccin de elementos semntio o a cos y algunos componentes necesarios en las redes de telecomunicaciones basadas en telefon conmutada. Algunas heur a sticas usadas en el subsistema de consultor tambin a e se basan en apartes de esta resolucin. o Manual de Calidad de Servicio Con este Manual de calidad de servicio (QoS) se especican los parmetros de calidad de servicio de red que permiten el suministro de servicios a a los clientes y los usuarios, satisfaciendo sus expectativas de calidad de servicio. Estos 23

parmetros tienen que ver tanto con la implementacin del servicio como con su utia o lizacin continua. Asimismo, la calidad de servicio se relaciona con todos los aspectos o relativos a la evaluacin y gestin de las redes.[ITU-T, 2004] o o Sus principales aspectos son recogidos en [CRT,QoS,2006] y [CRT,Indicadores,2006] las cuales sirven de base para el proyecto de resolucin[CRT,QoS,2007] de la Comisin de o o Regulacin de Comunicaciones y que especica entre otros: las deniciones relativas a o la QoS, parmetros de medicin, variables y propiedades tcnicas de diferentes enlaces. a o e Aunque el objetivo principal de este manual es el de garantizar la QoS en un sistema de telecomunicaciones dado es importante notar que sus indicaciones deben ser tenidas en cuenta al momento de proyectar los servicios de telecomunicaciones en un sistema de telemedicina dado. En estos aspectos tambin se considera dentro del modelado e de ciertos componentes del SITEM las recomendaciones de la UIT en [G1000, 2001] y [G1010, 2001], las cuales an no tienen un equivalente en la normatividad colombiana u pero son de uso extendido alrededor del orbe.

2.3.

Ingenier de Software a

A medida que el marco conceptual del SITEM crece, el cmulo de nuevos requerimientos u no vislumbrados en su planteamiento inicial, fomenta que los riesgos asociados al desarrollo de los componentes tambin crezcan. Lo que en un principio no era ms que una herramiene a tapara la administracin del acervo documental fruto de una investigacin, se convirti en o o o una propuesta de sistema de informacin y conocimiento que supon un reto novedoso al o a interior del grupo de investigacin. o Es evidente que se deben sumar nuevos saberes para procurar manejar formalmente el proceso de elaboracin del sistema: un punto inicial y obligado de estudio se centr en la ingenier o o a de software. Como rama de la ingenier comparte la denicin fundamental que de la misma brind a a o o mediados del siglo pasado el Consejo de Ingenieros para el Desarrollo Profesional ECPD, por sus siglas en ingls; y que en general propone que: e Ingenier Es la aplicacin creativa de principios cient a o cos para el diseo o desarrollo de n estructuras, mquinas, aparatos, procesos de manufactura o sistemas genricos, para ser a e usados de forma independientemente o combinados; o la construccin y operacin de los o o mismos con total conocimiento de su diseo; o el pronstico de su comportamiento bajo n o ciertas condiciones de operacin; todo aquello respecto a una funcionalidad esperada o asegurando econom en el manejo de los recursos y con seguridad para la vida y la a propiedad.11

Adaptacin de la denicin hecha por los autores. o o

24

Se concibe entonces a la ingenier de software como la aplicacin de los principios de ina o genier a los sistemas de software con base a un acercamiento sistemtico, cuanticable a a y disciplinado del desarrollo. operacin y mantenimiento de software[IEEE, 1990]; y ciertao mente se fundamenta en actividades interrelacionadas, propias del ser humano cognosciente y creativo que en [Brugge, Dutoit, 2000] se identican como:

Actividades de Modelado: Para abstraer la complejidad del dominio del problema en unidades factibles de ser objeto de estudio y anlisis. En este contexto las nociones de a contratos funcionales e independencia conceptual juegan un rol importante. Se pretende con estas actividades obtener modelos de anlisis - como representaciones relativamente a simples de la realidad y modelos de diseo - como representaciones del dominio de la n solucin de un problema dado, representado con un modelo de anlisis. o a Actividades de Resolucin de problemas: Siendo la ingenier de software un proo a ceso guiado de bsqueda de solucin a un problema espec u o co del ser humano que es viable de ser apoyado por sistemas software. Se concibe actualmente como un proceso investigativo que, de acuerdo a un acercamiento hol stico, contempla ujos de trabajo continuos y evolutivos de exploracin, descripcin, anlisis, comparacin, explicacin, o o a o o prediccin, proposicin, modicacin, conrmacin y evaluacin o o o o o Actividades de Adquisicin de conocimiento: Durante el desarrollo del sistema o software el ingeniero, a partir de un modelo constructivista, recrea constantemente su conocimiento tcito a partir de las nuevas experiencias y el mayor conocimiento del a dominio del problema as como de los diferentes paradigmas usados en la consecucin o de soluciones ptimas. En realidad el ingeniero, as como los dems actores que intero a vienen con el sistema, ven revalidados o reformados sus conocimientos a medida que los requerimientos son cumplidos y los riesgos minimizados.

Tambin contempla actividades propias de trabajo colaborativo que producen integracin e o de saberes en ambientes inter, trans y multidisciplinarios, lo que potencia efectivamente la creacin de ciclos de conocimiento que contribuyen al renamiento continuo del sistema o como objeto perfectible, y del conocimiento directo, que tanto del sistema como del proceso, tienen los actores vistos como sujetos perfectibles, racionales y cognoscientes; dentro de una dinmica de retroalimentacin entre el sujeto que crea el sistema y el sistema mismo. a o

2.3.1.

Proceso de Desarrollo del Software

Un proceso de desarrollo de software puede ser visto como el conjunto de actividades que deben realizar un grupo de personas para dar solucin - mediante un sistema software- a un o problema cuyas caracter sticas y condiciones de resolucin han sido especicadas. El producto o nal, el software, es un sistema o sea un conjunto de componentes funcionales que se relacionan por medio de interfaces denidas logran el objetivo comn de solucionar los problemas u determinados. 25

Para determinar el proceso ms apropiado segn las necesidades y especicidades del proyecto a u 2 centrada en diferentes modelos ampliamente aceptados en el se condujo una metodolog a campo de la ingenier de software que al nal dio lugar a un proceso consolidado de gu a a para el desarrollo del Sistema de Informacin para Proyectos de Telemedicina. Se aclara o que este modelo, como el sistema y los actores, no es indiferente del proceso evolutivo de adaptacin de conocimiento por lo que en realidad no se considera como una frmula mgica o o a sino simplemente como un caso espec co que aporta unos lineamientos interesantes para otros proyectos de software similares y sirve de base para los ingenieros de proceso de fases posteriores en el ciclo de vida del macroproyecto SITEM. En ultimas, un sistema software exitoso es aqul en el cual todos sus componentes se renan constantemente y el proceso de e desarrollo es un componentes nuclear que tiene mayor incidencia. Existen tantos procesos de desarrollo de sistemas en el mundo que la mera enumeracin taxao tiva podr cubrir cientos de pginas. El dilema de cual es el mejor de ellos es irresoluble, sin a a embargo se puede denir las caracter sticas ptimas para un contexto en particular teniendo o en cuenta mltiples indicadores a partir de aspectos tales como: u

Tamao del Grupo de Desarrollo n Presupuesto L mites de tiempo.

2.3.2.

Principios de Dise o y Desarrollo n

A travs del tiempo se han decantado ciertas prcticas que son reconocidas como las ms e a a o ptimas cuando se trata de construir un sistema software de gran magnitud - tanto en l neas de cdigo, como en funcionalidad y recursos involucrados. Estos principios son tenidos en o cuenta independientemente del proceso de desarrollo que se siga. Quizs los de mayor difusin a o son los patrones GRASP - acrnimo de General Responsibility Assignment Software Patterns, o que se basan en la asignacin precisa de responsabilidades a cada uno de los componentes del o sistema software.3 . En el desarrollo del SITEM se recomienda, como estrategia para mantener la calidad del software, que los integrantes del grupo tengan en cuenta y adquieran competencias en el manejo de los siguientes patrones y principios: 4La metodolog no fue exhaustiva y se limit a un grupo muy reducido de elementos cuya caracteria o zacin se bas exclusivamente en indicadores de tipo cualitativo. Se recomienda remitirse a [McCarty, 2006], o o [Pressman, 2006], [Jacobson,2000], [Koch, 2005] - entre otros, para detalles de los diferentes procesos. 3 An el Object Management Group declara el uso de ciertos principios de diseo en el desarrollo del u n metamodelo que especica a UML 4 Debido a que el proceso general adoptado contiene elementos del Desarrollo de Software de Cdigo Abierto o [Koch, 2005], no siempre se obtiene un seguimiento preciso de los patrones por parte de todos los participantes. Renamientos sucesivos y estrategias de capacitacin se despliegan al interior del grupo para incrementalmente o llegar a este objetivo.2

26

Modularidad. Para facilitar las tareas de mantenimiento, depuracin e incremento en o la funcionalidad, se requiere que el sistema se implemente con base en componentes que presente propiedades de alta cohesin funcional entre sus elementos y tengan bao jo acoplamiento entre s La alta cohesin funcional tiene en cuenta que el compo. o nente realiza solo tareas relacionadas y utiliza un conjunto de datos homogneo. El bajo e acoplamiento se reere al hecho de que un componente se relaciona con otro a travs de e una interfaz estable y denida; dicha relacin no est supeditada a la implementacin o a o interna de ninguno de los componentes, con bajo acoplamiento un cambio en un componente no requerir ningn cambio en la implementacin del componente asociado. a u o Prueba continua. Todos los mdulos y sus componentes deben ser probados en cuanto o su funcionalidad y el cumplimiento de los dems principios y patrones. Las actividades a de prueba podrn ser automatizadas o realizadas manualmente pero en cualquier caa so deben ser formalmente documentadas. Es una recomendacin que en lo posible el o personal de prueba sea diferente a aquel que ha diseado, o construido, el componente. n Codicar claramente. La forma en que se ingresa el cdigo o se agrupa un conjunto o de elementos grcos en un diagrama deben ser hecha de tal forma que se facilite su a comprensin. Se recomienda el uso de comentarios para aquellas partes del cdigo cuya o o funcionalidad no sea evidente o cuando se evite el tener que analizar piezas de cdigo o extensas. Abstraccin Funcional por capas. Los diferentes componentes del SITEM debern o a centrar su funcionalidad en tres capas principales: datos, aplicacin e interfaz. Los o unidades que manejen cada una de las capas deben propender por conservar la modularidad. Reutilizacin. Los diferentes componentes del SITEM - denominados bloques dentro o del modelo de desarrollo, deben estar codicados de tal forma que puedan ser fcilmente a adaptados en los diferentes mdulos sistema. o Re-creacin de componentes. Se debe conocer la estructura interna de un detero minado componente para poder sugerir mejoras. Este principio no pretende desplazar a la reutilizacin sino que debe complementarlo. El contexto denir cual de los dos o a deber ser usado. El tiempo transcurrido desde la creacin y la cantidad de uso del a o componente son indicadores a tener en cuenta. Controlar las versiones. Debe mantenerse un repositorio que permita recuperar los estados anteriores de cualquier componente dentro del sistema. El incremento general en la funcionalidad, el renamiento en el desempeo y la experiencia adquirida al desarrollar n el software es informacin que permanece latente en los repositorios. Los repositorios o integrados permiten mantener la sincronizacin de los grupos de trabajo y blinda el hilo o estable - ocial- de los hilos secundarios en desarrollo o depuracin. o Documentar. Ya sea empotrado dentro del cdigo, usando lenguajes de modelado o o en artefactos independientes se deben documentar las actividades interesantes que se realicen en el desarrollo del sistema. La documentacin debe usar estndares multio a plataforma para que pueda ser transparentemente visualizados,editados y compartidos entre los integrantes del equipo de desarrollo. 27

2.3.3.

Proceso de Desarrollo de Software de Cdigo Abierto o

Es indiscutible el papel preponderante que tiene la planicacin en el desarrollo de cualquier o tipo de sistema, sin embargo, no debe olvidarse que cuando se requiere solucionar un problema no basta con el mero seguimiento de una receta y es aquel toque unico que brinda el ser humano el que hace que los sistemas de software se diferencien unos de otros. No es por casualidad que en nuestro medio el software se considera un producto que esta cubierto por la misma legislacin que las obras literarias o musicales. o Apelando a ese recurso intangible llamado pasin, que an hoy solo es caracter o u stico de los seres humanos, se ha extendido en los ultimos aos el proceso de desarrollo de software de n cdigo abierto. Todos los paradigmas que las grandes empresas de desarrollo de software se o han encargado de poner como las mejores prcticas, se han reevaluado, trastocado, pisoteado a y sin ms ni ms un gran cisma apareci en el horizonte. Este renacimiento moderno surge a a o como respuesta humana al gran vac de satisfaccin de necesidades que brindaba el software o o a principios de los ao noventa. n Ms que una forma de realizar sistemas, se trata de una visin revolucionaria en torno al a o software como patrimonio de la humanidad y se une a la losof del software libre que se a expresa en [stallman,2002]:

Software Libre se reere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. De modo ms preciso, se reere a a cuatro libertades de los usuarios del software: La libertad de usar el programa, con cualquier propsito (libertad 0). o La libertad de estudiar cmo funciona el programa, y adaptarlo a tus necesio dades (libertad 1). El acceso al cdigo fuente es una condicin previa para o o esto. La libertad de distribuir copias, con lo que puedes ayudar a tu vecino (libertad 2). La libertad de mejorar el programa y hacer pblicas las mejoras a los dems, u a de modo que toda la comunidad se benecie. (libertad 3). El acceso al cdigo o fuente es un requisito previo para esto.

Las aplicaciones ms representativas del mundo del software libre como Apache, Mozilla, a MySQL, PostgreSQL y el mismo sistema operativo Linux, luego de sus etapas primarias, adoptaron como proceso de desarrollo uno que contraven en gran manera los fundamentos a del control riguroso y pon el futuro del sistema en manos de la anarqu 5 . Tal como lo a aDenida en su sentido positivo como la situacin humana en donde es innecesaria e indeseable la autoridad, o lo que conlleva a una sociedad libre basada en el respeto mutuo de sus miembros y la cooperacin voluntaria o entre individuos.[BCE,2003]5

28

Figura 2.3: Conceptos Bsicos en el Desarrollo de Software de Cdigo Abierto a o

29

propone Linus Torval la idea es liberar versiones de prueba rpido a menudo, delegar cuanto a sea posible, estar abierto hasta el punto de resultar promiscuo. Algunos principios fundamentales en este tipo de desarrollo los expone [Raymond, 1996]: 1. Todo buen trabajo de software comienza a partir de las necesidades personales del programador. (Todo buen trabajo empieza cuando uno tiene que rascarse su propia comezn). o Esto podr sonar muy obvio: el viejo proverbio dice que la necesidad es a la madre de todos los inventos. Empero, hay muchos programadores de software que gastan sus d a cambio de un salario, en programas que ni as, necesitan ni quieren. No ocurre lo mismo en el mundo Linux; lo que sirve para explicar por qu se da una calidad promedio de software tan alta en esa e comunidad. 2. Los buenos programadores saben qu escribir. Los mejores, qu reescribir (y e e reutilizar). ... una importante caracter stica de los grandes programadores es la meticulosidad con la que construyen. Saben que les pondrn diez no por el esfuerzo, a sino por los resultados; y que casi siempre ser ms fcil partir de una buena a a a solucin parcial que de cero. o 3. Contemple desecharlo; de todos modos tendr que hacerlo.ita encontrada en a c el cap tulo 11 de libro The Mythical Man-Month escrito por el clebre Fred e Brooks. Dicindolo de otro modo: no se entiende cabalmente un problema hasta que e se implementa la primera solucin. La siguiente vez quizs uno ya sepa lo o a suciente para solucionarlo. As que si quieres resolverlo, preprate a empezar a de nuevo al menos una vez. 4. Si tienes la actitud adecuada, encontrars problemas interesantes. a 5. Cuando se pierde el inters en un programa, el ultimo deber es heredarlo a e un sucesor competente. 6. . Tratar a los usuarios como colaboradores es la forma ms apropiada de a mejorar el cdigo, y la ms efectiva de depurarlo. o a 7. Libere rpido y a menudo, y escuche a sus clientes. a 8. Dada una base suciente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rpidamente, y su solucin ser a o obvia al menos para alguien. Dicho de manera menos formal, on muchas miradas, todos los errores saltarn c a a la vista. A esto lo he bautizado como la Ley de Linus. 9. Las estructuras de datos inteligentes y el cdigo burdo funcionan mucho mejor o que en el caso inverso. De nuevo Fred Brooks, Cap tulo 11: Mustreme su cdigo y esconda sus e o estructuras de datos, y continuar intrigado. Mustreme sus estructuras de e e datos y generalmente no necesitar ver su cdigo; resultar evidente. e o a 30

En general un proceso de desarrollo de software libre se basa en el hecho de que el programa puede ser instalado y el cdigo fuente est disponible para cualquier persona. Es decir, la o a ausencia de barreras en cuanto a la limitacin en el uso hace que muchas personas interesas o en la funcionalidad que brinda el software lo descarguen y empiecen a utilizarlo. Dando inicio al siguiente ciclo: 1. El grupo inicial de programadores mantiene un sitio en la red para obtener retroalimentacin de los usuarios los cuales reportan fallos, disafuncionalidades y solicitan o nuevas caracter sticas. 2. Un desarrollador - que puede ser uno de los usuarios, revisa la lista de reportes y decide trabajar en uno espec co; para tal efecto descarga la ultima versin del cdigo fuente o o la modica y la env a un revisor para que este convalide la contribucin. a o 3. La contribucin se agrega al cdigo fuente generando una nueva versin del sistema. Esto o o o se realiza sincronizando el cdigo fuente de desarrollo con aqul existente en la bodega o e de cdigo fuente - repository, la cul normalmente es un gestionada por un programa o a para el control de versiones. 4. Si en algn momento dos programadores estn realizando modicaciones a la misma u a porcin de cdigo y pretenden sincronizarlas ocurre un conicto que deber ser resuelo o a to siguiendo reglas denidas que habitualmente contemplan el bloqueo de la versin o ms reciente, el aviso para resolucin entre desarrolladores que causan el conicto o el a o descarte de las contribuciones. De esta forma se va renando el software siguiendo el ciclo mostrado en la gura 2.3. El grupo de desarrollo se ve aumentado cuando usuarios expertos empiezan a proponer y realizar cambios directos en el cdigo; cuando uno de ellos demuestra tener el suciente inters y o e respeto hacia los intereses del software se le asigna el permiso para escribir directamente en la bodega de cdigo. o La creacin de la documentacin as como de los modelos de requerimientos,anlisis, diseo o o a n y despliegue siguen el mismo proceso.

Mtodos Ligeros e Ha principios del milenio un grupo de experimentados desarrolladores, entre los que se encontraban Kent Beck, Alistair Cockburn, Martin Fowler y Dave Thomas, redactaron un maniesto en el que consignaban los elementos de mayor importancia dentro del desarrollo de sistemas software [Beck,1999]: Nosotros estamos descubriendo mejores formas de desarrollar software dado que lo creamos y ayudamos a otros a realizar esta tarea. Por medio del trabajo de desarrollo hemos encontrado de gran valor elegir: 31

Individuos e interacciones sobre procesos y herramientas Software ejecutable sobre documentacin profusa o Colaboracin del Cliente en el desarrollo sobre contrato de negocios o Respuesta al cambio sobre ceirse a un plan. n Mientras que existe valor en los elementos de la derecha nosotros valoramos ms a los elementos de la izquierda. Con esto sentaban las bases para el despliegue de nuevos mtodos de realizar software agrue pados bajo el nombre genrico de giles6 que se contrapon a los mtodos y procesos e a an e tradicionalmente r gidos y altamente planicados. En [Koch, 2005] se expresan claramente las razones del porqu se desarrollan estos mtodos e e y sus principales caracter sticas. Los mtodos giles nacen como respuesta del desarrollador e a puro al ambiente altamente industrializado y burocrtico en el cual transcurren la mayor de a a proyectos de desarrollo de software. En estos ambientes es t pico el riguroso control que sobre el cumplimiento de cronogramas, planes de trabajo y presupuestos mantienen los denominados ingenieros de proceso. El enfoque tradicional se basa en la planicacin con la que se trata de o predecir desde las primeras etapas todos los pormenores del ciclo de desarrollo. Debido a que los mtodos tradicionales tienen fundamento en la ingenier civil y mecnica, e a a tratan de mitigar los riesgos poniendo un especial inters a las actividades de modelo en ese pecial en las etapas de anlisis y diseo; en general relegan a los desarrolladores a etapas de a n construccin erroneamente consideradas de cero esfuerzo intelectual. Los requisitos del softo ware se tratan de jar desde los inicios del desarrollo, rmandose usualmente un contrato de aceptacin de los mismos por parte del cliente. Estos mtodos tradicionales siguen los o e lineamientos de aseguramiento de la calidad por la cual los procesos son ecientemente documentados, controlados, auditados, vigilados y mejorados. Todos esos aspectos hacen que el elemento clave sea el proceso y se relegue a segundo plano el crear productos que en realidad aporten un nuevo valor al cliente. Para atacar la abrumadora complejidad que aade el proceso al sistema de software, los n mtodos giles proponen cambiar el paradigma predictivo - r e a gido y resistente al cambio; por uno adaptativo que sea exible y reaccione rpidamente antes cambios inesperados en a los requisitos del software. Aquellos que han desarrollado un software de mediana o alta complejidad conocen de primera mano el hecho de que los requisitos no son estticos, ellos a cambian, evolucionan se transforman ya que en s no son sino abstracciones de necesidades , del mundo real y este no es esttico sino que se caracteriza por una fuerte dinmica. a a El cliente tambin debe ser adaptable en el sentido de que la mayor de las veces los requere a imientos del sistema los va descubriendo a medida que interactua con l. Una de las premisas e de los procesos giles es el mantener un contacto permanente con el cliente e involucrarlo a en todas las fases del desarrollo. Con esto se logra que el cliente obtenga un software que6

Siendo por denicin un mtodo caracterizado por ser liviano y ligero o e

32

realmente cope sus intereses y (el cliente) sea consiente de los costos asociados al desarrollo del mismo. As como los requisitos cambian durante el desarrollo tambin lo hacen los recursos y el e escenario en el cual se desenvuelve el equipo de trabajo. Para atacar esta caracter stica de los sistemas software, se recomienda aferrarse a un presupuesto global pero distribuyndolo en e pequeos presupuestos que solventen las tareas que ha corto plazo realizan los involucrados n en el desarrollo. Es claro con lo expuesto hasta ahora que el enfoque es considerar el desarrollo como una carrera de 100 metros planos y no como una maratn. En tal sentido se deben gestar o planes a corto plazo cuyo objetivo principal sea generar versiones del sistema que puedan ser probadas, corregidas e incrementalmente adicionadas en funcionalidad. Cada plan transcurre en lo que se denomina una iteracin la cual usualmente no supera el mes de duracin - algunos o o recomiendan una duracin de dos semanas o mnos.[Beck,1999] o e Otro caracter stica de los mtodos clsicos, y que atacan los mtodos giles, es aquella en la e a e a cual se considera a las personas como recursos intercambiables mediante la denicin de roles o con funciones espec cas y predictivas. Esto hace que las personas - cuyo comportamiento es poco predecible y no lineal [Cockburn, 1999], tengan una moral baja y descienda su productividad; en el mejor de los casos trabajan con esfuerzo y, si sus condiciones son excelsas, rapidamente abandonan el grupo perdindose un activo intangible que repercute negativae mente en la calidad global del sistema. Para los metodlogos giles el desarrollo se centra o a en las personas ms que en los procesos, considera a cada miembro del grupo como un ser a creativo e irreemplazable, esto genera un gran cambio en cuanto al mtodo: no es esttico ni e a recetario. Evoluciona, se recrea, se adapta y se concerta dentro el grupo de trabajo. Evidentemente el proceso de desarrollo de software libre maneja los principios promulgados por los mtodos giles los cuales encuentran quizs su mxima expresin en la Programacin e a a a o o Extrema [Beck,1999].

Proceso Unicado Segn lo expresa [Alhir,2003]: u El Proceso Unicado (UP) es un proceso de desarrollo de software basado en componentes dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental...que utiliza la especicacin UML dada por el Object Management Group o (OMG) para preparar los esquemas del sistema. El Proceso Unicado es aplicable a diferentes tipos de sistemas de software, incluyendo proyectos de pequea y larga n escala; proyectos que tengan varios grados de complejidad tcnica y administratie va, a travs de diferentes dominios de aplicacin y culturas organizacionales. e o El PU nace de la unicacin, en 1995, de la aproximacin sugerida por Ratioo o 33

nal Software Corporation y el proceso orientado a objetos de la empresa Objetory AB. Se puede considerar al Proceso Unicado como un modelo de ciclo de vida del proyecto que incluye contexto, colaboraciones e interacciones. El UP es documentado totalmente en el libro The Unied Software Development Process escrito por Booch, Rumbaugh y Jacobson, y publicado por Addison- Wesley en 1999. Un sistema desde que nace hasta que muere repite el Proceso Unicado en ciclos de desarrollo constituidos por fases secuenciales cuyo objetivo es la produccin incremental de liberaciones o del sistema, llamadas comnmente como generaciones del sistema. Cada una de las fases se u convierte en un hito principal y esta constituido por pequeos microprocesos denominados n iteraciones. Habitualmente la numeracin de las fases se hace de acuerdo a nmeros enteros o u mientras que las iteraciones se hacen en nmeros decimales. u Las fases para el desarrollo de proyectos en el Proceso Unicado son cuatro [Jacobson,2000], a saber:

Fase de Concepcin. Tambien conocida como de inicio. Se centra en el establecimiento de o las fronteras, mbitos, riesgos asociados y visin del proyecto. Determina la viabilidad a o y los objetivos del proyecto. En esta fase podr tenerse una arquitectura general del a sistema que esboze los subsistemas ms importantes. a Fase de Elaboracin. Se enfoca en la determinacin de la arquitectura y requisitos del o o sistema; de esta forma se establece su viabilidad tcnica. Durante esta fase se construyen e los casos de uso cr ticos y se obtiene una arquitectura renada del sistema. Fase de Construccin Es en la que se crea la mayor funcionalidad del producto, naliza o con cierta capacidad operativa. Se centra en la construccin del sistema y la arquitectura o del sistema se considera estable. Fase de Transicin . Concluye con la liberacin del producto, centrndose en la transicin o o a o o distribucin del sistema a la comunidad o usuario nal. o

Dentro de las iteraciones el grupo de trabajo deber distribuir sus esfuerzos en reas estratgia a e cas que conduzcan a la mitigacin temprana de los riesgos, ests reas son conocidas dentro o a a del PU como disciplinas, gura 2.4:

Disciplina de administracin de cambios en la conguracin, la cual se centra o o en la administracin de la conguracin del sistema y de las peticiones de cambios en o o la misma. Disciplina de administracin de proyecto. o Disciplina de ambiente que se centra en los ambientes de desarrollo del proyecto, incluyendo los procesos y las herramientas. 34

Disciplina de modelado del negocio; focalizado en la comprensin del negocio que o esta siendo automatizado por el sistema capturando dicho conocimiento en un modelo del negocio. Disciplina de requerimientos, necesaria para entender los requerimientos del sistema que automatiza el negocio y captura dichos requerimientos en un modelo de casos de uso. Disciplina de dise o y anlisis, centrada en analizar los requisitos y disear en n a n sistema capturando tales conocimientos en un modelo de anlisis/diseo. a n Disciplina de implementacin para la implementacin del sistema basado en el o o modelo de implementacin. o Disciplina de pruebas que maneja las pruebas (evaluaciones) del sistema comparndoa los con los requerimientos basndose primordialmente en el modelo de pruebas. a Disciplina de distribucin encargada de la distribucin del sistema basado en el o o modelo de distribucin. o

Durante la etapa de concepcin la mayor del esfuerzo est distribuido a travs del modelo o a a e del negocio y la disciplina de requerimientos. Durante la fase de elaboracin el esfuerzo se distribuye entre las disciplinas de implementacin, o o diseo, anlisis y requerimientos. Durante la etapa de construccin el esfuerzo se distribuye n a o entre las disciplinas de anlisis, diseo, implementacin y pruebas. a n o En la fase de transicin el esfuerzo se distribuye a travs de las disciplinas de prueba y o e distribucin. Obviamente las disciplinas de soporte se distribuyen entre todas las cuatro fases. o El objetivo general es producir el sistema, por lo tanto todas las disciplinas nucleares estn a comprometidas tanto como sea posible para no introducir riesgos en el proceso; esto es, los practicantes son los responsables de determinar cuales disciplinas comprometer y en que momento hacerlo. En este punto es necesario denir varios conceptos: riesgo en el Proceso Unicado se concibe como un obstculo para alcanzar el xito en a e la ejecucin de una actividad, este riesgo puede estar determinado por caracter o sticas del negocio, humanas o tcnicas. e Iteracin es un paso o rama a travs de un ruta hasta cierto destino. Dicho de otra forma o e es un movimiento planeado que puede ser evaluado para demostrar un progreso tangible dentro de una actividad o proceso, adems, de acuerdo a lo citado por [Zabala, 2000]: a Una iteracin es iterativa en el aspecto de que es un acto repetitivo que propende la o mejora continua del trabajo. Aditiva en el caso de que el resultado es siempre superior al alcanzado con un solo trabajo y paralela ya que el trabajo puede ser concurrente dentro de la iteracin. o 35

Figura 2.4: Ciclo de Desarrollo de un sistema segn el Proceso Unicado u

36

Cuando se decantan los requerimientos, aquello que el sistema debe cumplir, se est declarando a expl citamente los casos de uso los cuales, dado que el Proceso Unicado est manejado por a ellos, determinan las iteraciones. De la misma forma en que los casos evolucionan en el marco de las disciplinas regidas por un proceso iterativo, los sistemas evolucionan constantemente con base en iteraciones realizados en el marco de su arquitectura. Incluyendo en la arquitectura todos los elementos, sus colaboraciones e interacciones. Resulta pues obvio que la iteracin, dado que es un avance demostrable, tiende en ultimas a o reducir los riesgos inherentes a cada una de las etapas del proceso de desarrollo. Esto ha sido denido por [Alhir,2003] en su art culo: .. de esta forma las iteraciones confrontan los riesgos derivados de los casos de uso y la arquitectura para alcanzar el xito en el proyecto, buscando en todo momento e reconciliar las fuerza tcnicas y del negocio. Una iteracin esta acotada en el tiempo e o con inicio y nal jos en donde una coleccin de colaboraciones son planeadas, o ejecutadas y evaluadas del tal forma que en todo momento se pueda demostrar progreso en el proceso... un caso de uso evoluciona a travs de un gran nmero de e u iteraciones y a travs de cualquier nmero de disciplinas nucleares en una iteracin. e u o La experiencia y aprendizaje obtenido en una iteracin evidentemente conduce la o aplicacin de las prximas iteraciones dentro del proceso.. o o La iteracin se convierte en el hito ms importante para asegurar el crecimiento continuo y el o a aseguramiento de la calidad total dentro del sistema que se est desarrollando. Las iteraciones a marcan totalmente el ciclo de desarrollo del SITEM que utiliza una aproximacin iterativa o propuesta por el Proceso Unicado.

2.4.

UML: Lenguaje de Modelado Unicado

Independiente del modelo utilizado para la construccin y gestin del desarrollo del sistema o o se requiere que la comunicacin entre los diferentes integrantes del grupo de desarrollo sea o efectiva. Se hace indispensable que todo el equipo utilice y entienda un lenguaje consistente y unicado con el cual expresen claramente sus ideas y desde el cual puedan marcar claramente las directrices a seguir. El lenguaje de Modelado Unicado, UML por sus siglas en ingls, e brinda las caracter sticas tanto sintcticas como semnticas para lograr caracterizar lgicaa a o mente cualquier tipo de software permitiendo ser utilizado en cualquier etapa del diseo y es n especialmente util en aquellos desarrollos enfocados a objetos. El Lenguaje de Modelado Unicado es denido por el Object Management Group 7 :En la pgina del OMG (www.omg.org) se considera el OMG como un consorcio de la industria de la a informtica, sin animo de lucro, con caracter internacional y de membres abierta. Los diferentes grupos de a a trabajo del OMG desarrollan estndares en un rango amplio de tecnolog a as.7

37

UML es un lenguaje visual para la especicacin, construccin, y documentacin o o o de los artefactos de un sistema. Es un lenguaje de modelado de propsito genero alque puede ser usado con la mayor de los mtodos orientados a objetos y a coma e ponentes; que puede ser aplicado a todos los dominios de aplicacin (p.e., salud, o nanzas, telecomunicaciones, aeroespacial) y plataformas de implementacin (p.e., o J2EE, .NET). En [Jacobson,2005] se recalca que UML es usado para entender, disear, buscar, congurar, n mantener y controlar la informacin acerca de los sistemas. o Con UML se crean artefactos con informacin acerca de la estructura - o vista esttica- y el o a comportamiento - o vista dinmica- de un sistema. Cada vista del sistema se modela como a una coleccin de objetos que interactuan, es decir, que tienen interfaces y relaciones entre ellos o perfectamente denidas. Fruto de tal relacin entre objetos el sistema ofrece una funcionalidad o o cumple un objetivo que es de inters. e

2.5.

Portales de Informacin y Conocimiento o

Antes de la explosin de servicios a travs de la Internet, los portales basados en aplicaciones o e web estaban recomendados solo para organizaciones que por su complejidad (en tamao gen o ograf necesitaran de un sistema tecnolgico para que todo su personal pudiese tener acceso a) o a la informacin en forma compartida y simultnea. Sin embargo, fundamentado en el creco a 8 surgue la necesidad de la sociedad por mantener cierto orden en imiento del uso de Internet la corriente de bytes y grupos de usuarios con intereses de informacin comunes empiezan a o conglomerarse alrededor de portales temticos no organizacionales. a Un portal de informacin no es, en esencia, una fuente nueva de informacin; es una vista o o de la informacin existente que dispuesta en una forma ordenada se convierte en una hero ramienta de conocimiento extraordinariamente poderosa permitiendo poner al descubierto informacin valiosa que se enmascaraba entre otra no menos interesante Data Mining. Deno tro de las mltiples ventajas que ofrece el portal, es que proporciona la facilidad de obtener u informacin actualizada a muy corto plazo, lo que es indispensable para la ptima toma de o o decisiones. Dicha informacin esta disponible, en condiciones ptimas, veinticuatro horas al o o d trescientos sesenta y cinco d del ao, permitiendo as acceder a los datos que se necea, as n sitan de acuerdo con la disponibilidad singular de tiempo y apoyar la toma de decisiones bajo cualquier circunstancia y lugar. Gran cantidad de organizaciones y grupos de usuarios estn explotando el uso de los portales a creando y transformando servicios y procesos tradicionales convirtindolos en servidores de e autoservicio, pudiendo as dedicarse a aquellos de mayor valor agregado a la organizacin, el o personal o el grupo de investigacin. o8 El porcentaje de la poblacin con acceso a Internet en Colombia a crecido de un 2,1 % en el ao 2000 a un o n 15,8 % en el 2007, segn la Comisin de Regulacin de Telecomunicaciones. u o o

38

2.5.1.

Benecios y obstculos para la implementacin de portales basados a o en aplicaciones web.

Las facilidades que proporciona la tecnolog permite que el portal sea accedido a travs de a, e numerosas opciones, esto es a travs de computadoras de escritorio y porttiles integradas a e a la red interna de la organizacin, a travs de Internet por redes de banda ancha y estrecha y o e de los diversos medios inalmbricos como son las tecnolog celular, WiFi, WiMax, BlueTooh a as por intermedio de PDA, celulares y equipos de cmputo en redes WLAN. o Debido a la estructura del portal, se tiene una fuerte correlacin entre diversas aplicaciones o que nos permiten analizar interrelaciones que ser realmente complejas y tardadas si no se an contara con ellos. Sin embargo, es importante recalcar ms que los benecios los problemas a potenciales. De hecho en el xito de un portal estn enfocados factores clave que tienen e a benecios y problemas asociados.

Factor Humano Los individuos adaptan los procesos de informacin en diferentes maneras. o Factor Tecnolgico Intranets, pueden ser costosas y poco efectivas si la organizacin no o o tiene la tecnolog necesaria para construirlas. a

La principal ventaja obtenida al construir y mantener un portal basado en aplicaciones web es mejorar la eciencia y efectividad en la comunicacin de los miembros de una organizacin o un o o grupo de usuarios, lo que aumenta la objetividad en la toma de decisiones y la transferencia de conocimiento. Todo lo anterior se maximiza si el portal se concibe como fruto de un proceso de investigacin en donde todos sus componentes y servicios se construyen, mantienen, o distribuyen e integran de acuerdo a los requerimientos de los usuarios nales[Sarmento,2005]. Una de las caracter sticas importantes de los portales es que en un slo lugar - y con un o mecanismo de acceso unicado, los usuarios pueden acceder a las aplicaciones. Esta integracin con aplicaciones y servicios orientados al trabajo colaborativo hacen que trascienda o los l mites de un mero repositorio organizacional - que permite el autoservicio de requerimientos y extraccin de informacin bsica - y lo convierte en una herramienta de administracin o o a o del conocimiento, util para la toma de decisiones. Las novedosas tecnolog que convergen en Internet permiten que la informacin sea personas o alizada y dirigida de tal forma que se potencian ciclos de creacin, captura y diseminacin de o o conocimiento necesarios para el crecimiento de los activos intangibles de los grupos y organizaciones. As los portales convierten la informacin en valor, ya que eliminan las barreras de o distancia y disponibilidad de informacin, reduciendo costos conectando a mltiples personas o u en diversos sitios al mismo tiempo. La tabla 2.1 muestra los principales benecios potenciales de desplegar los portales de informacin y conocimiento dentro del quehacer de las organizaciones, los grupos de trabajo y las o comunidades de prctica. a 39

Benecios Humanos (suaves) Provee estructura de soporte 24 hrs. Servicio centrado en el usuario. Medio ambiente amigable. Benecios F sicos y capitales (benecios fuertes) Creacin medioambiente libre de papel. o Mejorar eciencia y efectividad. Reduccin de costos. o Menores tiempos en consecucin de informacin. o o Benecios estratgicos e Creacin de herramientas innovadoras de apoyo. o Proveer informacin a tiempo real. o Apoyo a proceso de negocios de reingenier a Apoyo a los ciclos de creacin, captura y diseminacin de conocimiento. o o Aumento de Capital intangible. Formalizacin del Know-How. o Tabla 2.1: Algunos Benecios Potenciales al Implementar un Portal

Los riesgos que se afrontan tambin son enormes y pueden llevar al traste cualquier pol e tica o proyecto de desarrollo; la tabla 2.2 muestra algunos de los ms importantes que deben ser a minimizados.

2.5.2.

Ciclo de Vida de los Portales

Los portales como representacin sistemtica del quehacer de un grupo humano evoluciona o a en la medida que dicho grupo mejora su conocimiento de las relaciones entre sus miembros y el entorno que los rodean. En general pueden determinarse cinco macro-etapas [UN, 2005] que aumentan gradualmente su funcionalidad basado en el conocimiento organizacional y la interrelacin de usuarios a travs del Portal: o e

Presencia Emergente Esta es la etapa primaria por la que pasa un portal en donde su funcionalidad es la de distribuir informacin interesante para un grupo de usuarios, el o cual es totalmente caracterizado por el grupo de personas que construye - en todas sus dimensiones, el portal. Dichos usuarios no intervienen directamente en la estructura del Portal el cual complementa sus servicios por medio de enlaces y dependencia a otros portales temticamente relacionados. a Presencia Mejorada Los usuarios pueden determinar en cierto grado la navegacin a travs o e de bsquedas en el archivo del sitio. Un portal en esta etapa presentar gran cantidad u a de informacin que usualmente se agrupa por reas temticas. Los mapas del portal se o a a distribuyen profusamente con el n de guiar a los usuarios en su trnsito por el mismo a y usualmente un sistema bsico de ayuda prediseada esta disponible. a n 40

De tipo Humano (Fuertes) Indiferencia de la administracin. o Sobrevaloracin del papel de las TIC o Direccin centrada en el capital nanciero o Estructuras organizacionales conservadoras. Micropoderes y feudos organizacionales autogestionados. Ignorancia y/o resistencia respecto al uso de TIC. Resistencia a estandarizar la informacin. o Resistencia a compartir informacin/conocimiento. o Riesgos F sicos/Capital Procesos orientados a la tcnica y no multidimensionales. e Carencia de capital(TIC marginales). Dicultad de integracin de tecnolog nueva y la existente. o a Ausencia de inter, trans y multidisciplinariedad. Riesgos tecnolgicos (Dbiles) o e Estndares propietarios. a Redes de interconexin da baja velocidad. o Alta relacin Consumo/Adopcin de tecnolog o o a. Tabla 2.2: Algunos riesgos Potenciales al Implementar un Portal

Interaccin Los portales registran a sus usuarios. Se implementan herramientas en l o nea como las salas de charla - chat, las listas de correo y los foros; se realiza capacitacin o bsica por medio de seminarios basados en contenidos y se hace uso extensivo de recursos a multimediales. La ayuda es s ncrona o as ncrona pero gil lo que fomenta una depuracin a o y actualizacin de la informacin contenida en el portal. o o Transaccin Los usuarios realizan operaciones a travs del portal. El comercio electrnico, la o e o gestin de contenidos, la personalizacin de los ambientes del portal, bsquedas semntio o u a cas y el despliegue de servicios avanzados - cursos, blogs, etc; caracterizan esta etapa. Transformacin La etapa ms avanzada de los portales en donde se han estructurado coo a munidades de prctica sobre temas concretos que potencian los ciclos de conocimiento a mediante las herramientas brindadas por el portal. Se observa una jerarqu ad hoc de a usuarios con base en su aporte. Ellos mismos generan contenido que es convalidado por la comunidad y los administradores tcnicos limitan sus funciones a aquellas relacionadas e con mantener operativa la plataforma tecnolgica. Las transacciones y el contacto en o tiempo real son rutinarios. Las aplicaciones son de conocimiento general y el nivel de inmersin en el portal es alto. o

2.5.3.

Aplicaciones Web

Tambin conocidas como WebApps son, en su concepcin ms bsica, aplicaciones que ree o a a sponden a peticiones realizadas por un usuario por medio de un navegador (cliente) y ejecutan 41

la lgica del programa en un servidor. Las aplicaciones web usualmente interactan con siso u temas de bases de datos y distribuyen los resultados de sus operaciones en lenguajes estndar a tales como HTML, SMIL, XML, RDF, SVG, etc.[Jackson,2005]. Las WebApps tambin se e pueden encontrar en ambientes diferentes al modelo cliente - servidor[Bos,2004]. Entre las caracter sticas de las aplicaciones web se destacan[Bos,2004]:

No requieren instalacin. En general las aplicaciones web no necesitan ejecutar rutio nas de instalacin en las mquinas cliente. Quizs en algunos lenguajes sea necesario la o a a preparacin de un ambiente espec o co de trabajo que en la mayor de las veces es de a acceso pblico. u Accesibilidad. Las aplicaciones web se despliegan desde de una pgina web. Los proa tocolos usados son estandarizados y abstraen fcilmente las capas de aplicacin de las a o de diseo y datos. n Facilidad en el Desarrollo. Los lenguajes usados son de alto nivel, con un buen soporte para cadenas de caracteres, diferentes tipos de datos y con facilidades para la programacin orientada a objetos. La mayor de ellos con sintaxis similares y herramientas o a de desarrollo gratuitas de fcil adquisicin. a o Independencia de la Plataforma. Las WebApps engines implementan el modelo de capa intermedia lo que permite que las diferentes WebApps puedan ser desplegadas sobre diferentes plataformas sin detrimento de su funcionalidad. El uso de mtodos genricos e e denidos en interfaces de programacin (API) ayuda en gran manera a garantizar esta o caracter stica. Seguridad. No obstante la facilidad de acceso de la WebApp, estas pueden implementar rutinas avanzadas que brindan ambientes transaccionales seguros aislados del sistema de archivos y conguracin del sistema en donde se alojan. El intercambio de informacin o o cifrada por la red y la integracin con la seguridad de los servidores de bases de datos o forman un contexto de alta seguridad. Privacidad. Las WebApps pueden operar fcilmente sobre una Plataforma de Prefa erencias de Privacidad debido a que la mayor de los motores estn habilitados para a a soportar el protocolo P3P. Almacenamiento Persistente. Tanto en el cliente - a travs de archivos texto para e el manejo de sesiones; como en el servidor de base de datos. Integracin. Las aplicaciones