Análisis de posicionamiento en la web

Muy buenas, como podéis comprobar hemos superado la primera eliminación de blogs realizada por los profesores de la asignatura. El contenido de la entrada de hoy no expondrá ningún tema relacionado con la ingeniería del software, el objetivo es mostraros el estado del posicionamiento de nuestro blog en la web y poder comprobar si el esfuerzo de publicar información y conocimientos útiles para la ingeniería del software tiene su recompensa. Respecto a la herramienta que se ha utilizado ha sido Google Analytics, una herramienta muy completa, profesional y gratuita.

A continuación se presentarán los informes generados a partir del día 29 de octubre del 2007. El primero de ellos es muestra el gráfico de visitas por país o ubicación, se puede ver observar cómo los países que más visitas realizan son España y Méjico, gracias a las buenas relaciones que mantenemos con nuestros amigos mejicanos.

En el segundo informe se refleja la visión que tienen los usuarios frente a nuestro blog. Hay que destacar varias puntos:

1. El porcentaje de abandonos es alto y el tiempo de permanencia bajo, lo que implica que debemos seguir mejorando el blog para cambiar la tendencia de estos dos valores cruciales.
2. El aumento de visitas en las fechas de valoración de blogs.
3. Una bajada actual debido a que en esta semana no hemos publicado ninguna información.
   

Por último, el tercer informe muestra las estadísticas recogidas sobre las fuentes de acceso al blog, señalando como punto más importante que casi la mitad de los usuarios de nuestro blog acceden a él a través de motores de búsqueda. Este dato nos demuestra que la estrategia de posicionamiento y publicación que tenemos está dando resultados.

Y nada más en breve incluiremos nuevas entradas: entrevista a un jefe de proyecto, opiniones sobre las fases de análisis y diseño y... ¡Una nueva sección de humor!

Web Services

Buenas a todos nuestros seguidores. En la entrada de hoy, vamos a exponer nuestra opinión sobre los Web-Services (WS) por ser una tecnología de comunicación distribuida que está en auge e implantándose cada vez en más sistemas de información, y que además, hemos decidido utilizarla para diseñar una API de acceso remoto al sistema de marcadores sociales que se está desarrollando. Nos centraremos única y exclusivamente en la opinión que tenemos: analizar las ventajas qué nos proporcionan y las limitaciones qué nos imponen, dejando en un segundo plano la colección de protocolos que conforman este mecanismo de comunicación: SOAP, WSDL, HTTP, etc. En cuanto a las fuentes y referencias de información de web-services, son muchas y variadas, destacando principalmente las siguientes:

1. Conocimientos obtenidos de la asignatura de Servidores de Información.
2. Experiencia en el ámbito laboral.
3. Artículos técnicos y blogs sobre los WS: http://sistemas3.wordpress.com/2007/06/14/web-services/, http://www.w3.org/2002/ws/,http://en.wikipedia.org/wiki/Web_service...

En cuanto a las ventajas que hemos observado, hay que destacar por encima de todo la increíble transportabilidad e interoperabilidad que existe en su comunicación: permiten compartir, obtener y generar información independientemente del lenguaje de las aplicaciones, la plataforma o entorno de ejecución y las arquitecturas de los dispositivos implicados. Pero además de esta gran ventaja, tras haber trabajado en otros paradigmas de comunicación distribuida: RMI, CORBA, RPC, etc., los WS permiten unas ayudas que no hay que olvidar como son:

• Proceso de transporte realizado por HTTP, provocando que las políticas de proxys y firewall de una empresa tras la implantación de los WS no se vea modificada.
• Permiten procesos de autenticación y seguridad, de forma que se puedan restringir el uso a máquinas que cumplan ciertas características: tengan un determinado certificado, estar en un dominio concreto, etc.
• Facilidad de uso desde la perspectiva del programador. Al final, los WS se reducen exclusivamente en una definición de funciones desde el lado del servidor, sin importar los procesos de binding, autenticación y otros de más bajo nivel; y en el lado del cliente, al uso de una "libreria de funciones" importada desde el servidor, una vez más sin importar procesos de bajo nivel.

Todo esto aplicado en una situación real, se puede ver con el siguiente ejemplo. Se tenían dos sistemas de información: un gestor de alumnos, y una plataforma de e-learning. Ambos sistemas eran desarrollados por dos empresas diferentes, en diferentes lenguajes: el primero en Java y el segundo en PHP e implantados en el mismo organismos oficial. Lo que se pretendía era que el gestor de cursos ofreciese unos servicios de matriculación al gestor de alumnos. Se procedió al estudio de las alternativas a la solución, y la que mejor se acoplaba a las necesidades solicitadas eran los Web Services. Al final, la implementación de los Web Services para PHP mediante la librería Nu-SOAP resultó todo un éxito, tanto en el tiempo que se realizó como en el funcionamiento final.

Por último, como todo en esta vida siempre hay ventajas pero también desventajas, y los WS no iban a ser una excepción. Lo primero hay que señalar que todavía se trata de una tecnología que está en plena fase de crecimiento y por tanto, la poca documentación existente y las modificaciones en el estándar no serían extrañas con el consiguiente riesgo que conllevaría. Otra desventaja que hemos observado es la sobrecarga que puede sufrir el canal por el uso de XML en el transporte de mensajes, a diferencia de RMI y CORBA que usan estrategias de marshall y unmarshall en los datos para enviar, produciendo un notable mejora en la velocidad de la comunicación. Finalmente, y aunque lo hemos citado como una ventaja, que la comunicación se realice mediante HTTP puede ser un "arma de doble filo", es decir, estará expuesto a todos los riesgos que se dan en este protocolo: captura de la información por terceros al no ir cifrada (a menos que se utilice HTTPs), WS desarrollados para producir un efecto negativo en el cliente y que esquivarían a los firewall fácilmente, etc.

Pues esto ha sido todo, esperamos vernos en la siguiente entrada ya que esta semana hay la primera eliminación de blogs. ¡Un saludo!

Opiniones sobre: Estudio de Viabilidad del Sistema (2)

Buenas de nuevo, hoy continuaremos describiendo nuestras experiencias con el Estudio de Viabilidad de Sistema.

En concreto, vamos a abordar la parte de estudio de alternativas de solución. Este apartado tiene como objetivo dar una primera aproximación al hardware y software que se utilizará para implementar e implantar el proyecto. Además, de este estudio saldrá el coste en hardware y software de implantación que tendrá que reflejarse en el presupuesto reflejado en la oferta, aunque como ya dijimos en el post anterior, en nuestro trabajo no seguimos este orden por motivos de simulación de un proyecto real en los que no siempre se sigue el orden adecuado. Para esto, deberán analizarse todas las posibilidades existentes y evaluar el rendimiento que nos ofrecen en cada uno de los factores que se consideren determinantes.

Estamos muy satisfechos con el resultado de nuestro trabajo en esta parte del nuestro trabajo, ya que varios de los miembros del grupo tienen experiencia con proyectos reales y conocían varias posibilidades de solución tanto hardware como software que nos permitieron lograr un análisis de las alternativas de gran calidad. Es decir, los factores que nos llevaron al éxito en este apartado fueron: la experiencia de nuestros empleados junto a una buena búsqueda por Internet de diferentes ofertas de empresas.

Para explicar mejor qué son las alternativas hardware y software, pondremos un ejemplo de cómo las seleccionamos nosotros:

Para las alternativas hardware del sistema, tuvimos que seleccionar entre hospedaje interno o externo, es decir si nuestro cliente tendría su propio servidor o alojaría su aplicación en el servidor de otra empresa. Recopilamos varias ofertas de diferentes empresas, dando todas las características del servicio ofrecido y su coste. La valoración fue realizada en base a las referencias, el coste, la experiencia de los desarrolladores, la estabilidad, la actuación ante fallos y los tiempos de respuesta. Finalmente, escogimos un hospedaje interno contratado con la empresa DELL.

Para las alternativas software del sistema, estudiamos varias combinaciones de sistema operativo + servidor + gestor bases de datos + lenguaje de programación. Tras valorar todas las alternativas intentando maximizar las referencias, la experiencia de los desarrolladores con la tecnología, la estabilidad, el soporte y minimizar el coste, Linux + Orión + PostgreSQL + Java fue la solución escogida.

Esperamos una vez más que este post pueda resultar de ayuda a nuestros lectores y que hayamos sido capaces de transmitir, tanto la importancia que tiene el estudio de alternativas para el desarrollo del proyecto (de aquí saldrá el presupuesto entregado al cliente) como las bases para realizarlo correctamente. Si os habéis quedado con alguna duda o queréis realizar alguna aclaración, no dudéis en dejar vuestros comentarios y os contestaremos encantados.

Un saludo.

Opiniones sobre: Estudio de Viabilidad del Sistema (1)

Buenas a todos nuestros seguidores. Como viene siendo habitual en esta entrada explicaremos nuestra experiencia que hemos adquirido después de desarrollar el documento de Estudio de Viabilidad del Sistema o EVS, que forma parte de la metodología que estamos siguiendo: Métrica 3. Este documento trata de dar un primer paso en la adquisición de requisitos y plantear qué solución se seguirá entre todas las alternativas posibles.

Puede resultar extraño el dar alternativas de solución antes de realizar la parte de análisis, pero lo cierto es que antes de entrar de lleno en la parte de análisis, normalmente habrá que dar un presupuesto al cliente y este documento busca una primera aproximación al coste del proyecto. Lo normal sería realizarlo al inicio del proyecto, antes de la oferta. Sin embargo, nuestro profesor nos indicó que lo primero que entregamos es la oferta porque así ocurre en muchos casos reales, en los que primero se presenta la oferta rápidamente y sin tiempo a nada más y luego se ve cómo justificar lo que se puso en la oferta.

Por lo tanto, diferenciaremos dos partes claras: la primera es la identificación requisitos para el software y la segunda el estudio de las alternativas a la solución. En este post, solamente expondremos nuestra experiencia en la parte de identificación de requisitos, para no realizar un post demasiado extenso. Otro día comentaremos el estudio de alternativas de solución.

En el inicio del proceso de captación de requisitos software hemos aprendido lo difícil que puede llegar a ser la identificación de los primeros requisitos. Esto se debe primero a que no estamos en una situación real y no se dispone de un cliente al cual se le puedan realizar preguntas; y después, es difícil responder a la siguiente pregunta: ¿qué problema quiere el cliente resolver? ¿que restricciones impone?

Luego la pregunta del millón es: ¿qué hemos hecho para solucionar este problema? Para enfrentarnos a él, nos hemos apoyado en dos puntos: la experiencia que disponemos en este tipo de documentos pues ya lo hemos realizado en varias asignaturas a lo largo de la carrera y la verdad es que se nota respecto a otros documentos de los cuales no disponíamos ninguna experiencia previa, como por ejemplo gestión de calidad y de configuración. Y el segundo punto, el estudio de la competencia, en nuestro caso como estamos desarrollando un sistema de marcadores sociales, qué mejor que fijarse de las capacidades y restricciones que ofrece del.icio.us para realizar un trabajo de ingeniería inversa y obtener los requisitos para nuestro proyecto.

En este punto, cometimos un error en nuestro trabajo, ya que no incluimos de forma explicita este estudio de la competencia en el documento debido a que la metodología no lo indicaba. Por ello, para que no caigáis en el mismo error, conviene que recordemos que la metodología que se sigue a lo largo del proyecto da una indicación de los pasos a seguir, pero no debe seguirse al pie de la letra. Si hay algo interesante que poner en un documento, aunque no lo indique la metodología, debe incluirse en el trabajo y, al revés, si algo de lo indicado por la metodología no tiene sentido en un proyecto en concreto, no debe realizarse.

En resumen, la conclusión principal que hemos obtenido ha sido la importancia que tiene la detección de todas las fuentes de requisitos, tanto de los usuarios participantes que puedan aportar requisitos como de otras fuentes (trabajos similares, competencia, etc.). Además, será importante poder extraer toda la información de dichas fuentes. Para esto, lograr una relación perfectamente coordinada y totalmente colaborativa por ambas partes con los usuarios participantes y formalizar en la medida de lo posible el resto de fuentes, resultará vital para obtener nuestro objetivo, es decir, un conjunto de requisitos iniciales robustos, con calidad y que reduzcan (¡no eliminen!, ya que esto es imposible) futuras modificaciones debido a las ambigüedades y vacíos que caracterizan este proceso en la ingeniería del software. Para terminar este punto, nos ha parecido curiosa la cita de Pressman sobre este tipo de problemas: "Quién hace una pregunta es un tonto por cinco minutos; quién no la hace es tonto para siempre." Proverbio chino.

Pues esto ha sido todo compañeros, en los próximos días publicaremos más entrevistas, más comentarios, más opiniones, entradas cómicas y... ¡muchas más cosas!. Como vereis, intentamos dedicar cierto tiempo al blog a pesar del trabajo que tenemos en la universidad porque nos sentimos a gusto con esta idea y pensamos que es enriquecedora tanto para vosotros como para nosotros. Un saludo y hasta las próximas entradas.

Concepto de Líneas Base

Saludos de nuevo. El otro día, en la corrección que hizo el profesor a nuestro documento del plan de gestión de configuración, resaltó que le había gustado que mencionásemos el concepto de "líneas base". Sin embargo, cuando nos pidió que explicásemos lo que eran nos quedamos un poco atascados, ya que es un concepto algo difícil de explicar.

Por eso, siguiendo en la línea de crear post didácticos, decidimos crear un post con la explicación de qué son las líneas base en ingeniería del software para que podáis incluirlo en vuestros futuros proyectos, ya que una vez comprendido correctamente, no es nada complejo.

Las líneas base o más conocidas por su termino en inglés, "baselines", son "una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios” según la traducción del estándar IEEE 610.12-1990 realizada en el libro de Pressman que ya recomendamos.

Nuestra explicación más informal pero esperamos que más comprensible también, es la siguiente:

Cuando, en un proceso de desarrollo de software se realiza un producto (un documento, código fuente u otros), este producto pasa una etapa de producción en la que se puede modificar sin impedimentos. Sin embargo, una vez terminado este producto, tendrá una revisión formal y se aprobará por el equipo de calidad y, en caso de que así se decida, por el cliente. Una vez que el producto ha sido aprobado, ya no podrá ser modificado de modo informal, sino que deberá seguirse un estricto control de cambios realizados sobre dicho producto para controlar correctamente su evolución.

Por lo tanto, una línea base se define como un producto que acaba de ser aprobado y que define la “base” de ese producto que para ser modificado deberá pasar por un protocolo de control de cambios. También puede verse como un punto de referencia en la configuración de un proyecto que marca un estado estable en algún producto del proyecto.

El uso de las líneas base en un proyecto vendrá dado por la definición de las diferentes líneas base que se realizarán a lo largo del proyecto (generalmente requisitos de usuario, requisitos software, diseño, código fuente, planes o procedimientos, pruebas, funcionamiento) para controlar cuando se aprueban los distintos productos y asegurar que se realiza el correspondiente control de cambios que ayudará a mantener la coherencia y calidad de todo el proyecto software.

Otras fuentes para consultar:
"Ingeniería del Software. Un enfoque práctico"
Baselines en Wikipedia

PD: Se agradecería cualquier tipo de comentario que ayude a completar la definición de líneas base o a corregir cualquier fallo que se pueda encontrar en este post.

Recomendación de Bibliografía

Buenas. Desde nuestro equipo creemos que ha llegado la hora de un pequeño cambio de mentalidad respecto al blog. Vamos a seguir dando nuestras impresiones sobre nuestro proyecto, pero también queremos hacer entradas que sean una verdadera ayuda a todos aquellos que estén iniciándose en la ingeniería del software.

Para ello, vamos a comenzar por una recomendación para los que no tengan experiencia a la hora de llevar un proyecto de desarrollo de software. El libro "Ingeniería del Software. Un enfoque práctico" de Roger S. Pressman.

Este libro nos está ayudando a solventar todos los problemas que vamos teniendo a la hora de realizar los documentos. En la entrada anterior, comentamos la dificultad de encontrar métricas o riesgos para un proyecto sin haber realizado ninguno aún. Para solucionarlo acudimos al libro recomendado y encontramos varias métricas de calidad para incluir en nuestro proyecto y varios ejemplos en los que basarnos para ir sacando más riesgos que los que se nos habían ocurrido.

Por lo tanto, hasta ahora, nos ha dado grandes ideas para mejorar la calidad de nuestro trabajo y pensamos seguir consultándolo durante todo el proyecto.

Esperamos que a todos aquellos que no hayáis oído hablar de este libro y decidáis echarle un vistazo, os sirva de ayuda en vuestros proyectos.

Si es así, seguid consultando el blog, ya que seguiremos haciendo recomendaciones, consejos, entrevistas a profesionales y ofreciendo toda la información y ayuda que esté en nuestra mano.

Un saludo.

PD. Si a alguien no le convence el libro o necesita más ayuda, como bien dice nuestro profesor Ricardo Colomo Palacios, "Google o F1".