Estamos realizando la asignatura de Recuperación y Acceso a la Información en la que estamos haciendo una página web acerca de técnicas de clasificación para la organización y recuperación de la información.
Hemos dividido las técnicas en extracción de información con clasificación supervisada y organización de información con clasificación no supervisada así que si queréis más información sobre estos temas solamente teneis que entrar en los enlaces que os hemos dejado.
Un saludo y esperamos que os sea de utilidad.
sábado, 29 de marzo de 2008
El blog continua
Buenas, hacía ya un tiempo que no pasábamos por aquí ya que entre los examenes y el inicio del cuatrimestre no teníamos demasiado que añadir.
Al final logramos ganar el concurso de blogs de la clase de Ingeniería del Software III, pero, como ya dijimos anteriormente intentaremos seguir poniendo algunos post si encontramos temas interesantes sobre los que hacerlos y que puedan aportar algo.
Un saludo.
Al final logramos ganar el concurso de blogs de la clase de Ingeniería del Software III, pero, como ya dijimos anteriormente intentaremos seguir poniendo algunos post si encontramos temas interesantes sobre los que hacerlos y que puedan aportar algo.
Un saludo.
miércoles, 30 de enero de 2008
Sobre auditoría y gestión de la configuración
Después de otra entrada más sobre tipos de tecnologías a utilizar en la fase de diseño, en ésta daremos unos consejos sobre el mantenimiento de la configuración de archivos que componen un proyecto.
El motivo viene precedido por los resultados que nos dio nuestro profesor tras la realización de la auditoría que hizo durante navidades. Los resultados fueron satisfactorios a excepción de una serie de inconsistencias en el nombrado y etiquetado de los archivos. La causa de estos fallos fueron porque nos recomendaba que si utilizabamos una herramienta de gestión de configuración que nos nombrase automáticamente los documentos, en el plan de gestión de configuración incluyesemos esta nomenclatura para no tener problemas a la hora de tener que renombrar los documentos. A raiz de esto, se nos ocurrió hacer una entrada sobre cómo gestionar los documentos.
La primera solución que puede pensarse para esto es organizar los documentos en un correo electrónico, pero esto es una locura y, dado que el tamaño de la práctica es bastante grande (puede llegar a ocupar cientos de megas), conviene elegir un otro medio para almacenar los documentos del proyecto.
Nosotros hemos utilizado una alternativa bastante simple, un servidor de subversión (SVN) en el que hemos creado la estructura de carpetas del proyecto, de modo que todos los miembros del equipo podamos trabajar en paralelo sin demasiados inconvenientes, y en caso de que existan conflictos: dos miembros están modificando a la vez un documento, te avisa de forma sencilla y efectiva los cambios que se han estado haciendo.
También existen otras alternativas, como por ejemplo utilizar un servidor FTP como el que proporciona la universidad con el discoweb. Sin embargo, esta tecnología no proporciona los mecanismos de control de versiones y modificación concurrente que sí lo hace el SVN.
Esperamos que este post os haya sido de utilidad (sobre todo para los futuros alumnos de IS 3 del año que viene) y no tengáis problemas a la hora de encontrar una herramienta de gestión de la configuración. Un saludo.
Patrón EJB Session Facade
Hace unos días, en este post, comentábamos que la utilización de los EJBs nos hacía más sencillo el diseño de la aplicación gracias a que, dado que seguíamos el esquema de clases que nos viene dado por esta tecnología no era necesario aplicar otros patrones.
En realidad, existen algunos patrones para utilizar dentro de esta tecnología. Nosotros, en nuestro proyecto, utilizamos uno llamado Session Facade que nos permite dar una fachada de acceso a la parte central de la aplicación hecha en EJBs.
De este modo, utilizamos una arquitectura de 4 capas (similar a la arquitectura Modelo Vista Controlador (tecnología pero añadiendo la capa de acceso a la base de datos y sin permitir comunicación entre la vista y el modelo). A la hora de detallar esta arquitectura utilizamos Session y Entity Beans para la capa de datos (modelo) y de infraestructura (acceso a la base de datos). Para la capa de control utilizamos Session Beans que nos sirven a modo de fachada para utilizar la aplicación. Por último para la capa de Vista utilizamos JSPs (para las interfaces de usuario) y Web Services (para permitir acceso a nuestro sistema desde otras aplicaciones).
Dejamos un diagrama que resume lo que hemos explicado:
Esto se corresponde con un session facade, ya que los session bean de la capa de control solamente hacen de fachada para que los JSPs de la interfaz accedan a los session y entity beans del modelo de datos.
Una de las ventajas de utilizar este patrón nos vino a la hora de controlar los permisos de los usuarios. Cada usuario tiene un rol (administrador, invitado, usuario registrado, etc.) y, para controlar los permisos de cada rol, lo único que tuvimos que hacer es definir las operaciones de cada rol en distintos session beans de la capa de control y despues, desde el deployment descriptor de los EJBs, mapear nuestros roles con dichos session beans. La autenticación se realiza en la capa de interfaz.
Pues eso es todo. Recomendamos que mireis la referencia que os dejamos sobre
el patrón para que completeis la información que os aporta este post y, si aun no lo habeís hecho, podeís consultar la bibliografía que recomendamos sobre EJBs en el primer post en que tratamos este tema y que ya hemos referenciado. Mucha suerte con vuestro diseño.
domingo, 27 de enero de 2008
Autovaloración
El motivo de esta entrada es intentar convencer a los evaluadores (los profesores y el resto de compañeros) para obtener una buena puntuación en sus valoraciones, pues consideramos que el blog se ha realizado cumpliendo los objetivos y criterios a los que estaba sujeto el concurso.
A continuación, presentamos la opinión personal sobre cómo responde a los criterios citados anteriormente:
ADECUACIÓN A LOS CONTENIDOS DE LA ASIGNATURA:
Es nuestro punto fuerte y el aspecto que más hemos cuidado durante el desarrollo del blog. Nuestra estrategia inicial fue clara: queríamos que el contenido del blog fuese útil para personas interesadas en la IS y en especial, futuros alumnos de IS III. Por eso sólo se escribirían entradas cuyo contenido estuviese relacionado estrictamente con la ingeniería del software, o temas relacionados con otras ramas de la informático pero siempre enfocados desde la IS. El resultado está a la vista: exposición de los conocimientos que hemos aprendido en clase, entrevistas a expertos en la ingeniería del software, temas directamente relacionados pero que se dan en otras asignaturas (como por ejemplo "Desarrollo de Software ágil") y ejemplos de las tecnologías más importantes y que destacan en proyectos de computación distribuida (descripción que hemos realizado sobre los Web Services y EJBs). Sin embargo, esto no es todo; siempre está la excepción que confirma la regla: IT Crowd (pero por lo menos algo tiene que ver la informática... jejeje)
DISEÑO:
Nuestra idea respecto al diseño era crear un blog cuya estética se viese a simple vista que estuviese cuidada, realizada de forma profesional y ante todo, seria. Esto ha tenido como resultado una elección de colores y contrastes que faciliten la lectura, pero además se han incluido una serie de widgets que han potenciado tanto el diseño como el contenido del blog: calendario de la planificación del proyecto, sistema de etiquetas de las entradas, gestor de noticias RSS relacionadas con la informática, listado de bibliografía y herramienta de previsualización de enlaces externos.
ACTUALIZACIÓN:
Como ya se ha dicho en el factor de "adecuación al contenido", nuestra idea era clara al principio: las entradas tenían que estar lo más relacionadas posibles con la ingeniería del software. Esto hizo que en algunas situaciones tuviéramos que buscar información, consultar dudas que nos surgían con el profesor, preguntar a terceros sobre determinados temas, etc., provocando que a veces para escribir una entrada tardáramos una semana o incluso más. De todas formas, nuestra media aproximadamente ha sido algo más de una entrada por semana, creyendo que es un buen datos y más que suficiente (teniendo en cuenta no sólo la carga de la asignatura y de las demás, sino la calidad con la que realizábamos las entradas).
REFERENCIAS EXTERNAS:
Ha sido un aspecto que hemos dedicado especial interés, no sólo por la utilidad de consultar las fuentes de información de las cuales desarrollamos la entrada por parte de los interesados, sino también por la valoración positiva que realiza Google aquellas páginas con una buena política de referencias: que estén relacionadas con el tema y que además tengan un PageRank (valoración de Google sobre una página).
INCOMING LINKS:
Es una medida indirecta para saber cómo de bien está publicado tu sitio en la Web. Como dijimos al principio, realizamos una estrategia para aumentar el posicionamiento en la Web y uno de los apartados era dejar referencias de nuestro blog en sitios de especial interés. En nuestro caso, nos anunciamos en la Wikipedia y en los foros de tecnología e informática de El País. Al final y junto con técnicas de mejora de los metadatos del blog, hemos conseguido aparecer en Google los décimos si se busca por la siguiente cadena: "blogspot ingeniería software", que teniendo en cuenta que blogspot es el principal proveedor de blogs de la Web y el poco tiempo que llevamos con el blog, el resultado es bastante bueno. Para ver el resultado de la estrategia de posicionamiento en base a los incoming link y los metadatos, os adjuntamos los gráficos que hemos ido obteniendo con Google Analytics referentes a los medios que utilizan los lectores para acceder a este blog:
Esto ha sido todo por hoy y hasta la próxima!!
viernes, 25 de enero de 2008
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:
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!
miércoles, 23 de enero de 2008
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.
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.
lunes, 21 de enero de 2008
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.
lunes, 14 de enero de 2008
Métrica v3 vs. ESA
¡Hola a todos! En esta entrada explicaremos las principales diferencias que hemos encontrado entre las dos metodologías que hemos visto a lo largo de la carrera: Métrica v3 y el estándar para la construccion de sistemas software definido por la ESA.
La principal diferencia radica en la división de las fases que componen el ciclo de vida del sistema de información a construir. Mientras que en Métrica v3 se identifican tres procesos principales: Planificación, Desarrollo y Mantenimiento; en la metodología propuesta por la ESA se tiene: Planificación, Desarrollo, Desarrollo Detallado y Mantenimiento. Sin embargo, el enfoque en ambas es similar, es decir, ambas están orientadas al proceso.
Otra diferencia que hemos observado, es el grado de abstracción con el que se trabaja en las fases de desarrollo. Como hemos podido observar este año, en Métrica v3 ya desde el análisis se hace hincapié en el Modelado de Clases, mientras que en la ESA se trabaja a un nivel de Componente, es decir, más abstracto y genérico. De todas formas hay que señalar, que esto no quiere decir que sea así siempre, puede que sea el enfoque que se haya dado en nuestra Universidad a la ESA y en otros lugares se realicen fases de análisis y diseño más concretas y orientadas a las clases.
En lo referente al ámbito de utilización, al desarrollarse Métrica v3 por el Ministerio de Administraciones Públicas, está destinada para proyectos software enmarcados a nivel nacional y en especial para las instituciones públicas del Gobierno de España, mientras que si se está desarrollando un sistema con proyección al exterior (y en especial a nivel Europeo), lo normal es que se use el estándar definido por la ESA.
Por último y relacionado con el artículo de ayer, hay que mencionar un aspecto positivo de la metodología ESA encontrado: ofrece la posibilidad de llevar una metodología en el desarrollo de pequeños sistemas software. Para ello se dispone de una versión reducida de la metodología ESA, denominada ESA Lite, que es una guía para la aplicación de los principios básicos definidos en la ESA en pequeños proyectos software. Para más información, consulten el siguiente enlace.
Un saludo y hasta la próxima entrada.
La principal diferencia radica en la división de las fases que componen el ciclo de vida del sistema de información a construir. Mientras que en Métrica v3 se identifican tres procesos principales: Planificación, Desarrollo y Mantenimiento; en la metodología propuesta por la ESA se tiene: Planificación, Desarrollo, Desarrollo Detallado y Mantenimiento. Sin embargo, el enfoque en ambas es similar, es decir, ambas están orientadas al proceso.
Otra diferencia que hemos observado, es el grado de abstracción con el que se trabaja en las fases de desarrollo. Como hemos podido observar este año, en Métrica v3 ya desde el análisis se hace hincapié en el Modelado de Clases, mientras que en la ESA se trabaja a un nivel de Componente, es decir, más abstracto y genérico. De todas formas hay que señalar, que esto no quiere decir que sea así siempre, puede que sea el enfoque que se haya dado en nuestra Universidad a la ESA y en otros lugares se realicen fases de análisis y diseño más concretas y orientadas a las clases.
En lo referente al ámbito de utilización, al desarrollarse Métrica v3 por el Ministerio de Administraciones Públicas, está destinada para proyectos software enmarcados a nivel nacional y en especial para las instituciones públicas del Gobierno de España, mientras que si se está desarrollando un sistema con proyección al exterior (y en especial a nivel Europeo), lo normal es que se use el estándar definido por la ESA.
Por último y relacionado con el artículo de ayer, hay que mencionar un aspecto positivo de la metodología ESA encontrado: ofrece la posibilidad de llevar una metodología en el desarrollo de pequeños sistemas software. Para ello se dispone de una versión reducida de la metodología ESA, denominada ESA Lite, que es una guía para la aplicación de los principios básicos definidos en la ESA en pequeños proyectos software. Para más información, consulten el siguiente enlace.
Un saludo y hasta la próxima entrada.
domingo, 13 de enero de 2008
Desarrollo Software Ágil
Buenas noches a todos. En la entrada de hoy se va a hablar sobre el desarrollo de software ágil o lo que se conoce como métodos ágiles. Aunque no se ha comentado nada en la asignatura (debido al amplio temario que ya se tiene), nos parece un tema interesante y muy relacionado con la Ingeniería del Software. La descripción tratará de responder a la siguientes preguntas:
- ¿Qué son los métodos ágiles?
- ¿Para cúando son convenientes utilizarlos?
En cuanto a la primera pregunta, las técnicas basadas en métodos ágiles tratan de enfocar el desarrollo software al cambio de los requisitos (incluso aunque estos se sitúen ya dentro de la fase de diseño), de forma que el cliente se involucre en el trabajo (pues son las mayores fuentes de cambios en la creación de un sistema de información). Ahora la pregunta es inmediata, ¿cómo se enfoca el desarrollo al cambio? La idea es sencilla: teniendo lo antes posible un software que funcione, se podrá calcular el proceso completado en la construcción del sistema. Para ello es importante obtener las siguientes características:
- El equipo de negocio y de desarrollo deben trabajar juntos y con una comunicación fluida y consistente, siendo lo más eficiente el trabajo "cara a cara".
- Trabajar orientado a la simplicidad.
- Intentar seguir patrones de diseño y la calidad técnica en la programación.
- Intentar que el equipo se busque la forma de trabajo más eficiente y efectiva para su trabajo.
- Enfocar el diseño de la arquitectura hacia componentes.
Respecto a la segunda pregunta, antes de todo hay que situar los antecedentes del desarrollo software, es decir, cómo estaba todo antes de aplicar estas nuevas técnicas. Básicamente el mundo de la ingeniería del software estaba en crisis: no había métodos de trabajo y producción predecibles y buenos ante la volatilidad de requisitos, los modelos de trabajo industriales eran difíciles de mapear a un proceso software y el boom del paradigma orientado a objetos hacía difícil de reutilizar los métodos de trabajo existentes. Por estas importantes razones se crearon las técnicas basadas en métodos ligeros, aunque también dio lugar a las basadas en CMM/CMMI (establecimiento y mejora de los procesos software) estudiadas en clase. Concretamente, el desarrollo software ligero intenta corregir la pérdida de la productividad (incluso en aumentarla) en los casos donde la especificación y validación de las necesidades del cliente cambia seriamente, pero también genera otra importante ventaja (directamente relacionada con la anterior): la disminución de la tasa de errores en los proyectos software, es decir, ahora hay un método de prevención o choque frente al cambio, que en proyectos que no lo tuviesen podría incluso ocasionar hasta la cancelación del mismo, llegando a provocar importantes pérdidas de dinero.
Pues hasta aquí la entrada de hoy. Espero que os sirva para entender a grosso modo qué son los métodos ligeros, y si tenéis alguna duda, ya sabéis: ¡a los comentarios!
P.D.: Muchas gracias a Miguel Olivares por sus apuntes relacionados con este tema, obtenidos de la asignatura "Desarrollo de Herramientas Informáticas de Productividad".
miércoles, 9 de enero de 2008
EN LA FINAL!!!!!
¡¡¡ Ya estamos en la final !!! Los profesores y el resto de compañeros han decidido que junto http://howtopassse3.blogspot.com/ y http://meencantalaingenieriadelsoftware.blogspot.com/ (no dudéis en visitarlos) somos los finalistas del concurso de blogs.
Nos están encantando la idea del blog y lo más importante, estamos reforzando los conocimientos de la asignatura y aprendiendo nuevos. Como ya hemos dicho en anteriores ocasiones, lo que más ilusión nos da (además del premio lógicamente0), es ver que el blog es útil para la gente interesada en el tema (stakeholders como se diría en la Ingeniería del Software, jejeje) y este hecho lo agradecemos un montón: al igual que cuando nosotros visitamos otros blogs o foros para aprender conocimientos para esta asigntaura u otras.
Pues nada más que deciros por hoy. Agradecer a los profesores y compañeros al confiar en nosotros, gracias por competir a los blogs eliminados y suerte para los dos restantes.
Un saludo y hasta la próxima.
Nos están encantando la idea del blog y lo más importante, estamos reforzando los conocimientos de la asignatura y aprendiendo nuevos. Como ya hemos dicho en anteriores ocasiones, lo que más ilusión nos da (además del premio lógicamente0), es ver que el blog es útil para la gente interesada en el tema (stakeholders como se diría en la Ingeniería del Software, jejeje) y este hecho lo agradecemos un montón: al igual que cuando nosotros visitamos otros blogs o foros para aprender conocimientos para esta asigntaura u otras.
Pues nada más que deciros por hoy. Agradecer a los profesores y compañeros al confiar en nosotros, gracias por competir a los blogs eliminados y suerte para los dos restantes.
Un saludo y hasta la próxima.
viernes, 4 de enero de 2008
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:
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.
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.
Consejos para lograr un buen trabajo en grupo
Hola a todos. Ya estamos aquí de nuevo. Sentimos no haber escrito durante estas fiestas pues son épocas de irse a los pueblos de los padres y resulta difícil tener acceso a Internet. Sin embargo, las ideas no han parado de surgir y para estos días tenemos un montón de entradas ya pensadas.
Lo primero de todo es desearos un buen día de Reyes y que hayáis pasado una buena Noche Buena y entrada de año. Lo segundo es que pronto sabremos si nos hemos clasificado para la fase final del concurso de blogs; el resto de compañeros ha trabajo fuerte durante esta segunda fase, aunque esperamos un resultado positivo y poder luchar para la gran final.
En cuanto a la entrada que expondremos a continuación, creemos que va a ser una de las mejores y más divertidas. Lo que se va a hacer es lo siguiente: hicimos una serie de preguntas a dos personas con una experiencia consolidada en la gestión y dirección de proyectos, comparando al final sus procedimientos y formar para coordinar y conseguir un buen trabajo en grupo.
Por una lado y de color amarillo estarán las contestaciones de D. Ricardo Colomo Palacios, nuestro profesor de la asignatura, y por otro lado y de color turquesa D. Juan de Castro Paredes, director de la compañia GMV-SGI. Bueno, sin más rodeos se muestran los resultados obtenidos:
Está claro que para lograr una buena coordinación en el equipo de trabajo es muy importante que el jefe de proyecto tenga un buen liderazgo y que los miembros del equipo estén dispuestos a colaborar. ¿Consideras alguna de estás condiciones más importante que la otra?
Con toda probabilidad ambas condiciones están muy ligadas. Así, existen innumerables casos de equipos de trabajo poco motivados de forma inicial cuyos responsables han sabido estimular para lograr el éxito del proyecto, pero también de lo contrario, es decir, equipos motivados arruinados por líderes incompetentes. Para mí, una de las dos condiciones se tiene que dar de forma obligada, y si me tengo que quedar con una, confío en los líderes.
Ambas son fundamentales. Lo que sí es cierto es que mediante el liderazgo y capacidad de gestión del Jefe de Proyecto de alguna forma se puede conseguir que el equipo colabore, ya que es su responsabilidad motivar al equipo y conseguir que todo el equipo funcione como una única entidad atómica hacia el objetivo común que es el éxito del proyecto.
A la hora de repartir tareas entre los miembros del equipo, ¿qué criterios sigue? (Evidentemente análisis será para los analistas pero ¿reparte las diversas partes del análisis o delega esa partición del trabajo?)
En los últimos años la Ingeniería del Software está trabajando en lo que se denomina "encaje persona puesto". Yo soy partidario de asignar las tareas a los mejores, por lo menos desde el punto de vista de resultados, sin embargo, también creo que el desarrollo profesional de las personas pasa por darles oportunidades de crecimiento. Por ello, los sistemas de evaluación de competencias tienen mucho de aportar en las asignaciones desde el punto de vista del plan de carrera y el crecimiento competencial. Así, el criterio resultadista debe ser obligatoriamente combinado con la formación del capital intelectual del equipo de trabajo.
Depende claramente de la dimensión del equipo de proyecto. En proyectos complejos y equipos de proyecto medios o grandes, el reparto de responsabilidades o tareas ha de realizarse de forma delegada, dado que de forma paralela hay que hacer el seguimiento del estado de cada tarea y el Jefe de Proyecto no podría seguirlas todas. En equipos de proyecto más pequeños puede estar involucrado directamente en la repartición y seguimiento de todo el trabajo. Como criterio de asignación obviamente el fundamental es la experiencia y capacidad de cada miembro del equipo, sin perder nunca de vista la importancia de ofrecer retos a cada miembro del equipo para que cada uno evolucione en su carrera profesional y se encuentre motivado en todo momento.
Una de las partes más importantes para lograr planificaciones de calidad es la estimación del esfuerzo que cada tarea requiere. ¿Cree que la estimación del esfuerzo de cada tarea debe recaer en el jefe de proyecto o éste puede delegarla al encargado de dicha tarea?
El jefe de proyecto es, desde luego, el responsable de la planificación. Sin embargo, creo que en el liderazgo consultivo que tiene que llevar a cabo (o, al menos esta es mi opinión), debe contar con miembros de su equipo para distintas tareas, entre ellas, la planificación.
El responsable último de la planificación de cada tarea ha de ser el Jefe de Proyecto. Sin embargo, también es fundamental que cada miembro del equipo vea dicha planificación viable y se comprometa con los plazos establecidos. Por lo tanto, siempre es conveniente realizar la planificación con todo el equipo o por lo menos revisarla con cada uno de los involucrados.
Si en algún caso delega la estimación del esfuerzo, ¿Confía totalmente en que no le engañen para trabajar menos?
La confianza es un tema muy interesante. Considero que en lo que a la ciencia del Management se refiere, la confianza es una función de una desviación típica y un tamaño de muestra. Por ello, y esta es una respuesta casi general, depende.
Como he comentado anteriormente, la planificación debe estar dirigida por el Jefe de Proyecto. Pero como respuesta a la pregunta planteada, uno de los pilares del buen funcionamiento de un equipo de proyecto profesional es la confianza entre los miembros, por lo que a priori no se debe contar con que ninguno vaya a engañar en su estimación. De cualquier forma el Jefe de Proyecto ha de tener la experiencia y conocimientos suficientes para saber valorar la propuesta de planificación que cualquiera de los miembros aporte, y perfectamente se puede detectar una planificación sobreestimada (o infraestimada). A la pregunta sobre el engaño, si en cualquier momento el Jefe de Proyecto percibe dicha situación ha de hablarlo con la persona en cuestión y dejar claro que situaciones así no se pueden permitir dado que generan situaciones de injusticia en el equipo.
Como jefe de proyecto, ¿Qué recomienda para incrementar la productividad de sus subordinados? ¿Mano dura o blanda? ¿Alguna medida en particular en cualquiera de los dos sentidos?
La productividad de los desarrolladores depende de un gran número de factores. Uno de los que los investigadores señalan es la relación que se tenga con sus superiores. En este sentido, el jefe de proyecto debe saber los mecanismos para el gobierno del grupo en conjunto y de los individuos de forma aislada. Sobre las medidas, sólo una regla general: imperativo categórico.
La mano dura puede ser productiva a corto plazo pero no suele ser una buena solución a medio/largo plazo dado que genera tensiones entre el equipo. La mano blanda tampoco es una buena solución porque en un entorno profesional es fundamental la transparencia y comunicación entre el equipo y hay que comunicar claramente tanto los logros como las equivocaciones. En este sentido y para maximizar el fruto de un equipo de proyecto, es fundamental la 'asertividad', entendida como "un comportamiento comunicacional maduro en el que la persona ni agrede ni se somete a la voluntad de otras personas, sino que expresa sus convicciones y defiende sus derechos" (Wikipedia), que visto desde el punto de vista del Jefe de Proyecto hace que la relación sea sincera y transparente, dejando claro la responsabilidad de cada uno, repasando el estado de cada compromiso en cada momento, y otorgando en todo momento los reconocimientos positivos o negativos que cada miembro del equipo se merezca.
En caso de que alguien no realice la parte del proyecto que le fue asignada o que la realice muy mal, ¿Qué medidas toma? ¿Sigue asignándole otras partes?
Se deben analizar las razones para el fracaso. Y depurar las responsabilidades con la cabeza fría. Los recursos humanos conforman el capital intelectual de las organizaciones. Y las organizaciones de desarrollo de software son intensivas en este tipo de capital. Siempre hay que intentar reenganchar al recurso, nunca abandolarle o condenarle al ostracismo.
Como he comentado anteriormente, el punto fundamental es la comunicación transparente con dicho miembro de forma que sepa qué medidas o herramientas puede utilizar para que no vuelva a suceder en un futuro. Hay que saber distinguir entre los errores que todo el mundo comete como parte de su evolución y aprendizaje, de aquellos que suceden por falta de interés o compromiso ya que el mensaje a transmitir varía enormemente: en el primer caso hay que realizar labores de coaching para ayudarle en su evolución profesional y hacerle comprender que son naturales (manteniendo su motivación), mientras que en el segundo caso hay que analizarlo con la persona en cuestión para no vuelva a suceder. Como resumen hay que entender que todas las personas cometen errores en su desempeño profesional pero que, lejos de ser puntos negativos, han de considerarse como oportunidades de aprendizaje si así se entienden por ambas partes.
Para tener en cuenta toda la organización de todo el equipo, ¿Qué herramientas y dispositivos usa para gestionar la planificación, calendario, reuniones, etc.?
Se pueden aplicar multitud de técnicas, son las herramientas de trabajo del JP. Se encuentran en los manuales, sin embargo, a mi me gusta pensar que , además de los instrumentos científicos, el JP cuenta con herramientas propias: escuchar, analizar y tomar decisiones en base a estos análisis. Su trabajo es, en buena parte,ese. En muchos casos, los miembros del equipo de trabajo piden a gritos que les escuche un JP "sordo", aislado de su entorno. Sin caer en la figura del "ladrón del tiempo", el jefe de proyecto debe comunicarse de forma regular con su equipo, en algunos casos de forma planificada, y en otros, y a mi juicio estos contactos son en muchos casos los más enriquecedoros, de forma informal.
Las herramientas a utilizar varían fundamentalmente del tamaño, naturaleza y complejidad del proyecto. Los básicos en cuanto a gestión de la planificación son mantener el calendario del proyecto con los detalles de cada subtarea, el detalle del responsable de cada una de ellas, análisis del camino crítico, establecimiento de puntos claves de planificación (que permitirán lanzar alertas tempranas sobre posibles desviaciones de planificación), así como asegurarse de que cada miembro del equipo conoce sus tareas y plazos en todo momento (de nuevo enfatizar la comunicación!).
Ante todo, muchas gracias a los dos por colaborar desinteresadamente en nuestro blog y gastar vuestro valioso tiempo. En cuanto a las conclusiones que hemos sacado de las resultados son las siguientes:
* Sus estilos de dirección son muy similares: piensan que liderazgo y colaboración están ligados, confian en la delegación de las responsabilidades, consideran el error como punto de aprendizaje y reenganche de la persona que ha cometido el error y enfatizar la comunicación del grupo para conseguir una buena organización del grupo (aunque no cayendo en el error de convertirse en un jefe "ladrón del tiempo" como bien dice Ricardo Colomo).
* En cuanto a las diferencias, se centran a detalles bastante concretos: mientras Ricardo Colomo sigue una línea más resultadista en el reparto de tareas, Juan de Castro se guía por la experiencia del Jefe del Proyecto.
* Un aspecto que queremos resaltar son los nuevos conceptos aprendidos: como ya hemos dicho el "ladrón de tiempo" y también hay que señalar el imperativo categórico y la asertividad de Ricardo y Juan respectivamente en la gestión de la productividad del equipo de desarrollo.
Lo primero de todo es desearos un buen día de Reyes y que hayáis pasado una buena Noche Buena y entrada de año. Lo segundo es que pronto sabremos si nos hemos clasificado para la fase final del concurso de blogs; el resto de compañeros ha trabajo fuerte durante esta segunda fase, aunque esperamos un resultado positivo y poder luchar para la gran final.
En cuanto a la entrada que expondremos a continuación, creemos que va a ser una de las mejores y más divertidas. Lo que se va a hacer es lo siguiente: hicimos una serie de preguntas a dos personas con una experiencia consolidada en la gestión y dirección de proyectos, comparando al final sus procedimientos y formar para coordinar y conseguir un buen trabajo en grupo.
Por una lado y de color amarillo estarán las contestaciones de D. Ricardo Colomo Palacios, nuestro profesor de la asignatura, y por otro lado y de color turquesa D. Juan de Castro Paredes, director de la compañia GMV-SGI. Bueno, sin más rodeos se muestran los resultados obtenidos:
Está claro que para lograr una buena coordinación en el equipo de trabajo es muy importante que el jefe de proyecto tenga un buen liderazgo y que los miembros del equipo estén dispuestos a colaborar. ¿Consideras alguna de estás condiciones más importante que la otra?
Con toda probabilidad ambas condiciones están muy ligadas. Así, existen innumerables casos de equipos de trabajo poco motivados de forma inicial cuyos responsables han sabido estimular para lograr el éxito del proyecto, pero también de lo contrario, es decir, equipos motivados arruinados por líderes incompetentes. Para mí, una de las dos condiciones se tiene que dar de forma obligada, y si me tengo que quedar con una, confío en los líderes.
Ambas son fundamentales. Lo que sí es cierto es que mediante el liderazgo y capacidad de gestión del Jefe de Proyecto de alguna forma se puede conseguir que el equipo colabore, ya que es su responsabilidad motivar al equipo y conseguir que todo el equipo funcione como una única entidad atómica hacia el objetivo común que es el éxito del proyecto.
A la hora de repartir tareas entre los miembros del equipo, ¿qué criterios sigue? (Evidentemente análisis será para los analistas pero ¿reparte las diversas partes del análisis o delega esa partición del trabajo?)
En los últimos años la Ingeniería del Software está trabajando en lo que se denomina "encaje persona puesto". Yo soy partidario de asignar las tareas a los mejores, por lo menos desde el punto de vista de resultados, sin embargo, también creo que el desarrollo profesional de las personas pasa por darles oportunidades de crecimiento. Por ello, los sistemas de evaluación de competencias tienen mucho de aportar en las asignaciones desde el punto de vista del plan de carrera y el crecimiento competencial. Así, el criterio resultadista debe ser obligatoriamente combinado con la formación del capital intelectual del equipo de trabajo.
Depende claramente de la dimensión del equipo de proyecto. En proyectos complejos y equipos de proyecto medios o grandes, el reparto de responsabilidades o tareas ha de realizarse de forma delegada, dado que de forma paralela hay que hacer el seguimiento del estado de cada tarea y el Jefe de Proyecto no podría seguirlas todas. En equipos de proyecto más pequeños puede estar involucrado directamente en la repartición y seguimiento de todo el trabajo. Como criterio de asignación obviamente el fundamental es la experiencia y capacidad de cada miembro del equipo, sin perder nunca de vista la importancia de ofrecer retos a cada miembro del equipo para que cada uno evolucione en su carrera profesional y se encuentre motivado en todo momento.
Una de las partes más importantes para lograr planificaciones de calidad es la estimación del esfuerzo que cada tarea requiere. ¿Cree que la estimación del esfuerzo de cada tarea debe recaer en el jefe de proyecto o éste puede delegarla al encargado de dicha tarea?
El jefe de proyecto es, desde luego, el responsable de la planificación. Sin embargo, creo que en el liderazgo consultivo que tiene que llevar a cabo (o, al menos esta es mi opinión), debe contar con miembros de su equipo para distintas tareas, entre ellas, la planificación.
El responsable último de la planificación de cada tarea ha de ser el Jefe de Proyecto. Sin embargo, también es fundamental que cada miembro del equipo vea dicha planificación viable y se comprometa con los plazos establecidos. Por lo tanto, siempre es conveniente realizar la planificación con todo el equipo o por lo menos revisarla con cada uno de los involucrados.
Si en algún caso delega la estimación del esfuerzo, ¿Confía totalmente en que no le engañen para trabajar menos?
La confianza es un tema muy interesante. Considero que en lo que a la ciencia del Management se refiere, la confianza es una función de una desviación típica y un tamaño de muestra. Por ello, y esta es una respuesta casi general, depende.
Como he comentado anteriormente, la planificación debe estar dirigida por el Jefe de Proyecto. Pero como respuesta a la pregunta planteada, uno de los pilares del buen funcionamiento de un equipo de proyecto profesional es la confianza entre los miembros, por lo que a priori no se debe contar con que ninguno vaya a engañar en su estimación. De cualquier forma el Jefe de Proyecto ha de tener la experiencia y conocimientos suficientes para saber valorar la propuesta de planificación que cualquiera de los miembros aporte, y perfectamente se puede detectar una planificación sobreestimada (o infraestimada). A la pregunta sobre el engaño, si en cualquier momento el Jefe de Proyecto percibe dicha situación ha de hablarlo con la persona en cuestión y dejar claro que situaciones así no se pueden permitir dado que generan situaciones de injusticia en el equipo.
Como jefe de proyecto, ¿Qué recomienda para incrementar la productividad de sus subordinados? ¿Mano dura o blanda? ¿Alguna medida en particular en cualquiera de los dos sentidos?
La productividad de los desarrolladores depende de un gran número de factores. Uno de los que los investigadores señalan es la relación que se tenga con sus superiores. En este sentido, el jefe de proyecto debe saber los mecanismos para el gobierno del grupo en conjunto y de los individuos de forma aislada. Sobre las medidas, sólo una regla general: imperativo categórico.
La mano dura puede ser productiva a corto plazo pero no suele ser una buena solución a medio/largo plazo dado que genera tensiones entre el equipo. La mano blanda tampoco es una buena solución porque en un entorno profesional es fundamental la transparencia y comunicación entre el equipo y hay que comunicar claramente tanto los logros como las equivocaciones. En este sentido y para maximizar el fruto de un equipo de proyecto, es fundamental la 'asertividad', entendida como "un comportamiento comunicacional maduro en el que la persona ni agrede ni se somete a la voluntad de otras personas, sino que expresa sus convicciones y defiende sus derechos" (Wikipedia), que visto desde el punto de vista del Jefe de Proyecto hace que la relación sea sincera y transparente, dejando claro la responsabilidad de cada uno, repasando el estado de cada compromiso en cada momento, y otorgando en todo momento los reconocimientos positivos o negativos que cada miembro del equipo se merezca.
En caso de que alguien no realice la parte del proyecto que le fue asignada o que la realice muy mal, ¿Qué medidas toma? ¿Sigue asignándole otras partes?
Se deben analizar las razones para el fracaso. Y depurar las responsabilidades con la cabeza fría. Los recursos humanos conforman el capital intelectual de las organizaciones. Y las organizaciones de desarrollo de software son intensivas en este tipo de capital. Siempre hay que intentar reenganchar al recurso, nunca abandolarle o condenarle al ostracismo.
Como he comentado anteriormente, el punto fundamental es la comunicación transparente con dicho miembro de forma que sepa qué medidas o herramientas puede utilizar para que no vuelva a suceder en un futuro. Hay que saber distinguir entre los errores que todo el mundo comete como parte de su evolución y aprendizaje, de aquellos que suceden por falta de interés o compromiso ya que el mensaje a transmitir varía enormemente: en el primer caso hay que realizar labores de coaching para ayudarle en su evolución profesional y hacerle comprender que son naturales (manteniendo su motivación), mientras que en el segundo caso hay que analizarlo con la persona en cuestión para no vuelva a suceder. Como resumen hay que entender que todas las personas cometen errores en su desempeño profesional pero que, lejos de ser puntos negativos, han de considerarse como oportunidades de aprendizaje si así se entienden por ambas partes.
Para tener en cuenta toda la organización de todo el equipo, ¿Qué herramientas y dispositivos usa para gestionar la planificación, calendario, reuniones, etc.?
Se pueden aplicar multitud de técnicas, son las herramientas de trabajo del JP. Se encuentran en los manuales, sin embargo, a mi me gusta pensar que , además de los instrumentos científicos, el JP cuenta con herramientas propias: escuchar, analizar y tomar decisiones en base a estos análisis. Su trabajo es, en buena parte,ese. En muchos casos, los miembros del equipo de trabajo piden a gritos que les escuche un JP "sordo", aislado de su entorno. Sin caer en la figura del "ladrón del tiempo", el jefe de proyecto debe comunicarse de forma regular con su equipo, en algunos casos de forma planificada, y en otros, y a mi juicio estos contactos son en muchos casos los más enriquecedoros, de forma informal.
Las herramientas a utilizar varían fundamentalmente del tamaño, naturaleza y complejidad del proyecto. Los básicos en cuanto a gestión de la planificación son mantener el calendario del proyecto con los detalles de cada subtarea, el detalle del responsable de cada una de ellas, análisis del camino crítico, establecimiento de puntos claves de planificación (que permitirán lanzar alertas tempranas sobre posibles desviaciones de planificación), así como asegurarse de que cada miembro del equipo conoce sus tareas y plazos en todo momento (de nuevo enfatizar la comunicación!).
Ante todo, muchas gracias a los dos por colaborar desinteresadamente en nuestro blog y gastar vuestro valioso tiempo. En cuanto a las conclusiones que hemos sacado de las resultados son las siguientes:
* Sus estilos de dirección son muy similares: piensan que liderazgo y colaboración están ligados, confian en la delegación de las responsabilidades, consideran el error como punto de aprendizaje y reenganche de la persona que ha cometido el error y enfatizar la comunicación del grupo para conseguir una buena organización del grupo (aunque no cayendo en el error de convertirse en un jefe "ladrón del tiempo" como bien dice Ricardo Colomo).
* En cuanto a las diferencias, se centran a detalles bastante concretos: mientras Ricardo Colomo sigue una línea más resultadista en el reparto de tareas, Juan de Castro se guía por la experiencia del Jefe del Proyecto.
* Un aspecto que queremos resaltar son los nuevos conceptos aprendidos: como ya hemos dicho el "ladrón de tiempo" y también hay que señalar el imperativo categórico y la asertividad de Ricardo y Juan respectivamente en la gestión de la productividad del equipo de desarrollo.
Suscribirse a:
Entradas (Atom)
