Ufff... estuvo cerca.

Saludos. Por fin ya estoy de regreso en casa, después de unos días terribles de insomnio y dolencias. Les cuento el porque:

El jueves pasado (22 si no me equivoco), después de entregar mi trabajo de la encuesta de protección social (EPS) de la Universidad de Chile, donde ya eran casi las 17:00 Hrs., empece con unos malestares en el estomago, mejor dicho, en todo el estomago, y es aquí donde comienza la historia. De a poco fueron tornándose intolerables al punto que regrese a mi casa para ver que podía hacer y que me recomendaban mis papás. La cosa es que fui al consultorio, y para hacer notar la incompetencia que comete el ser humano en algunos casos importantes, me categorizaron como el típico 'colon irritable' y me pusieron 'viadil'. Como vieron que no pasaba nada, un medico muy inteligente me dio un calmante mas fuerte, 'dipirona' junto con el suero, y claro, al rato ya no me dolía. Eran como las 1:00 Hrs. y ya estaba en mi casa durmiendo en mi cama. Hasta aquí todo va bien. A las 3:30 Hrs. me despierto con un dolor tremendo nuevamente, pero que logro controlar con hiervas (ojo, hiervas como menta o ruda, no piensen mal). Y sigue la historia ...
...Era de mañana, a eso de las 6:00, cuando despierto, otra ves, con un dolor ahora un poco diferente a los anteriores, ya que se ubicaba en el costado izquierdo inferior de mi estomago, y, haciendo memoria, me parecía que ahí estaba la apéndice. Al final, después de una espera en el consultorio decidimos ir a la urgencia del hospital Sótero del Río junto con mis padres, en donde tuve que esperar mas de 12 horas para que me pudieran operar. La cosa es que si se hubieran demorado unas horas mas, quizás, y que es lo mas probable, no estaría vivo, o también hubiese tenido que pasa hasta el año nuevo en el hospital. Por otro lado, si me hubiesen atendido antes, quizás habría salido un dia antes de alta.

Bueno, después de la operación y la recuperación, ya estoy de nuevo, solo que un poco quejumbroso, y espero recuperar lo que no hice la noche del 24 de diciembre y hacerlo la noche del 31 que se acerca, así que a prepararse y a seguir la dieta, los consejos del doctor y lógico, también los de la enfermera ;-).
Salu2!

Procesos de Desarollo de Ingeniería de Software

En este post voy a hablar, continuando con lo anterior, sobre Ingeniería de Software y los modelos y metodologías de desarrollo. En este caso me basara y daré mi opinión sobre otro documento llamado "Procesos de desarrollo: RUP, XP y FDD", creado por Alberto Molpeceres.
________________________________________

La verdad es que cuando leí este paper no había oído hablar, ni siquiera mencionar el proceso de desarrollo FDD, pero ahora lo tengo mucho más claro.

En este paper se narra sobre las ventajas y dificultades que se tienen al momento de adoptar un 'Proceso de Desarrollo' o una 'Metodología de Programación', tanto del punto de vista de los programadores como de los Jefes de Desarrollo o Jefes de Proyecto. También se expone el motivo del cual hoy en día existen muchas mutaciones de estos procesos, y es más que nada a que ninguno es posible pasarlo directamente de la teoría a la práctica. Hay ciertos casos que se podría hacer, pero, como por arte de magia, presente en toda área del conocimiento, nunca no salen las cosas como debería, o como muestran los libros o manuales.

Este documento clasifica los procesos de desarrollo en:
  • Ligeros: Aquellos procesos que buscan la calidad del software por medio de la comunicación directa entre desarrolladores y entre el desarrollador o equipo con el cliente.
  • Pesados: A diferencia de los ligeros, estos buscan la calida del software asegurando una buena documentación y ordenando muy bien todo el desarrollo.

Se mencionan además otra clase, como una mezcla entre las dos, que, reflejado en un proceso, seria el FDD, mientras que el ligero y el pesado es XP y RUP respectivamente.

Veamos ahora en que consiste cada uno:

Proceso Unificado Rational o RUP

RUP no solo esta pensado para proyectos de Software, sino para cualquier proyecto, y se divide en las siguientes fases:

  1. Intercepción (Puesta en marcha)
  2. Elaboración (definición, análisis y diseño)
  3. Construcción (Implementación)
  4. Transición (Fin del proyecto y puesta en producción)

Cada fase es iterativa, siguiendo el modelo en cascada para cada etapa mencionada anteriormente.



RUP, además, define nueve actividades a realizar en cada fase del proyecto:

  1. Modelado del negocio
  2. Análisis de requisitos
  3. Análisis de diseño
  4. Implementación
  5. Prueba
  6. Distribución
  7. Gestión de configuración y cambios
  8. Gestión de proyecto
  9. Gestión de entorno

El flujo de trabajo entre las actividades mencionadas se ven en el diagrama de actividad. Este proceso define roles que se asignan entre los miembros del equipo del proyecto, asignando las tareas y el 'artefacto' (resultado) resultante de cada uno.



Para ver que se cumpla lo esperado, RUP ocupa los casos de uso, dejándonos claro de que esta muy enfocado a la estructura del sistema, documentándose lo que mas se pueda, y lógicamente usando UML y su infinidad de diagramas.

Existen versiones reducidas de RUP, ya que por lo descrito, se necesita un proyecto muy grande para poder aplicarlo como lo señala la teoría, y el la practica hay que repartir 31 roles y generar más de 100 artefactos.

Programación Extrema o XP

Completamente diferente al proceso anterior, XP es una metodología ágil, preocupándose principalmente del objetivo, mejorando las relaciones interpersonales y velocidad de reacción, cosa que RUP no hace.

Se intenta minimizar el riesgo de fallar en el proceso usando a un representante del cliente a tiempo completo para el equipo de desarrollo. La función de este es de contestar rápidamente a cualquier duda del equipo y corregir de la misma manera, sin tener que retrasarse en 'absurdas' reuniones de tomas de decisiones.



Algunos instrumentos que usa XP para el proceso, y casi igual que RUP, ocupa UserStories como base de desarrollo, similar a los casos de uso de RUP, las cuales son las historias del cliente frente a diferentes escenarios con el sistema a desarrollar. En base a esto, y a la arquitectura del sistema planteada para el desarrollo se crean planes de releases, que permiten ver el avance del software, y su evaluación por el cliente. En cada release se verán cuanto se han cumplido los objetivos y, junto con el representante del cliente, se definirán las iteraciones, de pocas semanas, necesarias para alcanzar los objetivos la siguiente release.

Tambien, y en base a las UserStories, se encuentras los escenarios de prueba, que permiten evaluar cada pieza de software y ver su trazabilidad.

Los casos de prueba son fundamentales para XP, ya que aseguran, de que si en algun momento se requiere escacalar el sisetma, se tendra que evaluar si la pieza de software sigue ogreciendo la misa funcionalidaad inicial. La idea tambien es que sean lo más automatizados posibles, permitiendo evaluar rápidamente si es que se ha perdido funcionalidad o si algo anda mal.

Vista general del XP

En la fase de codificación del sistema, concretando el software, siempre se trabaja en parejas y con un ordenador, permitiendo de que la calidad aumente en tiempo real, a medida de que cada programador crea mejores algoritmos o entrega más funcionalidad. También se insta a rotar las parejas, haciendo de que en un momento cada uno haya trabajado con todo el equipo y que haya pasado por todas las partes del software, entregándole una visión completa del sistema a todo el equipo. De esta forma se evita el problema de que solo algunos conocen todo el sistema y los con menos experiencia se benefician al trabajar con los con mas experiencia, mejorando su nivel y del equipo en general.

XP tiene como objetivo primario el funcionamiento del sistema, y cumplir los planes de releases, para luego trabajar en mejorar los algoritmos. Es decir se ocupa la filosofía KISS (Keep It Simple Stupid), un diseño evolutivo de "conseguir la funcionalidad de la manera más simple posible”. Esto permite ahorrar mucho tiempo en la fase de análisis, dándole menos importancia como fase individual, pero integrándola al final de obtener funcionalidad.

Desarrollo Guiado por la Funcionalidad o FDD

En el documento lo anuncian claramente como un proceso ligero, pero también como a medio camino entre RUP y XP.

Esta pensado para proyectos con tiempo de desarrollo cortos, es decir, menos de un año, e iteraciones cortas, aproximadamente 2 semanas, que a medida que itera va generando, al igual que XP, software funcional que el cliente y/o dirección de empresa pueden ver y monitorizar.

Cada iteración se basa en features o funcionalidades, que son partes del sistema que tiene significado para el cliente. Esto quiere decir de que evitamos explicarle al cliente lo que significa construir el sistema de persistencia, sino que preguntamos cosas más concretas, como 'enviar pedido por e-mail'.

Las fases de desarrollo de FDD son:

  1. Desarrollo de un modelo general
  2. Construcción de una lista de funcionalidades
  3. Plan de releases en base a las funcionalidades a implementar
  4. Diseñar en base a las funcionalidades
  5. Implementar en base a las funcionalidades
  6. En las primeras tres fases se ocupa gran parte del tiempo al inicio del proyecto, pero a medida que se avanza en las iteraciones las otras dos van ocupando más tiempo, y las primeras solo son para el refinamiento del release siguiente.
A diferencia de XP, siempre hay un responsable último con mayor experiencia, que tendrá la ultima palabra en el caso de problemas sin resolver o sin acuerdo, lo cual además permite asignar responsabilidades que todas las empresa exigen, respetando la jerarquía. Ahora, al igual que XP, en FDD se trabaja como grupo, por lo que los menos inexpertos se ven beneficiados de la experiencia de otros.



Los diferentes componentes que se implementaran en una release se dividen en los diferentes sub-grupos y cadaa clase que se escriba tiene un propietario, y es quien puede hacer cambios a su parte del programa. Pueden darse casos de que un programador sea dueño de diferentes funcionalidades.

A diferencia de los otros procesos, el implementar una funcionalidad implica también la preparación y ejecución de los test, revisión del código (distribuir el conocimiento del sistema como un todo y aumentar la calidad) y la integración de las partes, estando en fases diferentes en los otros procesos.

FDD establece algunas medidas útiles que son muy importantes para la dirección de la empresa y muestran el estado actual del desarrollo y realizar, en el futuro, mejores estimaciones.

Comparando procesos

En el documento se señala que es complicado establecer una comparación concreta, sino que se debe realizar según los medios que emplean y el resultado. Lógicamente todos buscan aumentar la calidad del software, pero cada uno ocupa métodos diferentes, todos quieren el mismo fin.

La mayoría de los procesos de desarrollo que nacen hoy en día son orientados a objetos, y RUP, XP y FDD no son la excepción.

El tamaño de los equipos es una variable muy importante, ya que, como se menciono en el método de RUP, repartir esa gran cantidad de roles en un equipo pequeño, resulta imposible. XP y FDD son ideales para equipos pequeños y proyectos cortos. Ahora, el que permite mas escalabilidad de estos dos, es FDD, ya que a mayor tamaño de código y/o equipo, mayor es la necesidad de cierta organización.

Obtención de requisitos

RUP y XP usan UseCases y UserStories, los cuales describen los requerimientos del sistema, sin ahondar en detalles de la implementación, a diferencia de FDD, que no los define explícitamente y solo se define el proceder al momento de que se recogen los requisitos, de la forma que se quiera, y dividiéndolos en las tres primeras fases del proyecto.

Carga de trabajo

XP trata de cierta manera alivianar las tareas de los desarrolladores, dejando de lado tareas como el modelado, generación de documentación externa, etc., cuyo efecto se contrarresta con la presencia de un representante del cliente. En el caso de que algo ande mal, o se desea cambiar una funcionalidad, se habla directamente con el representante del cliente y listo.

RUP, en cambio, como proceso pesado, tiene muchísima documentación, y por lo tanto, no es muy deseable hacer algún tipo de cambio, habiendo ya generado esta. RUP se apoya en sus diferentes planes(Plan de desarrollo, plan de iteración, plan de calidad, etc.), cosa de prever de manera anticipada cualquier problema con el desarrollo.

FDD, al ser un proceso intermedio, genera más documentación que en XP, pero menos que RUP. Igual determina que se debe documentar, existen márgenes, y responsabilidades.

Relación con el Cliente

RUP, en cada ciclo entrega diferentes documento al cliente que permiten evaluar los diferentes aspectos del proyecto, como los riesgos, los diferentes planes, prototipos, y calidad.

XP y FDD aseguran calidad y comunicación con el cliente en base a una interacción mas directa y sin formalismo de documentación.. En estos dos metodos, el cliente, después de cada iteración el cliente recibe un rerlease, pudiendo evaluar directamente el estado del proyecto. También, y con respecto a la calidad, se apoyan en test propios, permitiendo su objetivo primario: la funcionalidad.
Desarrollo

Estos tres procesos se basan en e modelo iterativo, orientando a la refinación y que permite llegar de manera progresiva al objetivo.

XP y FDD tienen iteraciones mas cortas que RUP, ya que los desarrolladores tienen una menor carga.

RUP resulta un poco mas completo a la hora de ingresar a empresas grandes y formalistas, ya que cada release que se entrega al cliente, a diferencia de FDD y XP, se apoya en toda su documentación, casi tan completa como el producto final, solo que con menos funcionalidades.

Código Fuente

XP presenta una gran libertad con respecto a esto, ya que es el único que lo comparte con el equipo entero, al ser equipos pequeños y una comunicación rápida y constante. Los otros dos, en cambio, optan por dar propiedad al código, y a pesar de hacer grupos y sesiones de trabajo conjuntos, en los que hay comunicación directa, resulta mucho más engorroso que en XP.

Conocimiento sobre la Arquitectura

Tanto XP y FDD, como los actuales procesos de desarrollo de software, tratan de incentivar las reuniones directas para mejorar la arquitectura, auque XP lo hace con la programación en pares, en donde se revisa el código en tiempo de programación y busca generar una discusión entre compañeros para mejorar los algoritmos, en FDD se hace con reuniones con el programador más experto y ver que se puede mejorar o si hay algo mal.

Evaluación del Estado del Proyecto

Con respecto a las métricas de evaluación y de proyección, FDD es el que tiene la mejor postura, ya que los reportes están distribuidos en la jerarquía con su propio sistema de métricas y en unidades pequeñas.

Debilidades

Ninguno de los procesos puede llevarse a la practica un 100% por lo cual existen varias metodologías alternativas, o bien uno puede crear su propio proceso adaptado a sus circunstancias.

Ejemplo de lo anterior, RUP, podría decirse que solo es aplicable a equipos grandes de trabajo, pero existen procesos derivados de RUP que ocupan los mismos pasos para llegar al producto final, pero con ciertas adaptaciones, dependiendo de las circunstancias,

Con respecto a XP, el contar con un representante competente del cliente, que conozca las reglas del negocio, un 100% para el equipo de desarrollo es casi imposible, puesto que el es parte importante de la empresa. Así mismo, el cliente en si, también dispone, en general, de poco tiempo y el es aun más indispensable en la empresa. Esto dificulta el trabajo en XP generalmente

Un punto a favor de XP es la programación en parejas, que debería implementarse en cualquier proceso de desarrollo de software, pero siempre se debe manejar hasta que punto esto puede ser un beneficio. El programar en parejas, para algunos es algo tonto, ya que uno esta en el PC mientras que el otro observa. Hay muchas dificultades sobre todo cuando hay roses personales entre desarrolladores.

En casos donde se requiera documentación externa, más allá del código fuente, XP no es deseado para un desarrollo y mucho menos cuando es documentación por formalismos para con el cliente o empresa. En estos casos RUP y FDD son mejores alternativas.

FDD, que parece no tener problemas, presenta dificultades al requerir de que cada grupo de trabajo sea guiado por un desarrollador mas experto, por lo que se complica aun más la cosa si son un equipo nuevo.


__________________________________

Bueno, ojala les gusten mis comentarios, ya que he dedicado tiempo y esfuerzo (mas tiempo que esfuerzo) en entregarles este documento, que resulta muy interesante, sobre todo para quienes nos gusta la informática y la estudiamos. Saludos.

Modelos y Metodologias para desarrollo de proyectos en informática

Para los lectores de este Blog, los invito a iniciar un pequeño debate sobre modelos y metodologías para la Ingeniería de Software, basados en los conocimientos adquiridor por mi en el ramo de lenguajes y métodos de programación y un poco de Wikipedia. Este primer post, lo realizare en base a los modelo y metodologías más usadas. No duden en mandar comentarios o si ven algo catastroficamente mal :-P

Modelos de Desarrollo de Software

Como definición de modelo, podemos decir que es un esquema o una estructura que nos indica cuales son los pasos a seguir dentro del ciclo de vida de una aplicación. Sin embargo no nos dice que limites tiene cada uno de los pasos, ni que se debe cumplir para pasar de uno a otro, o al siguiente.

Faces en el Desarrollo de Software

Es el también llamado ciclo de vida del software, y cuenta con las siguientes faces:

  • Análisis de requisitos : Esta es la fase inicial del desarrollo, y según muchos, la más importante, ya que en base a estos requerimientos se construirá el proyecto. Se genera un documento llamado SDR(Documento de Especificación de Requisitos), que contiene todos los requisitos del sistema, y que, en general, deben ser resultado de mutuo acuerdo entre el desarrollador y el cliente, y firmado por ambos. Existen dos tipos de requerimientos:
    • Requerimientos funcionales: son parte intima del programa y reflejan las reglas del negocio para el cual el sistema va a conocer y manejar. Van también a depender de que importancia le de el cliente a cada requerimiento. Ejemplo de este tipo de requerimiento es, en el caso de un mantenedor de alumnos, que si la nota final es menor o igual a un 3,95 el alumno reprueba, o en el caso de un programa para un supermercado, que se envíe mensualmente un informe a la sucursal central, con cierta información. Son las reglas del negocio en si.
    • Requerimientos no funcionales : son aquellos en los que no se depende del sistema para poder definirlos, y no pertenecen a la regla del negocio. Ejemplo clásico es si la aplicación va a correr sobre una plataforma software y/o hardware específica o, dependiendo del enfoque que exija el cliente, los colores institusionales, formatos de informes o documentos generados por el sistema.
  • Diseño del sistema : Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Esta parte no fue vista en clases, apreciando que es aplicable solo para un grupo de desarrolladores. Cuando son dos o tres personas, no es necesario hacer tal documento, pero si tratar de que todos entiendan el sistema como un todo y como interactúan sus partes.
  • Diseño del programa : Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. Aquí se decide la manera vamos a reflejar cada uno de los requerimientos en piezas de software, con que lenguaje y/o plataforma y/o framework.
  • Codificación : Es la fase de programación propiamente dicha. Aquí se desarrolla el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido. Aquí implementamos el código planteado en la fase anterior, y según nuestro modelo, metodología o proceso de desarrollo, será cuanto avancemos, como haremos la documentación, y en base a que documentos basaremos nuestro trabajo.
  • Pruebas o Tests : En base a la primera fase, se elaboran, tanto los "casos de uso" como "casos de prueba", los cuales evaluaran si cada pieza de software realiza lo indicado por las reglas del negocio, y dependiendo, generara mas documentación para evaluar el avance.
  • Implementación : El software obtenido se pone en producción. Se implementan los niveles software y hardware que componen el proyecto. La implementación es la fase que dura más y con más cambios en el ciclo de elaboración de un proyecto. Este paso debe manejarse con mucho cuidado, y dependiendo del modelo, hacer diferentes implementaciones, para pasarlas finalmente a producción.
  • Mantenimiento : Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios. Esta fase tampoco fue mencionada en clases, y es de suma importancia, a parte de ser nuestro sueldo por lo que dure el software, o que nos cambien por otro equipo, es la parte de soporte que se entregara al cliente en el caso que quiera hacer un cambio al sistema, o se pardusca un cambio en las reglas del negocio.
Hay otras faces que, dependiendo del modelo, metodología o proceso de desarrollo van a cambiar, con lo que pueden haber unas mas u otras menos. De todas maneras, nada es estricto, y menos aun en la practica.

Nótese además que cada fase, opcionalmente, va acompañada con documentación, cosa que queda mas explicita en las Metodologías, siendo mas estrictas que los modelos en todos los aspectos.

El Modelo Lineal o en Cascada

Este modelo, como su nombre lo indica, y requiere terminar una fase completa para pasar a la siguiente, dejando nula posibilidad de volver atrás, por lo que hay que empezar de nuevo. Esto implica de que si empezamos a desarrollar un software con este modelo, una vez terminado, en el caso de tener algún problema en la ultima etapa, no podemos hacer cambios directamente en la ultima fase, y hay que volver al principio y hacer todo nuevamente, y dependiendo de la metodología, quizás esto sea muy engorroso, sobre todo cuando se pide mucha documentación. En lo personal, no creo que exista algún proyecto de software que sea tan riguroso como para no poder modificarlo directamente en las ultimas etapas del desarrollo, pero en la teoría así es la cosa.

El Modelo Iterativo, de Aproximación o Incremantal

Este es muy diferente al anterior, ya que iniciamos nuestro desarrollo, pasando por todas las etapas, pero no completamos ninguna, y solo avanzamos un cierto porcentaje. Una ves terminado, volvemos al principio pero debemos regresar al inició para seguir desarrollando. En la primera iteración no hay problemas en que el software no este listo, ni si quiera en la segunda, ya que cada ves que hacemos una iteración, implementamos nuevas funcionalidades del software final, corregimos y vemos como le parece al cliente, refinando más nuestro producto final, hasta la ultima iteración, en donde se realiza la entrega al cliente, para poder pasarlo a producción.

De estos dos modelos, decienden todos los submodelos, metodologias y submetodologias que conocemos.

Metodologías de Desarrollo

A diferencia de los modelos, las metodologías definen patrones, de cierta manera estrictos para cada una de las etapas de desarrollo.

Dentro de las metodologías más usadas está OMT++ : Metodología 100% orientada a objetos y descendiente del modelo lineal, es decir, se maneja muy bien con lenguajes orientados a objetos, como Java, C++ y la familia de lenguajes .NET y obliga a realizar cada una de las etapas de desarrollo de la mejor manera, ya que, en teoría, no es posible volver atrás para una nueva captura de requerimientos, por ejemplo. Esta metodología usa el patrón MVC (Modelo Vista Controlador) para las faces de análisis y diseño.

En otro post voy a hablar en profundidad sobre OMT++, asi como otros, como RUP, FDD, XP, los modelos que descienden del lineal e incemental.

Recomendaciones a la hora de usar Metodologías o Modelos de Desarrollo

Las metodologías es bueno ocuparlas en todo momento, ya que nos permiten seguir una estructura sólida y aseguran entregar tanto una buena documentación como un buen producto final. En cambio los modelos podemos hacer lo que queramos, permitiéndonos cierta flexibilidad al momento de implementarlo, pero no especifica algunas características de los productos finales, no así la metodología si los establece.

Para que se unan a la Googlemania!!

Anímense a ocupar Google, es lo que le recomiendo a todo el mundo, ya que cuenta con un correo electrónico espectacular de 2.7 GBytes, y sigue aumentando, Chat (GTalk o Jabber) integrado, y un montón de otros servicios más.

Ahora, muchos ya saben de lo fantástico que es GMail, pero lo interesante son los otros servicios que no son populares, ya que como no tienen traducción al español, no los publican, y yo me entere por que tengo mi GMail en ingles. Aquí les escribo un resumen de los servicios que ofrece Google y los links correspondientes:

http://picasaweb.google.com/ - Es un fotolog, pero mucho mejor, ya que puedes agrupar tus fotos en albums y subirlas con el Picasa de Linux o Windows directamente, así como optimizarlas, para que no se vean tan mal. Un ejemplo son mis álbums públicos en http://picasaweb.google.com/darth.debian. Notese la posibilidad de compartir fotos privadamente, enviando invitaciones por mail o bien compartir ciertos albums, como en mi caso.

http://groups-beta.google.com/ - Es un nuevo concepto, con respecto a las tradicionales listas de correo, ya que con este servicio se puede publicar una pagina web, publicar archivos y muchas otras coasa más. Cualquiera esta invitado a crear su propio grupo de conversación. Un ejemplo es el grupo que cree para el Ramo de Lenguajes y métodos de programación.

http://docs.google.com/ - Esto si que es innovador. Nada más ni nada menos que un procesador de texto en linea y más encima colaborativo. Esto quiere decir de que todo lo que heces se guarda en internet, por lo que no tienes que preocuparte de estar guardando tu documento en tu Pendrive, Diskette o el Disco Duro a cada rato por miedo a que se te borre o le pase algo. También soluciona el problema de los tediosos trabajos en grupo, ya que con este procesador de texto puedes compartir tu trabajo en tiempo real, al mismo tiempo que hace un historial de las modificaciones y quien las hizo, por lo que podras organizar bien tu trabajo. Finalmente puede exportarlo a formato PDF, OpenDocument, Microsoft Word y HTML, o publicarlo directamente en tu blog, enviando invitaciones por correo electrónico o un link. Aquí un ejemplo de un informe de administración. También posee el manejo de planillas de calculo con las mismas facilidades que con los documentos de texto.

http://www.googlepages.com - Un sistema simple de publicación Web, asociado al nombre de nuestro correo, por ejemplo, nombre@gmail.com se asocia a nombre.googlepages.com. El sistema es un poco limitado, ya que solo se puede trabajar con plantillas, pero resulta útil para publicar cosas rápidamente. Además, no tiene publicidad, y es tan simple, que es fácil de crear, publicar y ver.

Pucha, este articulo lo hice a la rápida, pero espero que os sirva y amplíe sus horizontes, ya que estos servicios gratuitos me han simplificado un montón la vida. Saludos!!

Apoyando el Software Libre, a un mundo libre! - Designed by Posicionamiento Web