Analista funcional : definición, tareas y competencias

junio 24, 2010

Función de un analista funcional por definición

  • Relevar y gestionar las necesidades funcionales del cliente en la elaboración y ejecución del proyecto, cumpliendo con los estándares y la documentación requerida por las normas de calidad de la empresa. Relevar las necesidades del cliente considerando las características de su operatoria. Especificar los requerimientos y funcionalidades de la solución. Determinar la viabilidad de adaptación del sistema de acuerdo a las características del negocio del cliente. Actualizar información sobre nuevas tecnologías y productos propiciando el aprendizaje permanente.

Tareas que actualmente el mercado requiere de un analista funcional

  • Relevamiento, analisis y documentación de procesos integrales, requerimientos técnicos, requerimientos de negocio, etc
  • Tomar requerimientos de usuario y poder bajar a un mayor nivel de detalle a efectos de elaborar el pedido de mantenimiento al proveedor de software.
  • Saber detectar, en la medida de lo posible,  eventuales omisiones en el pedido de usuario y relevarlas para consignarlas en los pedidos a proveedores.
  • Guiar al usuario en la elaboración de los casos de prueba, y elección de la forma en que se visualizarán los resultados esperados por la modificación.
  • Validar/Obtener la aprobación de las definiciones del usuario.
  • Obtener compromiso de los usuarios involucrados.
  • Verificar el cumplimiento de los requerimientos desde el punto de vista del usuario.
  • Validación de Modelos de Diseño
  • Entrevistas con usuarios y proveedores
  • Revisión de estimaciones
  • Especificación de diseños funcionales de casos de uso
  • Emisión de procedimientos
  • Generar y mantener documentación sobre los circuitos operativos, sistemas que permita su análisis y mejoramiento.
  • Armado de lotes de prueba
  • Detectar la necesidad de nuevos sistemas o proponer mejoras
  • Administrar cambios.
  • Analizar alternativas de implementación
  • Parametrización
  • Implementar soluciones junto a el equipo de desarrollo
  • Soporte post implementación
  • Generar informes / reportes

Conocimientos técnicos requeridos

  • Metodologías formales de análisis y desarrollo
  • UML
  • SQL / PLSQL
  • Datawarehousing
  • Orientación de Objetos
  • Herramientas automáticas para soporte de procesos de testing
  • Herramientas Office / Project

Compentencias requeridas

  • Trabajo en equipo
  • Capacidad de análisis
  • Buena comunicación oral y escrita
  • Predisposición hacia el usuario

En mi opinión un analista funcional debe ser de nexo entre el mundo real, cotidiano y un sistema de información , con lo cual debe tener capacidad para poder moverse en diferentes dimensiones de la comunicación y resultar una suerte de TRADUCTOR /INTERPRETE entre lo que un usuario necesita / espera de un sistema y lo que un sistema provee/facilita a la tarea de uno o mas usuarios dentro de una organización.

En épocas pasadas, el analista funcional realizaba diversas y variadas funciones que con el correr del tiempo y la evolución de los equipos de desarrollo de sistemas en el país , han ido tomando nuevos caminos hacia la especialización.

El analista funcional sigue teniendo un perfil amplio, que no solamente interviene en la primera etapa clásica del proyecto ( relevamiento, análisis y diseño) sino que las nuevas metodologías hace que intervenga constantemente y su tarea sea generalicia.

Hay requerimientos técnicos que siempre son bienvenidos, especialmente base de datos y lenguajes de consulta sobre las mismas.

También el analista debe conocer las diferentes arquitecturas de sistemas, para poder entender, diseñar y hasta implementar sistemas en tales entornos.

La comunicación debería ser su fuerte. Con el usuario, con el cliente interno, con el equipo completo.

Anuncios

Ingenieria de Requerimientos

diciembre 4, 2009

1. Contexto

Actualmente, son muchos los procesos de desarrollo de software que existen. Desde los años 90, la Ingeniería de Software ha introducido una serie de estándares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y artículos relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y estándares de calidad. Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen tantos proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad? ¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema? Suena contradictorio que a pesar de los avances que ha dado la tecnología, aún existen procesos de producción informales, parciales y en algunos casos no confiables. En este contexto; La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. La principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; pretendiendo minimizar los problemas relacionados al desarrollo de sistemas. En muchas empresas y organizaciones, el reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definición de los requerimientos. Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también explican los motivos de los fracasos.

2. La ingeniería de requerimientos (IR) y sus principales actividades

¿Qué son Requerimientos? Normalmente, un tema de la Ingeniería de Software tiene diferentes significados.

De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE . (1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes. Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

Dificultades Encontradas al momento de definir los requerimientos

•Los requerimientos no son obvios y vienen de muchas fuentes. • Son difíciles de expresar en palabras (el lenguaje es ambiguo). • Existen muchos tipos de requerimientos y diferentes niveles de detalle. • La cantidad de requerimientos en un proyecto puede ser difícil de manejar. • Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros. • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. • Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. • Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto. Ingeniería de Requerimientos vs. Administración de Requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa

Algunas definiciones para ingeniería de requerimientos.

“Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema” Boehm 1979.

“Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones”. STARTS Guide 1987.

“Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos” Leite 1987.

“Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto” Rational Software

Importancia de la Ingeniería de Requerimientos

Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son:

  • Gestión de las necesidades del proyecto en forma estructurada
  • Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados.
  • Disminución de los costos y retrasos del proyecto.
  • Mejora la comunicación entre equipos.
  • Evita rechazos de usuarios finales; se obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniería de Requerimientos

Son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema.  Cada una tendrá sus intereses y jugara un rol especifico dentreo de la planificación del proyecto.

Los roles más importantes pueden clasificarse como sigue:

  • Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario.
  • Usuario Lider: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema.
  • Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, éstas personas son las responsables de la administracion de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.
  • Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan directamente con el cliente.
  • Personal de pruebas: se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de bases de datos, entre otros.


Tareas de un Analista Funcional

noviembre 5, 2009

El Analista Funcional es el vínculo de unión entre el usuario y el área informática de la empresa. Su misión consiste en elaborar el análisis funcional de nuevas aplicaciones para la organización, así como actualizar y mejorar las ya existentes; es decir, debe controlar, analizar y supervisar el desarrollo funcional de las aplicaciones informáticas, asegurando su correcta explotación y su óptimo rendimiento.

Presta apoyo a los distintos usuarios; es decir, realiza una labor de asesoramiento y capacitación, con el fin de evitar cualquier problema que pueda surgir con los programas y obtener así el máximo rendimiento de los mismos.

Otras funciones son evaluar tanto la viabilidad técnica como la económica de los desarrollos de las aplicaciones que se han de ejecutar, y preparar y elaborar toda la documentación técnica y de usuario de cada aplicación.

Competencias

* Gestión del proyecto en general
* Comunicación interpersonal
* Comprensión de procesos empresariales
* Conocimiento de la Organización
* Capacidad de Negociación
* Adaptación al Cambio
* Investigación y Proactividad

Competencias Técnicas

* Conocimiento de la herramienta
* Configuración del Proceso
* Identificación de Roles y Perfiles
* Migración de Datos
* Especificaciones de Desarrollos


15 hitos en la historia de internet….

octubre 31, 2009

La entrada que ingrese para “el cumpleaños de internet” me resulto super completa e interesante…. pero sí, reconozco que es muy muy larga… buscando buscando encontre este resumen…que me parecio muy interesante para compartir…..

1. El inicio

El 29 de Octubre a las 10:30 de la mañana se produjo el primer envío de un mensaje entre un computador y otro, entre servidores de la Universidad de Los Ángeles de California (UCLA) y el Instituto de Investigación de Stanford en San Francisco. Detrás de este hito estuvo Leonard Kleinrock, quien se incorporó después al programa ARPA del gobierno estadounidense para crear Arpanet.

gmail

2. El e-mail

El primero fue enviado en 1971 por Ray Tomlinson, un programador de Arpanet. Fue una de las primeras funciones comunicacionales de internet, y todavía se mantiene con fuerza entre nosotros. Fue Tomlinson quien además tuvo la idea de utilizar el símbolo “@” para separar al usuario y el servidor desde donde estaba saliendo el correo. El primer mensaje se perdió en la nube en todos estos años, pero Tomlinson ha dicho que el contenido era “completamente olvidable” y que probablemente lo que envió fue “QWERTYUIOP”.

3. El bautismo

En 1974, Arpanet ya no era utilizado sólo por el Departamento de Defensa de Estados Unidos, sino que por la oficina de correos de Inglaterra, y otras compañías de telecomunicaciones como Telenet, Datapac, AT&T, etc. Fue entonces cuando Vinton Cerf, junto a los investigadores Yogen Dalal y Carl Sunshine, propusieron que todos trabajaran en una sola red, unificada y global, llamada “internet”, nombre que se le mantiene hasta hoy.

4. La “WWW”

En 1989  apareció la World Wide Web – que aunque ahora suene como sinónimo a internet, no es lo mismo.

La Web es una red interconectada de documentos de hipertexto que se acceden a través de internet, y es lo que vemos hoy al navegar a través de un browser. Esto fue desarrollado por Tim Berners-Lee, un científico del CERN en Ginebra. El hipertexto ya había sido esbozado por varios pensadores, entre ellos Vannevar Bush y Douglas Engelbart, pero fue implementado finalmente por Berners-Lee.

5. El primer browser masivo

Mosaic 1.0 fue el primer navegador relativamente popular, lanzado en 1993, antes que Internet Explorer se comiera al mercado unos pocos años más tarde. Antes de Mosaic existían otros como Erwise o ViolaWWW, pero estaban limitados a un público muy reducido y experto. En tanto, Mosaic fue el primero en abrirse al público general. Su popularidad duró hasta la aparición de Netscape, lanzado en 1994, el que a su vez fue superado por Explorer en 1995.

doom-logo

6. DOOM

Lanzado en 1993, DOOM fue un videojuego que impulsó internet. Compartido a través de shareware para los primeros 7 levels, el shooter fue instalado en unos 10 millones de computadores en dos años. El programa introdujo el “multiplayer” de hasta 4 personas a través de una red LAN, algo que crecería progresivamente hasta los mundos masivos online que existen hoy.

7. Amazon y eBay

En 1995 y 1996 aparecieron Amazon y eBay, respectivamente, redefiniendo el comercio y los modelos de negocios de las empresas de venta minorista. Amazon, que partió como una tienda de libros online, se ha expandido a vender casi de todo hoy en día. Aunque sufrió con la burbuja de las punto com, su modelo de negocios sobrevivió y se mantiene hasta hoy.

Por otro lado, eBay instaló las subastas online, permitiendo a los usuarios comprar y vender entre unos y otros, aunque sea basura – la primera venta del servicio fue una impresora láser que estaba mala, por USD$14,83, a un “coleccionista de impresoras malas”.

8. El protocolo Wireless

En 1997 apareció el primer protocolo de conexión inalámbrica de internet en teléfonos móviles. Era muy, muy, muy lento, pero inició el camino a lo que es hoy el iPhone o Android de Google, con una infinidad de posibilidades para la movilidad de internet, que podemos llevar ahora en nuestro bolsillo.

google-oldi

9. Google

Corría 1998 cuando apareció el colorido Google, que llegó a desbancar a buscadores como AltaVista, Infoseek y otros. Con su nueva forma de buscar y rankear los resultados, se convirtió rápidamente en el favorito, manteniendo el liderazgo hasta hoy.

10. La burbuja punto com

Porque no podía ser todo perfecto, internet también tuvo su crisis en el 2000. Las empresas online estaban tan sobrevaloradas en medio del entusiasmo general en torno a esta tecnología, que a nadie se le había ocurrido preguntarse realmente cuánto valían estas firmas hasta que fue demasiado tarde.

Unos USD$5 billones del valor de las empresas tecnológicas desaparecieron durante la crisis, cuando cundió el pánico entre los inversionistas al caer en la cuenta de que en realidad, esto valía mucho menos de lo que habían pensado al principio. Pero este no fue el final de la Web, sino que sólo un llamado a dejar las nubes y volver a la realidad de que hacer negocios aquí no es magia.

wiki-logo

11. Wikipedia

La enciclopedia online y colaborativa, fuente de consulta universal de cualquier duda, nació en 2001 como iniciativa de Jimmy Wales y Larry Sanger. Aunque muchos todavía dudan de su confiabilidad en comparación a otras enciclopedias tradicionales, Wikipedia se ha impuesto como el centro de referencia más expandido del planeta.

12. Las redes sociales

Lanzados en 2002 y 2004 respectivamente, MySpace y Facebook dieron inicio al masivo mundo de las redes sociales. Los seis grados de separación se volvieron cada vez menos teóricos, y de verdad ahora parece que todos estamos conectados con todos en el mundo. Aunque muchos las utilicen para abrir galletas de la fortuna, han configurado una forma más de comunicación en internet, que todavía cambia e innova (con servicios como Twitter, por ejemplo).

13. La Web 2.0

En parte relacionado con las redes sociales, es la participación de los usuarios en la generación de contenido en internet. Si antes las personas entraban a la red para leer diarios, ahora los escriben, los comentan, suben sus videos a YouTube (lanzado en 2005) y participan en general, haciendo que la red sea un lugar para todos.

14. China

Los usuarios chinos superaron a los estadounidenses el año pasado, llegando a 298 millones a fines de 2008. El dato sugiere que la cantidad de personas que se conecta a internet al mes supera los 1.000 millones, una cifra gigantesca, aunque todavía queda gran parte de la población del planeta que está fuera, sobre todo en los países del llamado “tercer mundo”.

cloud15. Cloud Computing

Junto con el avance de las velocidades de internet y la capacidad de almacenamiento, aparece la “nube”, la posibilidad de guardar y compartir archivos exclusivamente en internet, sin necesidad de pasar por el un PC físico. Aunque la posibilidad existe desde hace años, sólo recientemente esto se ha convertido en algo masivo, gracias a la aparición de servicios online como Google Docs y otros.

Lo que viene

Es difícil imaginar qué vendrá ahora. ¿La Matrix? ¿Refrigeradores con internet? Muchos han hecho sus apuestas, pero lo que está claro es que internet todavía tiene mucho espacio para crecer e impresionarnos con las opciones que abre.


Cumpleaños de la INTERNET!!!!

octubre 29, 2009

Internet surgió de un proyecto desarrollado en Estados Unidos para apoyar a sus fuerzas militares. Luego de su creación fue utilizado por el gobierno, universidades y otros centros académicos.

Internet ha supuesto una revolución sin precedentes en el mundo de la informática y de las comunicaciones.

Internet es a la vez una oportunidad de difusión mundial, un mecanismo de propagación de la información y un medio de colaboración e interacción entre los individuos y sus ordenadores independientemente de su localización geográfica.

Orígenes

Maquinas conectadas entre  si, datos enviados en “paquetes”…

La primera descripción documentada acerca de las interacciones sociales que podrían ser propiciadas a través del networking (trabajo en red) está contenida en una serie de memorándums escritos por J.C.R. Licklider, del Massachusetts Institute of Technology, en Agosto de 1962, en los cuales Licklider discute sobre su concepto de Galactic Network (Red Galáctica).

El concibió una red interconectada globalmente a través de la que cada uno pudiera acceder desde cualquier lugar a datos y programas. En esencia, el concepto era muy parecido a la Internet actual. Licklider fue el principal responsable del programa de investigación en ordenadores de la DARPA desde Octubre de 1962. Mientras trabajó en DARPA convenció a sus sucesores Ivan Sutherland, Bob Taylor, y el investigador del MIT Lawrence G. Roberts de la importancia del concepto de trabajo en red.

En Julio de 1961 Leonard Kleinrock publicó desde el MIT el primer documento sobre la teoría de conmutación de paquetes. Kleinrock convenció a Roberts de la factibilidad teórica de las comunicaciones vía paquetes en lugar de circuitos, lo cual resultó ser un gran avance en el camino hacia el trabajo informático en red. El otro paso fundamental fue hacer dialogar a los ordenadores entre sí.

Para explorar este terreno, en 1965, Roberts conectó un ordenador TX2 en Massachusetts con un Q-32 en California a través de una línea telefónica conmutada de baja velocidad, creando así la primera (aunque reducida) red de ordenadores de área amplia jamás construida. El resultado del experimento fue la constatación de que los ordenadores de tiempo compartido podían trabajar juntos correctamente, ejecutando programas y recuperando datos a discreción en la máquina remota, pero que el sistema telefónico de conmutación de circuitos era totalmente inadecuado para esta labor. La convicción de Kleinrock acerca de la necesidad de la conmutación de paquetes quedó pues confirmada.

A finales de 1966 Roberts se trasladó a la DARPA a desarrollar el concepto de red de ordenadores y rápidamente confeccionó su plan para ARPANET, publicándolo en 1967. En la conferencia en la que presentó el documento se exponía también un trabajo sobre el concepto de red de paquetes a cargo de Donald Davies y Roger Scantlebury del NPL. Scantlebury le habló a Roberts sobre su trabajo en el NPL así como sobre el de Paul Baran y otros en RAND. El grupo RAND había escrito un documento sobre redes de conmutación de paquetes para comunicación vocal segura en el ámbito militar, en 1964.

Ocurrió que los trabajos del MIT (1961-67), RAND (1962-65) y NPL (1964-67) habían discurrido en paralelo sin que los investigadores hubieran conocido el trabajo de los demás. La palabra packet (paquete) fue adoptada a partir del trabajo del NPL y la velocidad de la línea propuesta para ser usada en el diseño de ARPANET fue aumentada desde 2,4 Kbps hasta 50 Kbps (5).

En Agosto de 1968, después de que Roberts y la comunidad de la DARPA hubieran refinado la estructura global y las especificaciones de ARPANET, DARPA lanzó un RFQ para el desarrollo de uno de sus componentes clave: los conmutadores de paquetes llamados interface message processors (IMPs, procesadores de mensajes de interfaz).

El RFQ fue ganado en Diciembre de 1968 por un grupo encabezado por Frank Heart, de Bolt Beranek y Newman (BBN). Así como el equipo de BBN trabajó en IMPs con Bob Kahn tomando un papel principal en el diseño de la arquitectura de la ARPANET global, la topología de red y el aspecto económico fueron diseñados y optimizados por Roberts trabajando con Howard Frank y su equipo en la Network Analysis Corporation, y el sistema de medida de la red fue preparado por el equipo de Kleinrock de la Universidad de California, en Los Angeles (6).

A causa del temprano desarrollo de la teoría de conmutación de paquetes de Kleinrock y su énfasis en el análisis, diseño y medición, su Network Measurement Center (Centro de Medidas de Red) en la UCLA fue seleccionado para ser el primer nodo de ARPANET. Todo ello ocurrió en Septiembre de 1969, cuando BBN instaló el primer IMP en la UCLA y quedó conectado el primer ordenador host .

El proyecto de Doug Engelbart denominado Augmentation of Human Intelect (Aumento del Intelecto Humano) que incluía NLS, un primitivo sistema hipertexto en el Instituto de Investigación de Standford (SRI) proporcionó un segundo nodo. El SRI patrocinó el Network Information Center , liderado por Elizabeth (Jake) Feinler, que desarrolló funciones tales como mantener tablas de nombres de host para la traducción de direcciones así como un directorio de RFCs ( Request For Comments ).

Un mes más tarde, cuando el SRI fue conectado a ARPANET, el primer mensaje de host a host fue enviado desde el laboratorio de Leinrock al SRI. Se añadieron dos nodos en la Universidad de California, Santa Bárbara, y en la Universidad de Utah. Estos dos últimos nodos incorporaron proyectos de visualización de aplicaciones, con Glen Culler y Burton Fried en la UCSB investigando métodos para mostrar funciones matemáticas mediante el uso de “storage displays” ( N. del T. : mecanismos que incorporan buffers de monitorización distribuidos en red para facilitar el refresco de la visualización) para tratar con el problema de refrescar sobre la red, y Robert Taylor y Ivan Sutherland en Utah investigando métodos de representación en 3-D a través de la red.

Así, a finales de 1969, cuatro ordenadores host fueron conectados cojuntamente a la ARPANET inicial y se hizo realidad una embrionaria Internet. Incluso en esta primitiva etapa, hay que reseñar que la investigación incorporó tanto el trabajo mediante la red ya existente como la mejora de la utilización de dicha red. Esta tradición continúa hasta el día de hoy.

Se siguieron conectando ordenadores rápidamente a la ARPANET durante los años siguientes y el trabajo continuó para completar un protocolo host a host funcionalmente completo, así como software adicional de red. En Diciembre de 1970, el Network Working Group (NWG) liderado por S.Crocker acabó el protocolo host a host inicial para ARPANET, llamado Network Control Protocol (NCP, protocolo de control de red). Cuando en los nodos de ARPANET se completó la implementación del NCP durante el periodo 1971-72, los usuarios de la red pudieron finalmente comenzar a desarrollar aplicaciones.

En Octubre de 1972, Kahn organizó una gran y muy exitosa demostración de ARPANET en la International Computer Communication Conference . Esta fue la primera demostración pública de la nueva tecnología de red. Fue también en 1972 cuando se introdujo la primera aplicación “estrella”: el correo electrónico.
En Marzo, Ray Tomlinson, de BBN, escribió el software básico de envío-recepción de mensajes de correo electrónico, impulsado por la necesidad que tenían los desarrolladores de ARPANET de un mecanismo sencillo de coordinación.

En Julio, Roberts expandió su valor añadido escribiendo el primer programa de utilidad de correo electrónico para relacionar, leer selectivamente, almacenar, reenviar y responder a mensajes. Desde entonces, la aplicación de correo electrónico se convirtió en la mayor de la red durante más de una década. Fue precursora del tipo de actividad que observamos hoy día en la World Wide Web , es decir, del enorme crecimiento de todas las formas de tráfico persona a persona.

Conceptos iniciales sobre Internetting

La ARPANET original evolucionó hacia Internet. Internet se basó en la idea de que habría múltiples redes independientes, de diseño casi arbitrario, empezando por ARPANET como la red pionera de conmutación de paquetes, pero que pronto incluiría redes de paquetes por satélite, redes de paquetes por radio y otros tipos de red. Internet como ahora la conocemos encierra una idea técnica clave, la de arquitectura abierta de trabajo en red.

Bajo este enfoque, la elección de cualquier tecnología de red individual no respondería a una arquitectura específica de red sino que podría ser seleccionada libremente por un proveedor e interactuar con las otras redes a través del metanivel de la arquitectura de Internetworking (trabajo entre redes). Hasta ese momento, había un sólo método para “federar” redes.

Era el tradicional método de conmutación de circuitos, por el cual las redes se interconectaban a nivel de circuito pasándose bits individuales síncronamente a lo largo de una porción de circuito que unía un par de sedes finales. Cabe recordar que Kleinrock había mostrado en 1961 que la conmutación de paquetes era el método de conmutación más eficiente.

Juntamente con la conmutación de paquetes, las interconexiones de propósito especial entre redes constituían otra posibilidad. Y aunque había otros métodos limitados de interconexión de redes distintas, éstos requerían que una de ellas fuera usada como componente de la otra en lugar de actuar simplemente como un extremo de la comunicación para ofrecer servicio end-to-end (extremo a extremo).

En una red de arquitectura abierta, las redes individuales pueden ser diseñadas y desarrolladas separadamente y cada una puede tener su propia y única interfaz, que puede ofrecer a los usuarios y/u otros proveedores, incluyendo otros proveedores de Internet. Cada red puede ser diseñada de acuerdo con su entorno específico y los requerimientos de los usuarios de aquella red.

No existen generalmente restricciones en los tipos de red que pueden ser incorporadas ni tampoco en su ámbito geográfico, aunque ciertas consideraciones pragmáticas determinan qué posibilidades tienen sentido. La idea de arquitectura de red abierta fue introducida primeramente por Kahn un poco antes de su llegada a la DARPA en 1972. Este trabajo fue originalmente parte de su programa de paquetería por radio, pero más tarde se convirtió por derecho propio en un programa separado.

Entonces, el programa fue llamado Internetting . La clave para realizar el trabajo del sistema de paquetería por radio fue un protocolo extremo a extremo seguro que pudiera mantener la comunicación efectiva frente a los cortes e interferencias de radio y que pudiera manejar las pérdidas intermitentes como las causadas por el paso a través de un túnel o el bloqueo a nivel local. Kahn pensó primero en desarrollar un protocolo local sólo para la red de paquetería por radio porque ello le hubiera evitado tratar con la multitud de sistemas operativos distintos y continuar usando NCP.

Sin embargo, NCP no tenía capacidad para direccionar redes y máquinas más allá de un destino IMP en ARPANET y de esta manera se requerían ciertos cambios en el NCP. La premisa era que ARPANET no podía ser cambiado en este aspecto. El NCP se basaba en ARPANET para proporcionar seguridad extremo a extremo. Si alguno de los paquetes se perdía, el protocolo y presumiblemente cualquier aplicación soportada sufriría una grave interrupción. En este modelo, el NCP no tenía control de errores en el host porque ARPANET había de ser la única red existente y era tan fiable que no requería ningún control de errores en la parte de los host s.

Así, Kahn decidió desarrollar una nueva versión del protocolo que pudiera satisfacer las necesidades de un entorno de red de arquitectura abierta. El protocolo podría eventualmente ser denominado “Transmisson-Control Protocol/Internet Protocol” (TCP/IP, protocolo de control de transmisión /protocolo de Internet). Así como el NCP tendía a actuar como un driver (manejador) de dispositivo, el nuevo protocolo sería más bien un protocolo de comunicaciones.

Ideas a prueba

DARPA formalizó tres contratos con Stanford (Cerf), BBN (Ray Tomlinson) y UCLA (Peter Kirstein) para implementar TCP/IP (en el documento original de Cerf y Kahn se llamaba simplemente TCP pero contenía ambos componentes). El equipo de Stanford, dirigido por Cerf, produjo las especificaciones detalladas y al cabo de un año hubo tres implementaciones independientes de TCP que podían interoperar.

Este fue el principio de un largo periodo de experimentación y desarrollo para evolucionar y madurar el concepto y tecnología de Internet. Partiendo de las tres primeras redes ARPANET, radio y satélite y de sus comunidades de investigación iniciales, el entorno experimental creció hasta incorporar esencialmente cualquier forma de red y una amplia comunidad de investigación y desarrollo [REK78]. Cada expansión afrontó nuevos desafíos.

Las primeras implementaciones de TCP se hicieron para grandes sistemas en tiempo compartido como Tenex y TOPS 20. Cuando aparecieron los ordenadores de sobremesa ( desktop ), TCP era demasiado grande y complejo como para funcionar en ordenadores personales. David Clark y su equipo de investigación del MIT empezaron a buscar la implementación de TCP más sencilla y compacta posible.

La desarrollaron, primero para el Alto de Xerox (la primera estación de trabajo personal desarrollada en el PARC de Xerox), y luego para el PC de IBM. Esta implementación operaba con otras de TCP, pero estaba adaptada al conjunto de aplicaciones y a las prestaciones de un ordenador personal, y demostraba que las estaciones de trabajo, al igual que los grandes sistemas, podían ser parte de Internet.

En los años 80, el desarrollo de LAN, PC y estaciones de trabajo permitió que la naciente Internet floreciera. La tecnología Ethernet, desarrollada por Bob Metcalfe en el PARC de Xerox en 1973, es la dominante en Internet, y los PCs y las estaciones de trabajo los modelos de ordenador dominantes. El cambio que supone pasar de una pocas redes con un modesto número de hosts (el modelo original de ARPANET) a tener muchas redes dio lugar a nuevos conceptos y a cambios en la tecnología.

En primer lugar, hubo que definir tres clases de redes (A, B y C) para acomodar todas las existentes. La clase A representa a las redes grandes, a escala nacional (pocas redes con muchos ordenadores); la clase B representa redes regionales; por último, la clase C representa redes de área local (muchas redes con relativamente pocos ordenadores).

Como resultado del crecimiento de Internet, se produjo un cambio de gran importancia para la red y su gestión. Para facilitar el uso de Internet por sus usuarios se asignaron nombres a los host s de forma que resultara innecesario recordar sus direcciones numéricas. Originalmente había un número muy limitado de máquinas, por lo que bastaba con una simple tabla con todos los ordenadores y sus direcciones asociadas.

El cambio hacia un gran número de redes gestionadas independientemente (por ejemplo, las LAN) significó que no resultara ya fiable tener una pequeña tabla con todos los host s. Esto llevó a la invención del DNS ( Domain Name System , sistema de nombres de dominio) por Paul Mockapetris de USC/ISI. El DNS permitía un mecanismo escalable y distribuido para resolver jerárquicamente los nombres de los host s (por ejemplo, http://www.acm.org o http://www.ati.es ) en direcciones de Internet.

El incremento del tamaño de Internet resultó también un desafío para los routers . Originalmente había un sencillo algoritmo de enrutamiento que estaba implementado uniformemente en todos los routers de Internet. A medida que el número de redes en Internet se multiplicaba, el diseño inicial no era ya capaz de expandirse, por lo que fue sustituido por un modelo jerárquico de enrutamiento con un protocolo IGP ( Interior Gateway Protocol , protocolo interno de pasarela) usado dentro de cada región de Internet y un protocolo EGP ( Exterior Gateway Protocol , protocolo externo de pasarela) usado para mantener unidas las regiones.

El diseño permitía que distintas regiones utilizaran IGP distintos, por lo que los requisitos de coste, velocidad de configuración, robustez y escalabilidad, podían ajustarse a cada situación. Los algoritmos de enrutamiento no eran los únicos en poner en dificultades la capacidad de los routers , también lo hacía el tamaño de la tablas de direccionamiento. Se presentaron nuevas aproximaciones a la agregación de direcciones (en particular CIDR, Classless Interdomain Routing , enrutamiento entre dominios sin clase) para controlar el tamaño de las tablas de enrutamiento.

A medida que evolucionaba Internet, la propagación de los cambios en el software, especialmente el de los host s, se fue convirtiendo en uno de sus mayores desafíos. DARPA financió a la Universidad de California en Berkeley en una investigación sobre modificaciones en el sistema operativo Unix, incorporando el TCP/IP desarrollado en BBN. Aunque posteriormente Berkeley modificó esta implementación del BBN para que operara de forma más eficiente con el sistema y el kernel de Unix, la incorporación de TCP/IP en el sistema Unix BSD demostró ser un elemento crítico en la difusión de los protocolos entre la comunidad investigadora.

BSD empezó a ser utilizado en sus operaciones diarias por buena parte de la comunidad investigadora en temas relacionados con informática. Visto en perspectiva, la estrategia de incorporar los protocolos de Internet en un sistema operativo utilizado por la comunidad investigadora fue uno de los elementos clave en la exitosa y amplia aceptación de Internet.

Uno de los desafíos más interesantes fue la transición del protocolo para host s de ARPANET desde NCP a TCP/IP el 1 de enero de 1983. Se trataba de una ocasión muy importante que exigía que todos los host s se convirtieran simultáneamente o que permanecieran comunicados mediante mecanismos desarrollados para la ocasión.

La transición fue cuidadosamente planificada dentro de la comunidad con varios años de antelación a la fecha, pero fue sorprendentemente sobre ruedas (a pesar de dar la lugar a la distribución de insignias con la inscripción “Yo sobreviví a la transición a TCP/IP”).

TCP/IP había sido adoptado como un estándar por el ejército norteamericano tres años antes, en 1980. Esto permitió al ejército empezar a compartir la tecnología DARPA basada en Internet y llevó a la separación final entre las comunidades militares y no militares. En 1983 ARPANET estaba siendo usada por un número significativo de organizaciones operativas y de investigación y desarrollo en el área de la defensa. La transición desde NCP a TCP/IP en ARPANET permitió la división en una MILNET para dar soporte a requisitos operativos y una ARPANET para las necesidades de investigación.

Así, en 1985, Internet estaba firmemente establecida como una tecnología que ayudaba a una amplia comunidad de investigadores y desarrolladores, y empezaba a ser empleada por otros grupos en sus comunicaciones diarias entre ordenadores. El correo electrónico se empleaba ampliamente entre varias comunidades, a menudo entre distintos sistemas. La interconexión entre los diversos sistemas de correo demostraba la utilidad de las comunicaciones electrónicas entre personas.

La transici1ón hacia una infraestructura global

Al mismo tiempo que la tecnología Internet estaba siendo validada experimentalmente y usada ampliamente entre un grupo de investigadores de informática se estaban desarrollando otras redes y tecnologías. La utilidad de las redes de ordenadores (especialmente el correo electrónico utilizado por los contratistas de DARPA y el Departamento de Defensa en ARPANET) siguió siendo evidente para otras comunidades y disciplinas de forma que a mediados de los años 70 las redes de ordenadores comenzaron a difundirse allá donde se podía encontrar financiación para las mismas.

El Departamento norteamericano de Energía (DoE, Deparment of Energy ) estableció MFENet para sus investigadores que trabajaban sobre energía de fusión, mientras que los físicos de altas energías fueron los encargados de construir HEPNet. Los físicos de la NASA continuaron con SPAN y Rick Adrion, David Farber y Larry Landweber fundaron CSNET para la comunidad informática académica y de la industria con la financiación inicial de la NFS ( National Science Foundation , Fundación Nacional de la Ciencia) de Estados Unidos.

La libre diseminación del sistema operativo Unix de ATT dio lugar a USENET, basada en los protocolos de comunicación UUCP de Unix, y en 1981 Greydon Freeman e Ira Fuchs diseñaron BITNET, que unía los ordenadores centrales del mundo académico siguiendo el paradigma de correo electrónico como “postales”. Con la excepción de BITNET y USENET, todas las primeras redes (como ARPANET) se construyeron para un propósito determinado.

Es decir, estaban dedicadas (y restringidas) a comunidades cerradas de estudiosos; de ahí las escasas presiones por hacer estas redes compatibles y, en consecuencia, el hecho de que durante mucho tiempo no lo fueran. Además, estaban empezando a proponerse tecnologías alternativas en el sector comercial, como XNS de Xerox, DECNet, y la SNA de IBM (8).

Sólo restaba que los programas ingleses JANET (1984) y norteamericano NSFNET (1985) anunciaran explícitamente que su propósito era servir a toda la comunidad de la enseñanza superior sin importar su disciplina. De hecho, una de las condiciones para que una universidad norteamericana recibiera financiación de la NSF para conectarse a Internet era que “la conexión estuviera disponible para todos los usuarios cualificados del campus”.

En 1985 Dennins Jenning acudió desde Irlanda para pasar un año en NFS dirigiendo el programa NSFNET. Trabajó con el resto de la comunidad para ayudar a la NSF a tomar una decisión crítica: si TCP/IP debería ser obligatorio en el programa NSFNET. Cuando Steve Wolff llegó al programa NFSNET en 1986 reconoció la necesidad de una infraestructura de red amplia que pudiera ser de ayuda a la comunidad investigadora y a la académica en general, junto a la necesidad de desarrollar una estrategia para establecer esta infraestructura sobre bases independientes de la financiación pública directa. Se adoptaron varias políticas y estrategias para alcanzar estos fines.

La NSF optó también por mantener la infraestructura organizativa de Internet existente (DARPA) dispuesta jerárquicamente bajo el IAB ( Internet Activities Board , Comité de Actividades de Internet). La declaración pública de esta decisión firmada por todos sus autores (por los grupos de Arquitectura e Ingeniería de la IAB, y por el NTAG de la NSF) apareció como la RFC 985 (“Requisitos para pasarelas de Internet”) que formalmente aseguraba la interoperatividad entre las partes de Internet dependientes de DARPA y de NSF.

El backbone había hecho la transición desde una red construida con routers de la comunidad investigadora (los routers Fuzzball de David Mills) a equipos comerciales. En su vida de ocho años y medio, el backbone había crecido desde seis nodos con enlaces de 56Kb a 21 nodos con enlaces múltiples de 45Mb.Había visto crecer Internet hasta alcanzar más de 50.000 redes en los cinco continentes y en el espacio exterior, con aproximadamente 29.000 redes en los Estados Unidos.

El efecto del ecumenismo del programa NSFNET y su financiación (200 millones de dólares entre 1986 y 1995) y de la calidad de los protocolos fue tal que en 1990, cuando la propia ARPANET se disolvió, TCP/IP había sustituido o marginado a la mayor parte de los restantes protocolos de grandes redes de ordenadores e IP estaba en camino de convertirse en el servicio portador de la llamada Infraestructura Global de Información.

El papel de la documentación

Un aspecto clave del rápido crecimiento de Internet ha sido el acceso libre y abierto a los documentos básicos, especialmente a las especificaciones de los protocolos.

Los comienzos de Arpanet y de Internet en la comunidad de investigación universitaria estimularon la tradición académica de la publicación abierta de ideas y resultados. Sin embargo, el ciclo normal de la publicación académica tradicional era demasiado formal y lento para el intercambio dinámico de ideas, esencial para crear redes.

En 1969 S.Crocker, entonces en UCLA, dio un paso clave al establecer la serie de notas RFC ( Request For Comments , petición de comentarios). Estos memorándums pretendieron ser una vía informal y de distribución rápida para compartir ideas con otros investigadores en redes. Al principio, las RFC fueron impresas en papel y distribuidas vía correo “lento”. Pero cuando el FTP ( File Transfer Protocol , protocolo de transferencia de ficheros) empezó a usarse, las RFC se convirtieron en ficheros difundidos online a los que se accedía vía FTP.

Hoy en día, desde luego, están disponibles en el World Wide Web en decenas de emplazamientos en todo el mundo. SRI, en su papel como Centro de Información en la Red, mantenía los directorios online . Jon Postel actuaba como editor de RFC y como gestor de la administración centralizada de la asignación de los números de protocolo requeridos, tareas en las que continúa hoy en día.

El efecto de las RFC era crear un bucle positivo de realimentación, con ideas o propuestas presentadas a base de que una RFC impulsara otra RFC con ideas adicionales y así sucesivamente. Una vez se hubiera obtenido un consenso se prepararía un documento de especificación. Tal especificación seria entonces usada como la base para las implementaciones por parte de los equipos de investigación.

Con el paso del tiempo, las RFC se han enfocado a estándares de protocolo –las especificaciones oficiales- aunque hay todavía RFC informativas que describen enfoques alternativos o proporcionan información de soporte en temas de protocolos e ingeniería. Las RFC son vistas ahora como los documentos de registro dentro de la comunidad de estándares y de ingeniería en Internet.

El acceso abierto a las RFC –libre si se dispone de cualquier clase de conexión a Internet- promueve el crecimiento de Internet porque permite que las especificaciones sean usadas a modo de ejemplo en las aulas universitarias o por emprendedores al desarrollar nuevos sistemas.

El e-mail o correo electrónico ha supuesto un factor determinante en todas las áreas de Internet, lo que es particularmente cierto en el desarrollo de las especificaciones de protocolos, estándares técnicos e ingeniería en Internet. Las primitivas RFC a menudo presentaban al resto de la comunidad un conjunto de ideas desarrolladas por investigadores de un solo lugar. Después de empezar a usarse el correo electrónico, el modelo de autoría cambió: las RFC pasaron a ser presentadas por coautores con visiones en común, independientemente de su localización.

Las listas de correo especializadas ha sido usadas ampliamente en el desarrollo de la especificación de protocolos, y continúan siendo una herramienta importante. El IETF tiene ahora más de 75 grupos de trabajo, cada uno dedicado a un aspecto distinto de la ingeniería en Internet. Cada uno de estos grupos de trabajo dispone de una lista de correo para discutir uno o más borradores bajo desarrollo. Cuando se alcanza el consenso en el documento, éste puede ser distribuido como una RFC.

Debido a que la rápida expansión actual de Internet se alimenta por el aprovechamiento de su capacidad de promover la compartición de información, deberíamos entender que el primer papel en esta tarea consistió en compartir la información acerca de su propio diseño y operación a través de los documentos RFC. Este método único de producir nuevas capacidades en la red continuará siendo crítico para la futura evolución de Internet.

El futuro: Internet 2

Internet2 es el futuro de la red de redes y está formado actualmente por un consorcio dirigido por 206 universidades que junto a la industria de comunicaciones y el gobierno están desarrollando nuevas técnicas de conexión que acelerarán la capacidad de transferencia entre servidores.

Sus objetivos están enfocados a la educación y la investigación académica. Además buscan aprovechar aplicaciones de audio y video que demandan más capacidad de transferencia de ancho de banda.


Blogs…

octubre 9, 2009

en los que he colaborado:

http://azuldelago.blogspot.com/

http://www.elsenderodelasrosas.blogspot.com/

http://delsurtejidos.blogspot.com/

http://dianadreyfusrelatosdesuperficie.blogspot.com/


Claves para ser un buen SEO sin engañar a Google

octubre 9, 2009

de http://www.elpais.com :
Hay que conocer las tendencias de búsqueda de palabras clave para incorporarlas a tu contenido. El keyword research es fundamental.

Hay que responder con tus páginas a las preguntas que se hacen los internautas. Tienes que pensar como ellos.

Pero hay más claves para ser un buen SEO-SEM, según las recomendaciones dadas por los profesionales del sector

Conoce a tus visitantes. Hay que saber cómo piensan y qué palabras clave utilizan en buscadores. Éstas se deben incorporar a las zonas destacadas de la página web: primeras líneas de texto, pies de foto…

Crea contenido actualizado y de calidad. Es la principal fuente de enlaces externos y la forma directa de mejorar la indexación. No se debe abusar de palabras clave en los textos.

Diseñar mapas web sencillos. Cuanto más plana, limpia y sencilla sea la estructura de la página, más fácil lo tendrán los buscadores para indexarla.

No engañar a Google. Las técnicas de encubrimiento de páginas, granjas de enlaces o spam son hoy fácilmente detectables y comportan penalizaciones.

Formar a otros empleados. El posicionamiento no sólo es cuestión de un experto, sino de toda una empresa. Los responsables de contenido, diseño web y mercadotecnia también deben pensar en SEO.

Desarrollar habilidades técnicas y de marketing. Un buen especialista en SEO debe demostrar tanto conocimientos técnicos como de marketing online. Combinar ambos frentes es fundamental.

Abrirse a Twitter y las redes sociales. El microblogging, las redes sociales y la búsqueda en tiempo real van más allá de Google y Bing. Entender su funcionamiento generará más tráfico.

Probar, medir y probar. Lo que funciona para unas webs puede no valga para otras. La base del SEO es probar, medir los resultados y volver a probar hasta quedar satisfecho.