3.10 Methods
3.10.3 Bulk Frequency Ratios and SNP calling
La humanidad se encuentra hoy atravesando situaciones graves y complejas que están impactando en todos los sistemas: sociales, políticos, educativos, económicos, ambientales, tecnológicos, comunicacionales, etc. La discusión no puede ni debe reducirse a los sistemas ideológicos que en el pasado obraron como grandes impulsores de sistemas cerrados y estructurados, los análisis centrados entre los roles predominantes de lo público y/o lo privado, lo económico o lo social, la libertad o la planificación. Deberán dejar lugar al concepto de racionalidad, eficiencia y urgencia que la realidad demanda, pero en este análisis el hombre y su calidad de vida deberán ser el imperativo y centro de toda acción e indiscutible objeto final de cualquier sistema.
La sociedad de la información y especialmente la democratización de la comunicación-información tendrán un rol protagónico en los objetivos de lograr la negentropía de los sistemas y evitar caos de los mismos.
La calidad de vida se verán altamente impactadas por los sistemas comunicacionales, transaccionales e informáticos. En el futuro deberá decidirse con muy buena información proveniente de indicadores adecuados y monitoreo en línea y en tiempo real, cada situación de arbitraje entre los distintos sistemas y sub-sistemas de las organizaciones políticas, sociales y económicas.
Con información adecuada se podrá, por ejemplo, dimensionar daños por impactos industriales en el medio ambiente, su impacto en la salud de la población involucrada, en el empleo, en la organización social, etc., etc. Podrán interactuar los sistemas y equilibrarse, pudiendo resolver en forma mas adecuada que la actual, en donde determinadas decisiones emanan de razones económicas o políticas sin medir su impacto en las consecuencias terribles en la calidad de vida y el costo asociado que de la misma deriva. Con la información en el momento que se necesita e interactiva se podrá analizar cada variable y los sistemas interactuarán mas equitativa y racionalmente. Más aún si entendemos que en el caso planteado, por lo menos en los países desarrollados y en vías de desarrollo, la brecha digital no es significativa debido a que no estamos hablando del acceso de la tecnología a las personas sino a las organizaciones. Más aún si consideramos que las tecnologías descriptas en su mayoría son de código abierto y por lo tanto de acceso público para su utilización, donde el aporte realizado por el Switch Transaccional engrosa sólo un poco más las herramientas de conocimiento y tecnología ya existentes, permitiendo como gran avance el procesamiento de las transacciones orientados al contenido, utilizando para ello reglas definidas en forma genérica. Por lo tanto el inconveniente económico mas relevante es el de la infraestructura de comunicaciones requerida para implementar este conjunto de herramientas e infraestructura ya que el resto de las cuestiones son inherentes a la voluntad y decisión política y social de cada país, donde lamentablemente en muchísimas ocasiones todos los recursos existen menos la voluntad de ponerlos en marcha.
El futuro es hoy, porque si dilapidamos los recursos, habremos comprometido la razón de ser de las organizaciones humanas que es precisamente la sociedad en si misma.
Bibliografía Y Referencias
1. Katz, Ignacio. Retornar al pensamiento lógico. Revista Médicos Número, NEWSLETTER 82 / 24 de Marzo del 2003.
2. Jalfen, Luis J. Globalización y Lógica Virtual. Primera Edición, Ediciones Corregidor, 1998. 3. Morin, Edgar. El Método. Quinta Edición, Ediciones Cátedra, 1999.
4. Barry, Jorge y Barry, Damián. La Salud en la Sociedad de la Información. 32º JAIIO (Jornadas Argentinas de Informática e Investigación Operativa – SIS 2003 (Simposio de Informática y Salud)
5. Varios Autores. eGov-Interop'05 Conference. Observatory On Interoperable eGovernment Services. 6. Helland, Pat. Microsoft Corporation. Datos externos frente a datos internos.
7. Díaz Toledano, Moisés Daniel. Web Services -Introducción y Escenarios para su Uso.
8. OASIS. Organization for the Advancement of Structured Information Standards: http://www.oasis- open.org/home/index.php
9. Bray Tim. Sun on Open Office XML ISO Certification.
http://www.tbray.org/ongoing/When/200x/2004/09/24/SmartEC.
10. Carrera, Daniel. The Future Is Open: What OpenDocument Is And Why You Should Care.
http://www.groklaw.net/article.php?story=20050130002908154. 11. Seely, Scott. WS-Security. Microsoft Corporation. Octubre de 2002.
http://www.microsoft.com/spanish/msdn/articulos/archivo/121202/voices/understw.asp
12. Magíster Freh, Stephan Alexander. Analysis of global eID with focus on Interoperability by using the TFI Model. Marzo del 2005. Departament of Information systems – London School of Economics and Political Science.
13. Michelson, Adam. SOA Versus the Appliance. Mayo del 2006. revista LinuxWorld.
14. Panda, Debu. An Introduction to Service-Oriented Architecture from a Java Developer Perspective. Enero del 2005. http://www.onjava.com
15. Angelov, Samuil & Grefen, Paul. A Framework for Analysis of B2B Electronic Contracting Support. University of Twente, The Netherlands.
16. Laskey, Ken. Reference Model for Service Oriented Architecture. Marzo 2006. Developed by OASIS SOA Reference Model Technical Committe.
17. Varios autores. SOA Application Learning Trail. Netbeans.org. http://www.netbeans.org/kb/trails/soa.html
18. Varios autores.Java EE Applications Learning Trail. http://www.netbeans.org/kb/trails/java-ee.html
19. David Hunter, Kurt Cagle, Chris Dix et al, Beginning XML, 2nd Edition: XML Schemas, SOAP, XSLT, DOM, and SAX 2.0. Wrox Press © 2003.
20. Kim Topley, Java Web Services in Nutshell. O'ReillyPub. Junio 2003. 21. Englander, Robert. Java and SOAP. O'Reilly.
Anexos
Anexo A - XML Tags usados para definir un mensaje SOAP
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap,org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePricexmlns:m="Some-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Ejemplo:
El cliente necesita saber que producto corresponde con el código ID 827635 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductDetails xmlns="http://warehouse.example.com/ws"> <productID>827635</productID> </getProductDetails> </soap:Body> </soap:Envelope>
El Servicio Web responde con el siguiente mensaje:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws"> <getProductDetailsResult>
<productName>Toptimate 3-Piece Set</productName> <productID>827635</productID>
<description>3-Piece luggage set. Black Polyester.</description> <price>96.50</price> <inStock>true</inStock> </getProductDetailsResult> </getProductDetailsResponse> </soap:Body> </soap:Envelope>
Anexo B – Proceso General de Implementación
I
NTRODUCCIÓNEl Proceso General de Implementación (PGI) provee un método disciplinado de asignación de tareas y responsabilidades aplicable al desarrollo de proyectos de tecnología de la información.
El principal objetivo del PGI es el de asegurar la calidad de la implementación, cumpliendo con las necesidades y expectativas del Proyecto, dentro de un calendario y un presupuesto predecibles.
La siguiente figura muestra la arquitectura del proceso:
El PGI tiene dos dimensiones:
➢ El eje horizontal representa el tiempo, y muestra los aspectos relacionados con el ciclo de vida del proceso, a medida que el mismo progresa cronológicamente.
➢ El eje vertical representa las tareas centrales del proceso, los cuales agrupan aquellas actividades que se relacionan entre si en forma natural.
La primera dimensión representa el aspecto dinámico del proceso, y está expresado en términos de fases, iteraciones, e hitos.
La segunda dimensión representa el aspecto estático del proceso, y está expresado en términos de tareas, actividades, roles, artefactos. Administración de Proyecto Infraestructura Relevamiento de Negocio Control de Configuración Aseguramiento de Calidad Puesta en Marcha Prueba Formal Migración e Integración Implementación Solución Requerimientos Reingeniería de Procesos
PGI - Visión General
Fases
Iteraciones
Lanzamiento Elaboración Refinamiento Cierre
Refin 2 Refin 3 Refin 1
Elab 1 Elab 2
Inicial Final
Las tareas se clasifican en:
➢ Verticales: tareas directamente relacionadas con el objetivo de efectuar la implementación de la Solución; por ejemplo: Relevamiento de Negocio, Análisis y Diseño, Construcción, etc..
➢ Transversales: tareas que se relacionan solo indirectamente con el objetivo de efectuar la implementación, y están orientadas a dar soporte o servicios a las tareas verticales. Pueden ser vistas como “ciclos” o “rutinas” que se repiten con mínimas variantes a lo largo del proyecto. El ejemplo típico de este tipo de tareas es la Administración del Proyecto.
El diagrama anterior muestra cómo varía el énfasis a lo largo del tiempo (los recuadros con relleno sólido indican mayor énfasis que los recuadros con relleno punteado). Por ejemplo, en las primeras iteraciones se pone más énfasis en las actividades relacionadas con el relevamiento de las necesidades del Cliente y el análisis de las soluciones a las mismas, mientras que en las últimas iteraciones el énfasis está puesto en las actividades relacionadas con la implementación, migración de datos, prueba formal y puesta en marcha de la implementación.
La base teórica del PGI se sustenta en dos principios fundamentales:
➢ La utilización de un método iterativo e incremental de implementación. ➢ El empleo de casos de uso para la administración de los requerimientos.
I
MPLEMENTACIÓN ITERATIVAEl método iterativo plantea una aproximación progresiva al resultado final en la concreción del proyecto, la cual se va desarrollando por medio de la ejecución de sucesivas iteraciones, cada una de las cuales va agregando nueva funcionalidad a la ya disponible, a la vez que produce las mejoras que el Cliente o el Proyecto requiera sobre la funcionalidad implementada en iteraciones anteriores (aspecto dinámico del proceso).
Dentro de cada iteración se repite con énfasis variable un ciclo de tareas que se inicia con el relevamiento de los requerimientos del Cliente, y concluye con la puesta en marcha de una porción de la Solución (aspecto estático del proceso).
Para permitir este avance gradual, el método prevé como cierre de cada iteración la entrega al Cliente de una versión “utilizable” de la Solución, y fomenta el uso de prototipos a lo largo de la implementación.
El Cliente comprueba periódicamente la validez de las soluciones planteadas no solo por medio de la revisión de la documentación generada, sino también a través de de la utilización de las porciones de la Solución que van siendo implementadas.
Las principales características del método son las siguientes:
➢ La Solución se construye en forma incremental, implementando los requerimientos gradualmente. ➢ Se dispone periódicamente de una versión utilizable de la Solución.
➢ El equipo de trabajo aprende y mejora su rendimiento a lo largo del proyecto. ➢ El proceso se refina a lo largo del proyecto.
C
ASOS DEU
SOLos Casos de Uso (CU) constituyen una metodología de análisis de sistemas utilizada para identificar, clarificar y organizar requerimientos. Cada CU está compuesto por un conjunto de interacciones entre actores (personas físicas, personas jurídicas, aplicaciones, máquinas, etc.) dentro de un entorno específico, y en relación a una meta particular. Objetivo que quiere alcanzar el actor principal.
A su vez, cada CU contiene un escenario principal, y diferentes excepciones derivadas de los pasos del escenario principal. Por lo tanto, un CU puede ser visto como una colección de escenarios.
La vista de escenarios de CU es esencial para la administración de los requerimientos, especialmente desde el punto de vista de su priorización e implementación dentro del proyecto.
A su vez los CU son derivados de Historias del usuario (Story Boards) que son el relato lineal de las actividades que desarrolla o ejecuta un actor en particular. Desde esta perspectiva las historias de los usuarios son casos de uso no refinados que el analista convierte en caso de uso.
Desde un punto de vista general, un CU o conjunto de CU tiene las siguientes características: ➢ Permite organizar requerimientos funcionales.
➢ Modela las metas de las interacciones entre los actores.
➢ Registra los escenarios dentro de los que se producen las interacciones entre los actores. ➢ Describe un flujo principal de eventos, y posibles flujos alternativos excepcionales.
Los CU pueden ser utilizados con distintos propósitos: desarrollar los requerimientos de un proyecto de desarrollo o implementación de software, validar diseños, efectuar pruebas formales, etc. Una de las ventajas principales de su utilización deriva del hecho de que los CU permiten captar los requerimientos desde el punto de vista del Cliente (o del usuario) y de las metas perseguidas por el mismo. Los caos de uso se centran en los objetivos que deben alcanzar las personas dentro de una organización y por ende capturan los objetivos organizacionales.
Inicio de Fase Fin de Fase Tareas Verticales Tareas Transversales Fase 1 Inicio de Fase Fin de Fase Fase n Avance del Proyecto Varias iteraciones en cada Fase Inicio de Fase Fin de Fase Inicio de Fase Fin de Fase Tareas Verticales Tareas Transversales Fase 1 Inicio de Fase Fin de Fase Inicio de Fase Fin de Fase Fase n Avance del Proyecto Varias iteraciones en cada Fase
Las principales características de los CU son las siguientes:
➢ Cada CU describe fundamentalmente una meta a alcanzar o una necesidad a cubrir con respecto del negocio o de la automatización de tareas o procesos.
➢ Un CU captura el contrato entre los actores internos de una organización acerca de sus responsabilidades en ella con respecto a dicha meta en particular.
➢ Un CU describe las responsabilidades de la Solución bajo las distintas condiciones en las cuales debe responder ante los requerimientos de los actores.
➢ Un CU representa una respuesta a un determinado evento de negocio.
➢ Dada la diversidad de propósitos con los que son utilizados los CU, entre los mismos se puede encontrar una gran variedad de formatos, estilos de escritura, y nivel de formalidad. Por lo tanto, los CU pueden:
✔ Tener distintos alcances, describiendo el comportamiento de una organización completa, de un sistema
funcionando dentro de dicha organización, o de un componente dentro de un sistema.
✔ Tener distintos niveles de objetivo: nivel estratégico, nivel de tareas, nivel de sub-función.
✔ Tener distintos niveles de definición: informal, descripción del escenario principal, descripción de
extensiones.
✔ Pertenecer a distintos tipos: reales o abstractos.
➢ Pertenecer a distintas clases:
✔ CU de Usuario: Describe los objetivos del usuario con respecto a un sistema. Rescata las necesidades
operacionales del usuario y de su entorno. Identifica los pasos a seguir dado un objetivo. Evalúa un escenario principal y sus excepciones.
✔ CU de Negocio: Describe los objetivos del negocio y las necesidades de automatización y control. Identifica a
los responsables del negocio, su visión y sus necesidades. Permiten definir el alcance del negocio.
✔ Proceso: Describe los procesos, tanto automatizados como manuales. Establece el flujo principal de tareas
del proceso, y los flujos alternativos que dependen de las situaciones excepcionales. Enumera eventos disparadores, pre-condiciones y garantías mínimas del flujo de tareas.
Los casos de uso de negocio tienen un rol fundamental ya que el alcance global del proyecto está determinado por el conjunto de CU que se hayan identificado. De esta manera, estos constituyen la base sobre la cual se efectúan las estimaciones y la planificación de todo el proyecto.
Por este motivo resulta muy importante que en las primeras iteraciones se haga el mejor intento por identificar la totalidad de los CU más relevantes del negocio, ya que los mismos constituyen el principal factor que guía y dirige los esfuerzos de implementación.
Los CU relevados al inicio del proyecto pueden luego ir siendo refinados e implementados gradualmente a lo largo del resto de las iteraciones.
Aquellos CU de negocio que estén fuera del alcance deben derivar en mejoras a la Solución o en adecuaciones específicas realizadas dentro del marco del proyecto.
Por razones de estandarización, el PGI adopta un formato específico de CU, cuyos detalles pueden ser consultados en la descripción del artefacto correspondiente. A continuación se muestra un ejemplo de formato de CU:
Una vez recopilados los CU del proyecto, los mismos se organizan dentro de grupos de casos de uso, los cuales agrupan un conjunto de CU relacionados entre si (por ejemplo, por el hecho de pertenecer a un mismo área del negocio, o por tener un determinado conjunto de actores en común).
E
LEMENTOS DEL PROCESO ITERATIVOH
ITOSConstituyen los puntos en los que una iteración finaliza formalmente, e implican (en la casi totalidad de los casos) un “release” de la implementación.
F
ASESDesde el punto de vista de la Administración del Proyecto, el proceso se descompone a lo largo del tiempo en varias fases secuenciales, cada una de las cuales concluye en un hito principal. Esencialmente, una fase se puede definir como el período de tiempo transcurrido entre dos hitos principales.
ID: CU-xxxx (numerar secuencialmente, ajustar a la derecha y rellenar con ceros a la izquierda).
Objetivo: Objetivo en verbo activo y enunciado desde la perspectiva del actor principal.
Actor principal: Nombre o descripción del actor principal (el interés del mismo está representado por el objetivo del caso de uso).
Stakeholders e intereses: Nombre stakeholder + Interés del mismo sobre el caso de uso (estos intereses constituyen objetivos secundarios del caso de uso).
Descripción: Descripción breve, simple y específica del caso de uso. Debe servir como ampliación del objetivo, y como “precalentamiento” del desarrollo del escenario habitual y sus extensiones. Puede aportar “background” o información que ponga en contexto al caso de uso. No debe confundírselo con un escenario.
Garantía mínima: Indicación del estado de mínima propuesto para el caso de uso en función de las extensiones de falla.
En caso de éxito garantiza: Indicar el estado final del caso de uso en caso de éxito del mismo.
Precondiciones: Requisitos del caso de uso para ser ejecutado.
Triggers: Eventos disparadores del caso de uso. Pueden ser otros casos de uso.
Escenario principal:
Paso 1. – Paso 2 ... Paso N
Extensiones:
1.1. (Paso 1 de la excepción 1).
1.1.a (Excepción al paso 1 de la excepción 1). 1.2. (Paso 2 de la excepción 1).
Al finalizar cada fase se realiza una evaluación para determinar si se han alcanzado los objetivos de la misma. Si el resultado de la evaluación es satisfactorio, el proyecto avanza hacia la próxima fase.
Tal como puede apreciarse en el Diagrama de Visión General, las fases son disímiles entre si en cuanto a esfuerzo y planificación.
I
TERACIONESUna iteración puede ser vista como un mini-proyecto dentro del proyecto general, dentro del cual se ejecutan (con un énfasis que varía de acuerdo al grado de avance del proyecto) todas las tareas que componen el PGI, resultando en la gran mayoría de los casos en una implementación completamente funcional (aunque parcial) de la Solución General. Cada iteración comienza con una planificación de las actividades, y culmina con un “release” de la implementación, el cual puede o no ser “puesto en producción”.
R
OLESUn rol define el comportamiento y las responsabilidades de un individuo o un grupo de individuos que trabajan conjuntamente dentro del contexto del equipo de trabajo que realiza la implementación.
Cada rol tiene un conjunto cohesivo de actividades asignadas. Estas actividades se relacionan entre si, están acopladas funcionalmente, y se desarrollan más eficientemente si son realizadas por un mismo individuo.
Asimismo, cada rol es responsable de la generación de un determinado conjunto de artefactos.
Se debe notar que un rol no equivale a un individuo. La asignación entre individuos y roles, se efectúa durante el inicio del proyecto, y puede implicar que un mismo individuo desempeñe varios roles simultáneamente, y/o que un mismo rol sea desempeñado por varios individuos simultáneamente.