Estrategia para el histórico de un proyecto

Durante este fin de semana hemos creado el documento de histórico del proyecto. En pocas palabras, este documento pretende realizar un resumen de todo lo acontecido desde que se presentó la oferta de servicios hasta la implantación del sistema de información resultante, de tal forma que si alguna persona esté interesado en el proyecto o esté desarrollando uno parecido, pueda acceder a una fuente que le dé la información necesaria, de forma rápida y sencilla.

En esta entrada daremos una estrategia para enfocar este documento tan importante: no sólo analiza la situación final del proyecto, sino que previene e informa a futuros desarrollos de proyectos similares. 

Como nos dijo nuestro profesor Ricardo Colomo, desde su experiencia había comprobado que en los proyectos españoles suele predominar la crítica y el castigo en el análisis que realizan los jefes de proyectos al finalizarlos. Sin embargo y estando totalmente de acuerdo con su opinión, pensamos que esto es un error: si una cosa se ha hecho mal, se dice y no se oculta, pero NO se "machaca" a los responsables del fallo; en cambio si han existido una serie de aciertos o aspectos muy positivos y valorados (en especial por el cliente), queda claramente reflejado en el histórico del proyecto. En resumen, hay que seguir una estrategia parecida a la que mencionó Ricardo junto con Juan de Castro en la entrevista que hicimos para conseguir un buen trabajo en grupo: Transparencia y sinceridad en la comunicación + imperativo categórico + reconocimiento de aciertos.

Y nada más que contar, os volvemos a animar a que escribáis algún comentario y hasta la próxima entrada, que tenemos muchas y muy variadas para enfocar esta recta final. 

¡Saludos!

Opiniones sobre: Web 2.0

Mientras esperamos el resultado de la valoración de los blogs realizado por el departamento de la asignatura, en la entrada de hoy expondremos nuestra opinión sobre la Web 2.0. El objetivo es que la gente entienda a qué se refiere este termino tan general, aplicable tanto en el mundo de la informática como en cualquier otra materia dada la extensión actual de la Web. De forma concreta lo que pretendemos es aclarar este concepto tan de moda actualmente (¡si se introduce en Google se obtienen 85.000.000 de resultados!) para que cualquier usuario de Internet diferencia si una aplicación está diseñada hacia la Web 2.0 o no.

Lo primero de todo es responder a la siguiente pregunta: ¿Qué es la Web 2.0? Aunque mucha gente piense que pueda ser un estándar, una tecnología, herramienta o plataforma; es más sencillo que todo esto: es una cambio en la actitud o diseño de las aplicaciones Web de forma que estén orientadas al usuario final. Se trata de que éstos (los usuarios finales) no sean únicamente receptores de la información, sino que también sean capaces de generarla y compartirla con el creador de la página y con otros usuarios finales. El ejemplo más inmediato es este blog: vosotros ya no sois meros lectores, si queréis podéis participar en la creación del mismo mediante la introducción de comentarios a las diferentes entradas que vamos escribiendo, los cuales serán publicados y leídos por nuevos usuarios.

La siguiente cuestión es: ¿Qué páginas en la actualidad son Web 2.0? Para comprender mejor esto de la Web 2.0 os detallamos a continuación plataformas que si están orientadas hacia la Web 2.0:

• YouTube
• del.icio.us
• Google AdSense
• Wikipedia
• ebay
• Y muchas más.

Un caso concreto de ellos es Wikipedia. Si la comparamos con su antagonista de la Web 1.0: la enciclopedia británica, la diferencia de porqué una está enfocada a la Web 2.0 y la otra no, es que en Wikipedia además de leer el artículo podemos modificarlo y añadir nueva información que será útil para futuros lectores, mientras que en la enciclopedia británica no se puede: el artículo es realizado exclusivamente por una persona.

La tercera y última pregunta: ¿Cómo se relaciona la Web 2.0 con la ingeniería del software? Cada vez es más común que los proyectos cuya plataforma es la Web se enfoquen hacia la Web 2.0, por esta razón es fundamental que las personas relacionadas con el desarrollo de este tipo de sistemas software entiendan qué es la Web 2.0, y , en especial los clientes, comerciantes y jefes de proyectos para que sepan lo que piden, venden y dirigen respectivamente.

Pues hasta aquí esta entrada, espero que os haya aclarado las principales dudas sobre la Web 2.0 y hasta la próxima. 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.

Opiniones sobre: Gestión de Configuración y Calidad

Buenos días. Como ya prometimos hace unos días, ha llegado el momento de dar nuestra visión acerca de los documentos de gestión de la configuración y gestión de la calidad.

Hemos juntado esta entrada porque consideramos que el objetivo de ambos documentos es similar, ya que pretenden maximizar la calidad de todo el proyecto.

Se diferencian en que el documento de gestión de la configuración pretende dar unas normas generales para la gestión de los productos que se generarán y los cambios que se produzcan en estos, mientras que la gestión de calidad trata de todos aquellos aspectos necesarios para que el cliente quede 100% satisfecho con nuestro trabajo.

Esta ha sido nuestra primera experiencia con estos documentos. Hasta ahora, toda esta parte de un proyecto la realizábamos de un modo completamente informal, sin dejar las cosas por escrito y basándonos únicamente en nuestros presentimientos, a la hora de planificar y evaluar nuestros trabajos.

Este tipo de planificación, aunque en algunos caso salió bien, en otros tuvimos grandes pérdidas de tiempo en solucionar las inconsistencias que inevitablemente ocurrían, teniendo graves consecuencias.

Por lo tanto, consideramos que, aunque pueden resultar algo tediosos el tener que formalizar todo metódicamente, son realmente útiles a la hora de realizar un proyecto complejo.

La mejor característica que vemos en estos documentos es que son muy poco dependientes del proyecto actual. Ha medida que íbamos redactando los diferentes apartados nos dimos cuenta de que realmente, se podría realizar un documento de gestión de la configuración y de la calidad para todos los proyectos de la empresa, solamente teniendo que realizar algunas partes que dependen de los proyectos, como por ejemplo el análisis de riesgos.

En cuanto a las diferencias a la hora de realizarlos, definir la configuración es muy metódico, dando todas las normas que deben seguirse al realizar cada parte del proyecto. Definir el plan de aseguramiento de calidad es igual de metódico pero más difícil, ya que en este caso hay que listar todos los posibles riesgos que nos pueden acontecer en un proyecto, y no es sencillo conocerlos. También nos resulto difícil dar métricas.

Como conclusión, ambos documentos nos han parecido muy importantes, pero consideramos más didáctico el de calidad, ya que hasta ahora sabíamos que era uno de los objetivos que tiene que tener presente todo ingeniero del software, pero no la forma de conseguirla. Ahora hemos ampliado nuestros conocimientos para la realización de un plan de aseguramiento de calidad que nos permita realizar mejores proyectos y esperamos aprovecharlo en todos los proyectos que afrontemos en un futuro.

Opiniones sobre: Oferta

Buenas. Tras un pequeño "descanso" por el puente volvemos al blog a contar nuestra experiencia con el documento de ofertación de servicios.

El objetivo de este documento es convencer al cliente de que realizar el proyecto ofertado es fundamental para sus intereses empresariales y que nuestra empresa es la opción más adecuada para llevarlo a cabo.
Esto ha marcado todo nuestro trabajo en el documento, ya que hemos intentado poner nuestro mayor esfuerzo en encontrar las palabras y expresiones más adecuadas para lograr nuestro fin. Destacamos esto porque consideramos que uno de los puntos más complejos de la realización de la oferta ha sido el intentar "vender el producto" al cliente sin dejar de parecer una empresa seria y organizada.

Otro punto que también creemos importante resaltar, es el apartado de planificación del trabajo. Consideramos este apartado muy importante, ya que le damos al cliente una serie de plazos para ir completando partes del trabajo y, en fases posteriores del proyecto, el cliente irá evaluando nuestro rendimiento comparando el progreso actual con dicha planificación.

Además, nos ha parecido una tarea compleja, puesto que decidir cómo dividir el trabajo e intentar dar una aproximación al tiempo estimado a cada fase, nos ha resultado difícil de afrontar, al ser la primera vez que nos enfrentábamos a la organización de un proyecto. El factor más importante a la hora de realizar este apartado, del cuál carecíamos, es la experiencia en proyectos anteriores.

Un problema similar a lo que acabamos de contar, es a lo que nos hemos enfrentado a la hora de realizar el documento de cálculo de costes. Al inicio del proyecto sin saber todas las necesidades exactas no sabíamos exactamente que costes poner. Al final decidimos llevar el presupuesto a la alza para asegurarnos de que no hay apuros económicos.

Para finalizar, también queremos añadir un poco de autocrítica. En este sentido, quizás deberíamos haber dedicado un poco más de tiempo a dar un formato uniforme al documento, ya que eso es tan importante como su contenido. Esto es así, especialmente en los documentos destinados al cliente. Infravaloramos el tiempo que teníamos que dedicar a dar formato a todo el documento y al final casi no nos dió tiempo de terminarlo correctamente.