Diferencia entre revisiones de «Building an institutional author search tool»

De TallerDocumental on Wiki
Saltar a: navegación, buscar
(La estructura documental de los proyectos de desarrollo de software)
(Página creada con «== RESUMEN ORIGINAL == Ability to collect time-specific lists of faculty publications has become increasingly important for academic departments. At OHSU publication lists…»)
Línea 1: Línea 1:
La '''documentación de un software''' es el registro de todo lo que ocurrió en la implementación de una solución. Existen distintas metodologías sobre cómo hacer documentación. Aunque sí es importante estudiarlas, lo principal es evaluar qué funciona y qué no.
+
== RESUMEN ORIGINAL ==
No es inteligente seguir ciegamente una metodología sólo porque así lo dice la certificación o el libro. Las circunstancias nunca van a ser las mismas que las del autor de la metodología.
+
Ability to collect time-specific lists of faculty publications has become increasingly important for academic departments. At OHSU publication lists had been retrieved manually by a librarian who conducted literature searches in bibliographic databases. These searches were complicated and time consuming, and the results were large and difficult to assess for accuracy.
 +
The OHSU library has built an open web page that allows novices to make very sophisticated institution-specific queries. The tool frees up library staff, provides users with an easy way of retrieving reliable local publication information from PubMed, and gives an opportunity for more sophisticated users to modify the algorithm or dive into the data to better understand nuances from a strong jumping off point.
  
==La estructura documental de los proyectos de desarrollo de software==
+
== Resumen detallado ==
La estructura documental de los proyectos de desarrollo de software suele consistir en un documento –o más de uno- por cada una de las fases del desarrollo, si se sigue la versión 2.1 de MÉTRICA (o por cada uno de los procesos del desarrollo, si se sigue la versión 3). Esta documentación es la que establecen los manuales de Ingeniería del Software, indicándose en el cuadro nº. 1 la documentación que indica R. S. Pressman (1992)<sup>2</sup>
+
En todas las universidades, cada departamento quiere conocer cuántas publicaciones han publicado sus profesores e investigadores durante un periodo de tiempo determinado. En la Universidad de Ciencias de las Salud de Oregon (OHSU), estas preguntas se manejaban manualmente, recayendo toda la responsabilidad y el trabajo en manos del bibliotecario ya que tenía que buscar manualmente en varias bases de datos de publicaciones, al hacerlo de esa forma, por mucho que el bibliotecario intentara acotar al máximo sus búsquedas, los resultados siempre eran amplios y difíciles de manejar.
 +
Por esa razón se llevó a cabo el reto de desarrollar estrategias de búsqueda para poder conseguir datos precisos y relevantes. En este articulo se intentan abordar los problemas que tienen las bases de datos de publicaciones y los esfuerzos que se han hecho para intentar abordarlos. Además, se desarrolló una herramienta de búsqueda aumentada que aligera la carga y normaliza el proceso en el campus, la herramienta está abierta y se puede personalizar fácilmente para otras instituciones.  
 +
Los problemas que se identificaron fueron 3:
  
{| class="wikitable" border="1"
 
|-
 
| '''Pasos'''
 
| Análisis del sistema. Funciones del software
 
| Análisis de requisitos o creación de un prototipo
 
| Diseño de datos y arquitectónico
 
| Diseño procedimental
 
| Codificación
 
| Pruebas
 
| Lanzamiento y distribución
 
| Mantenimiento
 
|-
 
| '''Documento generado'''
 
| Planificación. Plan del proyecto.
 
| Especificación de requisitos
 
| Especificación preliminar del diseño
 
| Especificación detallada del diseño
 
| Documentación del código
 
| Plan, procedimientos y resultados de las pruebas
 
| Documentación de usuario
 
| Documentos modificados
 
|}
 
  
==Comparación de la documentación de proyectos de desarrollo de software con proyectos de otras tecnologías==
+
* Quién: qué autores se consideran parte del departamento académico
Entendemos que la documentación que se presenta en los proyectos de software, se corresponde principalmente con la que aparece en Anexos a la Memoria en los proyectos que no son informáticos. Como se indica en el apartado 2, la Memoria es el Documento nº I, y consta de dos partes principales que son: I.1: Memoria, propiamente dicha I.2: Anexos a la Memoria.
+
El reto que se considera más difícil es identificar qué artículos deben contarse en los índices de publicaciones. Muchas de esas publicaciones incluyen la afiliación organizacional de los autores, y algunos de ellos al tener varias organizaciones las nombran todas o algunas de ellas, a todo esto, hay que añadir la temporalidad ya que las personas a veces cambian de organización y no hay ningún seguimiento de quién formó parte de esa organización o hasta cuándo. Para solucionar este problema se podrían hacer las búsquedas directamente por e nombre del autor, pero si todos usaran identificadores ORCID, porque si no es el caso, surgen problemas con personas que tienen el mismo nombre.  
La documentación que se presenta con los proyectos de desarrollo de software corresponde a la Documentación Técnica, que también se presenta en los no informáticos; pero en estos aparece, como se ha dicho, agrupada en los Anexos, que forman parte del documento nº I (Memoria); y
 
el resto de documentación se independiza, formando otros documentos (Documento nº. III: Pliego de condiciones, y Documento nº IV: Presupuesto –además del Documento nº II: Planos, que es fundamental cuando se trata de construcciones, etc.).
 
  
===Relación entre las etapas de Proyecto y las etapas de su Ejecución===
+
* Qué: qué fuente se está utilizando para encontrar todas las publicaciones
Son muchas las diferencias entre proyectos informáticos y los de otras tecnologías, pero interesa aquí señalar una, que se
+
Este problema está determinando una fuente autorizada de lo que se ha publicado. No hay una sola fuente a la que referirse para todas las publicaciones de una institución. OHSU, por ejemplo, ofrece una amplia selección de publicaciones, pero no abarca todos los formatos posibles, por lo tanto, hay recursos que no se contarán en ningún recuento de publicaciones de OHSU.
refiere a la relación y a la división y separación entre dos grandes etapas del proyecto y su ejecución; etapas que son las
 
siguientes:
 
* Etapa de proyecto
 
* Etapa de Ejecución del Proyecto
 
  
===Interés de la estructura documental uniforme para los proyectos de diversas tecnologías===
+
* Cuándo: cuál de las muchas fechas asociadas con la publicación se está buscando
La estructura documental señalada, se puede decir que encuentra su justificación en los siguientes aspectos, al menos:
+
Los editores a menudo “pre-publican” un artículo y luego lo publican oficialmente, eso significa que los datos pueden ir cambiando y actualizarse, el problema que surge con esto es que una persona que cuente mensualmente las publicaciones de una organización puede contar más de una vez el mismo artículo en meses diferentes, para poder evitar este problema se tendrían que controlar los artículos de forma individual.
  
# Tiene una correspondencia con los llamados “factores del proyecto”, esto es, con los objetivos, contenidos y las condiciones que el proyecto debe considerar. E. Gómez-Senent (1994)<sup>1</sup>, presenta un cuadro en el que se expresa gráficamente la relación entre cada uno de los cuatro documentos típicos de cualquier proyecto tecnológico, y los que denomina factores del proyecto. Esto es, en todo proyecto tecnológico,aparecen determinados objetivos, condiciones, contenidos, etc. (los factores) que son recogidos en cada uno de los documentos referidos.
+
=== Proceso previo ===
# Aparece recogida en alguna normativa legal, relativa a ciertos tipos de Proyectos.
+
Antes de desarrollar la nueva herramienta, la Biblioteca de OHSU creó manualmente una lista de publicaciones creadas por la propia facultad ejecutando una actualización mensual para las afiliaciones de OHSU en PubMed y Scopus. Lo que se quería conseguir era identificar y eliminar duplicaciones entre las dos bases de datos y mover las versiones más nuevas de los artículos para reemplazar cualquier versión existente en RefWorks. Llevar a cabo este proceso fue insostenible para la biblioteca, por lo que la facultad decidió aumentar las búsquedas de las personas para aproximar parte de la normalización realizada en el proceso manual.
# La recomienda el Instituto de Ingenieros Civiles de España.
+
Para resolver el problema del “qué”, la herramienta utilizaría un índice de publicación existente, el que se eligió fue PubMed, en el caso del problema del “cuándo” se dejó en manos del buscador individual, no se abordó el problema a nivel institucional.  
# Está arraigada en la práctica de Proyectos anteriores a la Informática. Y mantiene su vigencia a pesar del paso del tiempo (incluso centenario), por lo que se trata de una estructura útil.
+
Pero el gran problema sin duda fue como afrontar el problema de “quién”. El gran problema era cómo abordar el problema de «Quién». La búsqueda de personas específicas está llena de dificultades, ya que las personas cambian de nombre y a menudo tienen nombres idénticos con los demás. Nuestro enfoque es solo buscar personas después de que tengamos una búsqueda limitada por el alcance por institución. Trabajamos con los Registradores y las oficinas de Recursos Humanos para obtener una lista de las personas y su unidad organizativa principal dentro de la institución.
# Es la utilizada por las Administraciones Públicas, cuya participación en la actividad social es muy importante, tanto en España como en la Unión Europea (con esto se quiere indicar que la propuesta se formula también para los proyectos de promoción privada).
+
La idea era esencialmente extraer una lista de las publicaciones más probables de OHSU de PubMed y luego intentar hacer coincidir los nombres con las listas de los Registradores y Recursos Humanos. Además, tenemos un problema con artículos más antiguos, donde es más probable que un autor ya no esté asociado con OHSU y, por lo tanto, no esté en la lista «maestra» proporcionada por los Registradores y Recursos Humanos.
#  Es conocida por muchas personas de las organizaciones públicas (y también, por supuesto, de las empresas), si estas han encargado algún Proyecto de tecnologías.
 
# El profesional de las Tecnologías de la información puede trabajar en equipos interdisciplinares. Una razón para la convergencia hacia la norma referida, es que estos profesionales no siempre trabajan individualmente o en grupos de personas de la misma profesión, sino que pueden hacerlo con frecuencia en el seno de equipos interdisciplinares − formados por profesionales de otras tecnologías y especialidades, y otros titulados, etc.− y la estructura normalizada la conoce todo profesional.
 
# Ha demostrado ser operativa para buscar la información deseada en una documentación extensa (como suele ser la del Proyecto).
 
  
==Referencias==
+
=== Método automatizado ===
<sup>1</sup> GÓMEZ-SENENT, E. y CHINER, M. (1.994): ''El Proceso Proyectual.'' Ed. Universidad Politécnica de Valencia, Valencia
+
El servicio que se ha creado utiliza una pila LAMP (Linux, Apache, MySQL, PHP). Destacamos PHP, que se utiliza para consultar API de PubMed para obtener información de citas y MySQL para la consulta de una base de datos local que se extrae de los datos disponibles de Recursos Humanos, y Registradores de la institución. En cuanto al lenguaje de programación web también se eligió PHP, y para los datos personales MySQL.  
 
+
Con el formulario los usuarios hacen sus consultas, y lo que hace es comparar los resultados con los datos de personas disponibles y devuelve esos resultados a los usuarios. Éstos pueden realizar sus búsquedas desde el nombre del autor, título de la revista, rango de fecha de publicación, etc. Además, también hay campos adicionales, esos campos ingresados por el usuario se mandan a esa consulta base y se envían a la API de eSearch de PubMed al presionar “Buscar” en el formulario.
<sup>2</sup> PRESSMAN, R. S. (1.992): ''Ingeniería de Software. Un enfoque práctico''. Ed. McGraw-Hill, Madrid
+
La API devuelve esos resultados con una tabla páginada a la derecha del formulario de búsqueda, los usuarios tienen la posibilidad de “hacer coincidir los departamentos de OHSU”, en el que se intenta coincidir los nombres del autor del conjunto de resultados PubMed, con la base de datos de la institución y los nombres que coinciden aparecen en negrita.  
 
+
El formulario es 'self-POSTing' en el sentido de que todos los campos de búsqueda modificados se construyen como una cadena de consulta URI. Esto significa que los enlaces a conjuntos de resultados específicos son completamente portátiles o incluso completamente personalizables fuera del uso del formulario en sí para la entrada. Esto hace que los conjuntos de resultados enlatados sean fáciles de construir con la herramienta.
{| class="wikitable" border="1"
 
|'''Categorías''':  Documentación de proyecto de software
 
|}
 

Revisión del 10:39 26 nov 2019

RESUMEN ORIGINAL

Ability to collect time-specific lists of faculty publications has become increasingly important for academic departments. At OHSU publication lists had been retrieved manually by a librarian who conducted literature searches in bibliographic databases. These searches were complicated and time consuming, and the results were large and difficult to assess for accuracy. The OHSU library has built an open web page that allows novices to make very sophisticated institution-specific queries. The tool frees up library staff, provides users with an easy way of retrieving reliable local publication information from PubMed, and gives an opportunity for more sophisticated users to modify the algorithm or dive into the data to better understand nuances from a strong jumping off point.

Resumen detallado

En todas las universidades, cada departamento quiere conocer cuántas publicaciones han publicado sus profesores e investigadores durante un periodo de tiempo determinado. En la Universidad de Ciencias de las Salud de Oregon (OHSU), estas preguntas se manejaban manualmente, recayendo toda la responsabilidad y el trabajo en manos del bibliotecario ya que tenía que buscar manualmente en varias bases de datos de publicaciones, al hacerlo de esa forma, por mucho que el bibliotecario intentara acotar al máximo sus búsquedas, los resultados siempre eran amplios y difíciles de manejar. Por esa razón se llevó a cabo el reto de desarrollar estrategias de búsqueda para poder conseguir datos precisos y relevantes. En este articulo se intentan abordar los problemas que tienen las bases de datos de publicaciones y los esfuerzos que se han hecho para intentar abordarlos. Además, se desarrolló una herramienta de búsqueda aumentada que aligera la carga y normaliza el proceso en el campus, la herramienta está abierta y se puede personalizar fácilmente para otras instituciones. Los problemas que se identificaron fueron 3:


  • Quién: qué autores se consideran parte del departamento académico

El reto que se considera más difícil es identificar qué artículos deben contarse en los índices de publicaciones. Muchas de esas publicaciones incluyen la afiliación organizacional de los autores, y algunos de ellos al tener varias organizaciones las nombran todas o algunas de ellas, a todo esto, hay que añadir la temporalidad ya que las personas a veces cambian de organización y no hay ningún seguimiento de quién formó parte de esa organización o hasta cuándo. Para solucionar este problema se podrían hacer las búsquedas directamente por e nombre del autor, pero si todos usaran identificadores ORCID, porque si no es el caso, surgen problemas con personas que tienen el mismo nombre.

  • Qué: qué fuente se está utilizando para encontrar todas las publicaciones

Este problema está determinando una fuente autorizada de lo que se ha publicado. No hay una sola fuente a la que referirse para todas las publicaciones de una institución. OHSU, por ejemplo, ofrece una amplia selección de publicaciones, pero no abarca todos los formatos posibles, por lo tanto, hay recursos que no se contarán en ningún recuento de publicaciones de OHSU.

  • Cuándo: cuál de las muchas fechas asociadas con la publicación se está buscando

Los editores a menudo “pre-publican” un artículo y luego lo publican oficialmente, eso significa que los datos pueden ir cambiando y actualizarse, el problema que surge con esto es que una persona que cuente mensualmente las publicaciones de una organización puede contar más de una vez el mismo artículo en meses diferentes, para poder evitar este problema se tendrían que controlar los artículos de forma individual.

Proceso previo

Antes de desarrollar la nueva herramienta, la Biblioteca de OHSU creó manualmente una lista de publicaciones creadas por la propia facultad ejecutando una actualización mensual para las afiliaciones de OHSU en PubMed y Scopus. Lo que se quería conseguir era identificar y eliminar duplicaciones entre las dos bases de datos y mover las versiones más nuevas de los artículos para reemplazar cualquier versión existente en RefWorks. Llevar a cabo este proceso fue insostenible para la biblioteca, por lo que la facultad decidió aumentar las búsquedas de las personas para aproximar parte de la normalización realizada en el proceso manual. Para resolver el problema del “qué”, la herramienta utilizaría un índice de publicación existente, el que se eligió fue PubMed, en el caso del problema del “cuándo” se dejó en manos del buscador individual, no se abordó el problema a nivel institucional. Pero el gran problema sin duda fue como afrontar el problema de “quién”. El gran problema era cómo abordar el problema de «Quién». La búsqueda de personas específicas está llena de dificultades, ya que las personas cambian de nombre y a menudo tienen nombres idénticos con los demás. Nuestro enfoque es solo buscar personas después de que tengamos una búsqueda limitada por el alcance por institución. Trabajamos con los Registradores y las oficinas de Recursos Humanos para obtener una lista de las personas y su unidad organizativa principal dentro de la institución. La idea era esencialmente extraer una lista de las publicaciones más probables de OHSU de PubMed y luego intentar hacer coincidir los nombres con las listas de los Registradores y Recursos Humanos. Además, tenemos un problema con artículos más antiguos, donde es más probable que un autor ya no esté asociado con OHSU y, por lo tanto, no esté en la lista «maestra» proporcionada por los Registradores y Recursos Humanos.

Método automatizado

El servicio que se ha creado utiliza una pila LAMP (Linux, Apache, MySQL, PHP). Destacamos PHP, que se utiliza para consultar API de PubMed para obtener información de citas y MySQL para la consulta de una base de datos local que se extrae de los datos disponibles de Recursos Humanos, y Registradores de la institución. En cuanto al lenguaje de programación web también se eligió PHP, y para los datos personales MySQL. Con el formulario los usuarios hacen sus consultas, y lo que hace es comparar los resultados con los datos de personas disponibles y devuelve esos resultados a los usuarios. Éstos pueden realizar sus búsquedas desde el nombre del autor, título de la revista, rango de fecha de publicación, etc. Además, también hay campos adicionales, esos campos ingresados por el usuario se mandan a esa consulta base y se envían a la API de eSearch de PubMed al presionar “Buscar” en el formulario. La API devuelve esos resultados con una tabla páginada a la derecha del formulario de búsqueda, los usuarios tienen la posibilidad de “hacer coincidir los departamentos de OHSU”, en el que se intenta coincidir los nombres del autor del conjunto de resultados PubMed, con la base de datos de la institución y los nombres que coinciden aparecen en negrita.

El formulario es 'self-POSTing' en el sentido de que todos los campos de búsqueda modificados se construyen como una cadena de consulta URI. Esto significa que los enlaces a conjuntos de resultados específicos son completamente portátiles o incluso completamente personalizables fuera del uso del formulario en sí para la entrada. Esto hace que los conjuntos de resultados enlatados sean fáciles de construir con la herramienta.