Estándares

En la siguiente entrada daremos una lista de los estándares que hemos utilizado en nuestro proyecto y el porqué de su elección, de tal forma que aquellos que lean esta entrada tengan un buen punto de partida a la hora de elección de estándares con los que impresionar al cliente jejejeje. Ya en serio, tener un producto basado en estándares te aseguras un nivel de calidad y seguridad que de otra forma sería muy difícil de conseguir si se aplicase o definiesen procedimientos de aseguramiento de calidad de forma manual.

Ahí va esta serie de referencias de estándares:

FORMATO DE LAS REFERENCIAS DE FUENTES DE INFORMACIÓN:

• IEEE (2.007). IEEE Standards Style Manual. Obtenido de: http://standards.ieee.org/guides/style/
• APA. (2.007). American Psychological Asociation. Obtenido de http://apa.org
  

PLANES DE ASEGURAMIENTO DE LA CALIDAD EN LA INGENIERÍA DEL SOFTWARE:

• IEEE (2.004). IEEE Std 730-1998. IEEE Standard for Software Quality Assurance Plans. Obtenido de: http://standards.ieee.org/reading/iee/std_public/description/se/730-1998_desc.html

• NASA SATC. (s.f.). A Software Quality Model and Metrics for Identifying Project Risk and Assessing Software Quality. Obtenido de http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.html

• ISO (1.995). ISO/IEC 12207 Information Technology - Software Life Cycle Processes. Obtenido de: http://www.wikipedia.com
  
• ISO (1.993). ISO/IEC 15504 Software Process Improvement and Capability dEtermination. Obtenido de: http://www.wikipedia.com

INTERFACES DE USUARIO:

• ISO. (Enero de 1.997). User Interface Standards in the ISO. Obtenido de http://sigchi.org/bulletin/1997.1/standards.html

WEB SERVICES:

• W3C. (2.007). Web Services. Obtenido de http://www.w3.org/TR/2002/ws
• W3C. (2.004). SOAP Specifications. Obtenido de http://www.w3.org/TR/soap

P.D. Muchas gracias a los comentarios de la anterior entrada!!!!!!

Capítulo Final

"Todo comienzo tiene un final". Es una regla de la vida y esto no va a ser una excepción. En estos momentos acabamos de terminar nuestro desarrollo del sistema de marcadores sociales y estamos a la espera de la aprobación final por parte del cliente.

Para el equipo de desarrollo, a pesar del esfuerzo y trabajo, e incluso a veces sufrimiento (sobre todo en los días de la entrega), ha sido una grata experiencia. Lo más importante nos es que hayamos acabado la práctica en su momento, que el profesor le haya gustado algún apartado, alguna idea novedosa que se nos ha ocurrido para la práctica o el blog... No nos referimos a nada de eso. Lo principal ha sido que al finalizar este año, cada uno se llevará seis amigos más con los que poder compartir tanto los buenos como los malos a lo largo de estos años y esto no tiene precio. 

Después y ya en relacionado con el tema de la asignatura, tenemos la idea que por primera vez nos hemos enfrentado a un problema lo más parecido a lo que nos vamos a encontrar en la nueva etapa que nos espera y muy distinto a las prácticas que habíamos hecho hasta ahora. Además de este hecho tan importante, en un principio dudábamos del sentido de esta asignatura ("¿Para qué volver a hacer otra asignatura donde la mayor parte del contenido es temario que ya hemos dado 50 veces a lo largo de la carrera: análisis y diseño?"), sin embargo, a parte de enfrentarnos a un problema similar del mundo laboral como ya hemos dicho, hemos aprendido pequeños detalles pero no de menor importancia que el análisis y diseño que no habíamos visto hasta ahora:

• Cómo redactar un documento de oferta de servicios.
• Gestionar la relación con el cliente.
• Interfaces de configuración y calidad a las que está sujeto todo proyecto software.
• Proceso de implantación.
• Proceso de histórico y síntesis del proyecto.

Así que después de cursar la asignatura, se nos ha ido de la cabeza todas las dudas iniciales que teníamos sobre el sentido de esta asignatura.

Otro aspecto a citar es el blog. Sinceramente, ha sido de las mejores experiencias en términos académicos que hemos tenido a lo largo de la carrera y nos comprometemos desde ahora, que independientemente del resultado de la final, tenemos la intención y el deseo de continuar escribiendo a lo largo del segundo cuatrimestre para lo que sería la continuación de esta asignatura: Sistemas Informáticos y poder seguir compartiendo con la comunidad informática los conocimientos que vamos aprendiendo en la universidad. Lo que más nos ha sorprendido ha sido comprobar que el esfuerzo que dedicábamos al blog valía la pena y que personas interesadas lo utilizaban, no sólo nuestro amigo de El Salvador como el caso más importante, sino bastante gente, principalmente de España y América Latina, han estado visitando nuestro blog, sindicándose a nuestros contenidos, viendo las entrevistas que hacíamos a los expertos en ingeniería del software, etc. En general, nuestro principal objetivo que planteamos al principio del blog se ha visto cumplido en tan sólo 4 meses: Observar que tu trabajo es útil y valioso para la gente.

Por último y ya hablando como Javier, no quería acabar esta semana dando las gracias a Ricardo por perdonarme el castigo pero sobre todo a Álvaro por defenderme, dar la cara por mí y echarme todos los piropos que me echó jejejeje.

Pues nada más que contaros por hoy, sólo la última cosa: Esto no ha hecho nada más que comenzar. En los próximos días publicaremos más entradas y todas las ideas que tenemos ya preparadas.

Por cierto, algún día os teníamos que mostrar quiénes éramos...

De izquierda a derecha y de arriba a abajo: Pablo (y su barba de 1 semanilla), Álvaro, Israel, Eva, Javi e Iñaki.

P.D.: Falta Jose lo que pasa que ayer cuando nos hicimos la foto ya no estaba y no íbamos a tener otro momento para hacernos la foto antes de la final.

P.D. 2: Sólo deciros unas últimas palabras: ¡Suerte a todos en los exámenes y en las prácticas que os quedan que otro cuatrimestre más está llegando a su fin!

Enterprise Java Bean

Buenos días. Hoy queríamos comentar los Enterprise Java Beans(EJBs). Esta tecnología de Sun Microsystems puede ayudarnos mucho a realizar un proyecto software tanto si deseamos realizar una aplicación web o una normal.

Utilizar esta tecnología implica realizar todo el diseño en función del esquema definido por ella. Gracias a esto, el diseño se realiza de forma inmediata y la programación se facilita mucho mediante la herencia de las clases de EJB.

Ventajas. Las principales ventajas de la utilización de EJBs son:

Funciona sobre Java, por lo que adquiere algunas de sus ventajas como son su portabilidad, orientación a objetos, etc.

Ahorra mucho trabajo tanto en la fase de diseño (solamente hay que seguir el esquema que nos definen los EJBs, haciendose innecesaria la aplicación de patrones) como en la fase de implementación (heredando de las clases de EJBs, especialmente si utilizamos los CMP EJBs).

Realiza automáticamente casi todas las consultas a la base de datos (todas excepto algunas de búsqueda), ahorrando mucho trabajo de diseño y programación en este sentido.

Facilidad de integración en aplicaciones web basadas en servlets o Java Server Pages (JSPs).

En las últimas versiones tiene soporte para integración con servicios web, de modo que se pueda acceder a las funcionalidades de los EJBs desde ellos.

Inconvenientes. Evidentemente no todo son ventajas y, el uso de los EJBs presenta los siguientes inconvenientes:

Dependencia de la tecnología para el mantenimiento y reutilización de la aplicación. Una vez que la aplicación ha sido realizada en función del esquema de EJBs, es muy costoso pasar el trabajo a otro sistema que no incluya esta tecnología, lo cual podrís ser necesario por motivos de mantenimiento (migración del sistema a otra tecnología) o reutilización, tanto de código (¿Cómo reutilizar una clase que hereda de EJB en un sistema que no los utiliza).

Hay que aprender a realizar aplicaciones basadas en EJBs, lo cual conlleva su esfuerzo. La API de EJBs no es sencilla, ya que hay que seguir un esquema predefinido de herencias en el diagrama de clases que no es del todo intuitivo. Además hay que definir el deployment descriptor, lo que tambien conlleva el estudio de cómo hacerse.

Conclusión

En definitiva, recomendamos su utilización para la práctica de la asignatura (especialmente si algún miembro del equipo tiene algo de experiencia con el tema), ya que, aunque en principio parece que estudiarlo no merece la pena, al final ahorra trabajo en la fase de diseño y compensa.

Para un proyecto real ya depende de las especificaciones del proyecto, ya que habrá que balancear sus ventajas (ahorro de tiempo principalmente) y sus desventajas (restringido al uso de java, poca portabilidad a otros sistemas, poca reutilización).

Las referencias bibligráficas que hemos utilizado:
Monsol, R. Haefel. Enterprise Javabeans. USA: O`Reilly: libro bastante recomendado para EJBs.
Sierra, K. Bates, S. Head First EJB. USA: O`Reilly: libro que explica los EJB de una forma más sencilla y entretenida.

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!

Consejos Oferta (2)

Hace un tiempo, en un post anterior ya recomendábamos dedicar una atención especial al documento de oferta. Hoy queremos volver sobre este documento para hablar sobre como abordar una de sus partes más complejas, tanto por su dificultad, como la inexperiencia que tenemos al llegar a esta fase del proyecto en la asignatura: la planificación de tareas.

Como ya decíamos, esta es una tarea no trivial y a la que hay que dedicarle bastante tiempo. Consiste en desglosar todo el trabajo que se realizará en diferentes actividades y tareas. El primer problema que se nos planteó al abordar esto fue ¿Cómo de grandes deben ser las tareas? ¿Una tarea por cada documento? ¿Una tarea por cada apartado?

Nosotros llegamos a la siguiente conclusión: una tarea por documento son demasiadas pocas tareas y con una tarea por documento nos quedaría una planificación demasiado extensa. Por ello decidimos un punto intermedio, haciendo que una tarea englobase varios apartados, agrupando los apartados de los documentos según nos pareció.

Aclarar que cuando decimos que nos podrían quedar pocas tareas no nos referimos por extensión del documento (los documentos ya son suficiente extensos como para tener que preocuparse por ampliarlos más) sino a que, a la hora de planificar, asignar recursos a las tareas, estimar el tiempo dedicado a una tarea, etc, al ser tareas demasiado grandes todo esto se nos complicaba. Además, a la hora de rellenar las hojas de imputación nos dimos cuenta de que a veces teníamos problemas porque el trabajo de todos iba a la misma tarea a pesar de haber estado trabajando en apartados diferentes del documento.

Por todo esto, nuestra recomendación es hacer muchas tareas bastante pequeñas, aunque no sean una por apartado de documento pero tampoco tener miedo a que quede una planificación grande, ya que, aunque luego la planificación se arrastra durante todo el proyecto en los informes de seguimiento, el trabajo a realizar sobre la planificación es en su mayoría decir el % de realización de cada tarea, lo que resulta más sencillo de calcular si las tareas son pequeñas (en la mayoría será 0 o 100%).

Por otro lado, también recomendamos hacer una cosa que nosotros no hicimos del todo correctamente. En esta planificación inicial, además de dar las tareas y los recursos humanos que se encargarán de realizarlas, dar una estimación del tiempo necesario para realizarlas. Evidentemente, es muy difícil dar esta estimación al comenzar el proyecto y más si es vuestro primer proyecto pero creemos que si las tareas son pequeñas, la estimación de cada tarea será más sencilla.

En resumen, cómo hacer la planificación inicial es una cuestión muy subjetiva pero no debe infravalorarse la importancia de hacerlo correctamente, porque se tendrá que arrastrar durante todo el proyecto.