Entre líneas...

La Nota Final...

2009-01-17T10:11:00.004+01:00

Ayer, día 16 de enero, recibimos la nota de Ingeniería del Software III. Tanto trabajo, tanto esfuerzo, tantas horas sin dormir, tanto word,... tanto todo... había tenido, por fín, su reflejo en una calificación. A la vista de los resultados, creemos que la tónica general del grupo (Grupo 81 de Ing. Informática), ha sido notable, con un nivel general bastante más que aceptable.

Simplemente queremos felicitar a todos nuestros compañeros, y a nosotros mismos, por todo este gran trabajo realizado, por todo el ese esfuerzo, y porque todos hemos dado lo mejor para llegar hasta aquí.

¡¡¡Felicidades!!!

Ah, y recordad que ya queda una menos...

La Entrevista de Trabajo (II)

2009-01-17T09:44:00.003+01:00

En el anterior post ya os introducíamos, desde una perspectiva muy global, cómo eran los procesos de selección en las empresas y qué pasos se solían seguir hasta encontrar al candidato idóneo. Pues bien, hoy vamos a hablaros de las Dinámicas de Grupo.

Normalmente suelen ser una de las técnicas empleadas en los primeros pasos de un proceso de selección de personal, y dan una visión, muchísimo más clara que la de un mero currículum, de cómo es una personal, de cuál es su perfil real y de cómo reacciona ante imprevistos.

Este trabajo se desarrolla en grupo, entre 4 y 8 personas suele ser lo normal, y se trata de que, entre todos, se consiga llegar a ofrecer una solución a un problema planteado, siempre con consenso y sin que existan graves discrepancias entre los componentes del equipo. Lo más frecuente es que el supuesto al que nos enfrentemos tenga poco o nada que ver con nuestro área de conocimiento, sino que se busca encontrar otro tipo de aptitudes, más allá de las puramente técnicas inherentes a cada perfil. Miden tu capacidad de negociación, tu iniciativa y creatividad, tu tendencia al liderazgo, tu autonomía o dependencia con respecto al grupo, tu habilidad de comunicación, escucha y empatía, tu asertividad (habilidad para expresar tus necesidades y pensamientos sin sumisión ni agresividad), tu nivel de proactividad o pasividad, si trabajas con motivación intrínseca o extrínseca, e incluso tu escala de valores.

En resumidas cuentas, os vamos a dar una serie de consejillos para que, cuando os enfrentéis a un proceso de este tipo, tengáis recursos para salir victoriosos.

Créate un primer esquema mental del problema, muy básico, para poder tener un control mayor de las distintas opiniones del resto de compañeros.
Ten conocimiento de los detalles que se les pueden escapar a los demás y házselos saber.
Controla el tiempo, sintetiza, sé claro y no pierdas tiempo en temas banales. Evita siempre salirte del tema principal, trátalo en profundidad, no en amplitud.
No mires al entrevistador, céntrate en el trabajo que tienes que realizar.
No intentes llevar la voz cantante, como si quisieras demostrar una gran capacidad de liderazgo, se suele valorar de forma negativa.
Trabaja en equipo, escúcha a tus compañeros y toma nota de lo que dicen.
No olvides nunca que se trata de un trabajo en equipo y que, por tanto, has de emplear el plural para hablar. Esto que puede parecer una trivialidad en absoluto lo es.

Y, sobre todo y lo más importante, SÉ TÚ MISMO y SÉ NATURAL. Es absurdo fingir algo que no eres, porque el proceso no acaba aquí y se acabará viendo cómo eres realmente en posteriores entrevistas.

La Entrevista de Trabajo (I)

2009-01-15T11:01:00.006+01:00

Seguramente muchos de vosotros habréis participado en un proceso de selección o similar, con el fin de acceder a algún puesto de trabajo en una determinada empresa. Tanto si es así, como si no, se va acercando la hora de empezar a buscar trabajito...

Hay múltiples, cientos, miles, de teorías sobre cómo has de comportarte o cómo has de actuar en una entrevista o proceso de selección, trucos, etc. Nosotros lo que pretendemos es darte una serie de recomendaciones basadas en nuestra experiencia personal, en lo que hemos vivido, para que puedan serte de utilidad en el futuro.

La mayoría de los procesos de selección constan de, al menos, tres partes bien diferenciadas:

Primera Fase: es la toma de contacto, donde se evalúan, de forma analítica, distintas aptitudes del candidato (inglés, capacidad para las relaciones humanas, comunicación, reacción ante imprevistos, capacidad analítica, etc.). Usualmente se suele realizar en grupos, es decir, un conjunto de personas que trabajan en equipo. Es importante, pero no clave, simplemente sirve para encuadrar a cada candidato en un determinado perfil y para descartar aquellos que no respondan a ninguno de los perfiles requeridos.
Segunda Fase: normalmente suele tratarse de una entrevista ya personal, con gente de Recursos Humanos. En este punto suele haber dos tipos muy diferenciados, la cordial, donde repasan tu Currículum, te preguntan qué sabes, qué te gusta más, etc, para encuadrarte dentro de la empresa, o la fucking, es decir, que te masacran con múltiples preguntas, casi todas de carácter personal, para ver cómo reaccionas. Éstas últimas no suelen ser las típicas, pero, como las meigas, haberlas, hailas. También te comentan y explican los distintos departamentos de la empresa, a qué se dedican, etc.
Tercera Fase: transcurridos los dos procesos anteriores, el último paso suele ser la entrevista con un Gerente/Jefe de Proyecto de la empresa (generalmente responsable de un área en la que tu perfil encaje). En ella, esa persona te explica a qué se dedica su departamento, qué se hace, qué podrías hacer, y evalúa tus aptitudes desde un punto de vista más técnico.

En todas ellas creemos que son fundamentales varios aspectos: naturalidad, ser uno mismo, estar tranquilo, no intentar ni tener afán por destacar y ser la voz cantante, ser rápido e intentar cuadrar tu experiencia y conocimientos en lo que ellos piden, demostrar interés, etc.

Seguiremos hablando de este mundillo en sucesivos posts, entrando a valorar y comentar aspectos más detallados y dando consejos más puntuales.

Otra muestra más de la magnitud de Twitter

2009-01-12T16:25:00.004+01:00

Leyendo el blog de Enrique Dans, recomienda este artículo publicado en el diario La Razón. En él se habla de la multitud de organizaciones, estamentos e incluso gente famosa que lo utiliza: el Gobierno de Israel, Obama, Lance Armstrong, Shaquille O'Neal, Andy Muray, Britney Spears... Sin ánimo de desvelar más contenidos del propio artículo, os convidamos a su lectura y a que saquéis vuestras propias conclusiones de hasta dónde llega el "¿Qué estás haciendo?"

El fin...

2009-01-08T18:31:00.003+01:00

Bueno, hoy, día 8 de enero de 2009, a las 16 horas se ha producido el momento que todos anhelábamos... la entrega final de toda la documentación de Ingeniería del Software III. Han sido unos meses duros, muy duros, en los que todos hemos trabajado mucho con una única meta, llegar a donde hemos llegado hoy y como hemos llegado.

Como muestra, os queremos dejar un testimonio gráfico de lo que ha supuesto nuestro trabajo...

PD: está impreso a doble cara y a dos páginas por cara...

Feliz 2009

2009-01-01T21:41:00.003+01:00

Desde aquí no queríamos dejar pasar la oportunidad de desearos a todos un muy Feliz Año... y que ojalá este 2009 que ahora comienza sea, cuanto menos, tan bueno como el año que ahora acaba.

¡ Muy Feliz 2009 !

El Cuadro de Mando Integral

2008-12-31T00:07:00.005+01:00

En este post os vamos a comentar una de los paradigmas más empleados en la actualidad como ayuda para la Gestión de Proyectos, el Cuadro de Mando Integral. Este Sistema de Gestión permite al Jefe de Proyecto tener una perspectiva global y visual del estado de distintas fases o aspectos que competen al propio proyecto, de tal forma que le proporciona una visión mucho más simplificada de la información.

Así mismo, permite mostrar continuamente cuándo un equipo de trabajo alcanza los resultados definidos por el plan estratégico, ayudando también a la propia compañía a expresar los objetivos e iniciativas necesarias para cumplir con la estrategia. El Cuadro de Mando Integral llena el vacío que existe en la mayoría de sistemas de gestión: la falta de un proceso sistemático para poner en práctica y obtener feedback sobre la estrategia empresarial.

El Cuadro de Mando Integral se basa en los Indicadores, que no son más que un dato o conjunto de datos que ayudan a medir objetivamente la evolución de un proceso o de una actividad, a partir de los cuales puede establecer estadísticas, gráficos,... que serán de enorme utilidad para conocer el estado actual de un Proyecto Software.

El CMI pretende que se vea a la organización desde cuatro puntos de vista bien diferenciados:

Innovación y Aprendizaje: mejora continua.
Interna del Negocio: puntos fuertes.
Del Cliente: visión del cliente.
Financiera: visión del accionista.

Resumiendo, el CMI es un Sistema de Administración o Gestión Estratégica Empresarial, cuyas principales funcionalidades son:

Formular una estrategia consistente y transparente.
Comunicar la estrategia a través de la organización.
Coordinar los objetivos de las diversas unidades organizativas.
Conectar los objetivos con la planificación financiera y presupuestaria.
Identificar y coordinar las iniciativas estratégicas.
Medir de un modo sistemático la realización, proponiendo acciones correctivas oportunas.

El WorkFlow

2008-12-30T23:55:00.003+01:00

El Flujo de Trabajo (WorkFlow en inglés) es el estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas. En definitiva, el análisis de las distintas tareas y actores que participan en los procesos de negocio.

Un WorkFlow presenta la ventaja de automatizar las distintas secuencias de actividades o tareas que se ven implicadas en la realización de un proceso de negocio, incluyendo el seguimiento del estado de cada una de sus etapas y la aportación de las herramientas necesarias para gestionarlo.

Por lo general se distinguen dos tipos de Workflow:

Workflow procedimental (también denominado Workflow de producción o Workflow administrativo), que corresponde a procesos de negocios conocidos de la empresa y que está sujeto a procedimientos preestablecidos. En este caso, la dirección del Workflow es más o menos fija.
Workflow ad hoc, que se basa en un modelo de trabajo de grupo en el cual los protagonistas participan en la decisión de hacia dónde dirigir el Workflow. Aquí la dirección del Worflow es dinámica.

Los objetivos que cualquier WorkFlow son los siguientes:

Reflejar, mecanizar y automatizar los métodos y organización en el sistema de información.
Establecer los mecanismos de control y seguimiento de los procedimientos organizativos.
Independizar el método y flujo de trabajo de las personas que lo ejecutan.
Facilitar la movilidad del personal.
Soportar procesos de reingeniería de negocio.
Agilizar el proceso de intercambio de información y agilizar la toma de decisiones de una organización, empresa o institución.

(Ejemplo de WorkFlow)

Por otra parte, existe el denominado Motor de Workflow, que es una herramienta que permite dar forma y automatizar los procesos de negocio de la empresa. Con este tipo de herramientas se pueden formalizar las reglas comerciales de la empresa para automatizar el proceso de toma de decisiones, es decir, qué rama de Workflow elegir según el contexto.

La Arquitectura Dirigida por Modelos (MDA)

2008-12-30T23:21:00.002+01:00

La Arquitectura Dirigida por Modelos (Model Driven Architecture) es una especificación detallada por el OMG (Object Management Group) que integra diferentes especificaciones y estándares definidos por la misma organización con la finalidad de ofrecer una solución a los problemas relacionados con los cambios en los modelos de negocio, la tecnología y la adaptación de los sistemas de información a los mismos.

MDA nos permite el despliegue de aplicaciones empresariales, diseñadas sin dependencias de plataforma de despliegue y expresado su diseño mediante el uso de UML y otros estándares, potencialmente en cualquier plataforma existente, abierta o propietaria, como Servicios Web, .Net, Corba, J2EE,...

La especificación de las aplicaciones y la funcionalidad de las mismas se expresa en un modelo independiente de la plataforma que permite una abstracción de las características técnicas específicas de las plataformas de despliegue. Mediante transformaciones y trazas aplicadas sobre el modelo independiente de la plataforma, se consigue la generación automática de código específico para la plataforma de despliegue elegida, lo que proporciona finalmente una independencia entre la capa de negocio, y la tecnología empleada. De esta manera es mucho más simple la incorporación de nuevas funcionalidades, o cambios en los procedimientos de negocio sin tener que llevar a cabo los cambios en todos los niveles del proyecto. Simplemente se desarrollan los cambios en el modelo independiente de la plataforma, y éstos se propagarán a la aplicación, consiguiendo por tanto una considerable reducción del esfuerzo en el equipo de desarrollo, en los errores que tienden a producirse en los cambios introducidos en las aplicaciones mediante otros métodos de desarrollo, y por consiguiente, la reducción de costes y aumento de productividad que conlleva, tan demandados tanto la industria de desarrollo de software como el resto de las empresas.

MDA se apoya sobre los siguientes estándares para llevar a cabo su función:

UML: empleado para la definición de los modelos independientes de la plataforma y los modelos específicos de las plataformas de destino. Es un estándar para el modelado introducido por el OMG.
MOF: establece un marco común de trabajo para las especificaciones del OMG, a la vez que provee de un repositorio de modelos y metamodelos.
XMI: define una traza que permite transformar modelos UML en XML para poder ser tratados automáticamente por otras aplicaciones.
CWM: define la transformación de los modelos de datos en el modelo de negocio a los esquemas de base de datos.

MDA rompe con el concepto de producción de software artesanal, automatizando las tareas de diseño, desarrollo y en buena parte despliegue de aplicaciones. Gracias a esta automatización, la ingeniería del software puede participar de las ventajas de que gozan otras ingenierías al usar herramientas de soporte a su disciplina.

La importancia de... la Gestión de la Capacidad

2008-12-29T17:06:00.005+01:00

A lo largo del desarrollo de nuestro proyecto hemos hablado de la gestión de múltiples aspectos, como configuración o calidad, pero hoy nos vamos a centrar en otro que, si bien no tocamos, es harto relevante y puede ser un factor determinante a la hora de conseguir el éxito en un proyecto.

La Gestión de la Capacidad es la encargada de que todos los servicios TI se vean respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente dimensionada. Sin una correcta Gestión de la Capacidad los recursos no se aprovechan adecuadamente y se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y administración. O aún peor, los recursos son insuficientes con la consecuente degradación de la calidad del servicio.

El objetivo primordial de la Gestión de la Capacidad es poner a disposición de clientes, usuarios y el propio departamento TI los recursos informáticos necesarios para desempeñar de una manera eficiente sus tareas y todo ello sin incurrir en costes desproporcionados.

Entre las responsabilidades de la Gestión de la Capacidad se encuentran:

Asegurar que se cubren las necesidades de capacidad TI tanto presentes como futuras.
Controlar de rendimiento de la infraestructura TI.
Desarrollar planes de capacidad asociados a los niveles de servicio acordados.
Gestionar y racionalizar la demanda de servicios TI.

La Gestión de la Capacidad intenta evitar situaciones en las que se realizan inversiones innecesarias en tecnologías que no están adecuadas a las necesidades reales del negocio o están sobredimensionadas, o por el contrario, evitar situaciones en las que la productividad se ve mermada por un insuficiente o deficiente uso de las tecnologías existentes.

Los principales beneficios derivados de una correcta Gestión de la Capacidad son:

Optimizar el rendimiento de los recursos informáticos.
Disponer de la capacidad necesaria en el momento oportuno, evitando así que se pueda resentir la calidad del servicio.
Evitar gastos innecesarios producidos por compras de "última hora".
Planificar el crecimiento de la infraestructura adecuándolo a las necesidades reales de negocio.
Reducir los gastos de mantenimiento y administración asociados a equipos y aplicaciones obsoletos o innecesarios.

La Web Semántica

2008-12-29T16:29:00.004+01:00

La Web Semántica es la nueva generación de la Web que intenta representar información tal como puede ser usada por máquinas, no solo para mostrar propósitos, sino para automatización, integración y reusabilidad a través de aplicaciones. Se centra especialmente en su contenido, más allá de su simple estructura sintáctica.

La web semántica trata hacer la Web más entendible para las máquinas. También trata sobre la construcción de una infraestructura apropiada para que agentes inteligentes trabajen alrededor de la web realizando acciones complejas para sus usuarios. Con este fin, los agentes deben recuperar y manipular la información pertinente, lo que requiere una integración de agentes sin fisuras con la Web y el aprovechar totalmente las infraestructuras existentes (tales como el envío de mensajes, seguridad, autenticación, servicios de directorio, etc). Igualmente, la Web Semántica trata de declarar explícitamente el conocimiento embebido en muchas aplicaciones Web, integrando información de un modo inteligente, ofreciendo acceso semántico a internet y extrayendo información de textos. Finalmente, la Web Semántica trata el cómo implementar servicios web fiables e interoperables a gran escala, creando una web de servicios interpretables e interoperables que agentes inteligentes puedan descubrir, ejecutar y componer automáticamente.
El gran problema que presenta la web "tradicional" es que es enorme, posee cantidades ingentes de información, y no es lo suficientemente inteligente para integrar fácilmente las numerosas piezas de información que el usuario realmente necesita. Hoy en día, la mayor parte de la información de la web está representada en lenguaje natural; es por ello que nuestros ordenadores no pueden entender ni interpretar su significado. Los humanos por sí solos pueden procesar sólo una infinitésima fracción de la información disponible en la Web, y se beneficiarían enormemente si pudiesen recurrir a máquinas que ayudasen a procesar y analizar los contenidos de la Web. Desafortunadamente, la web fue desarrollada para consumo humano, no para consumo máquina – aunque todo en la web es inteligible para las máquinas, no lo es entendible. Se necesita la Web semántica para expresar la información de una forma precisa e interpretable por maquina, preparada para que los agentes puedan procesar, compartir, y reutilizarla, así como entender lo que describen los términos. Todo ello permitiría que las aplicaciones Web interoperasen tanto a nivel sintáctico como semántico.

Los principales horizontes hacia los que camina la web semántica son: buscadores semánticos (swoogle, powerset, cognition o hakia), los servicios web semánticos (fusión de los web services con tecnologías semánticas para proveer servicios más eficientes y potentes) o el Speech Mashup (interpretación de la semántica a través de la voz).

¡Feliz Navidad!

2008-12-24T22:30:00.002+01:00

Hola a tod@s, desde Evosoft os queremos desear una muy Feliz Navidad, que paséis estos días con vuestros seres queridos y que este nuevo año sea, cuanto menos, tan bueno como éste.

¡¡¡ Feliz Navidad !!!

Reflexiones... Luis Puente

2008-12-18T17:36:00.000+01:00

¿Cuál considera que es el factor que más influye en el éxito de un proyecto software?
El compromiso.

¿Qué factor cree que es el más crítico, el más complejo de gestionar?
Las destrezas individuales.

Motivación… ¿Cree que un Ingeniero de Software trabaja más y mejor si está motivado o piensa que ha de realizar su trabajo de la mejor manera posible por el simple hecho de ser un profesional y porque le pagan por ello?
Creo en la motivación.

Nuevos horizontes… ¿Hacia dónde va la ingeniería del software? ¿Cuál es el paradigma del futuro?
Existe una tendencia clara a la realización de procesos más abstractos y serán las máquinas las encargadas de convertir esas abstracciones en componentes físicos.

¿Cuál cree que es la cualidad más importante que tiene que poseer un ingeniero de software?
Capacidades de abstracción y síntesis.

¿ESA o Métrica v3?
ESA.

Una vez casi finalizada la asignatura… ¿cuál es la panorámica que tiene del trabajo realizado por los alumnos este año?
En general se ha confirmado el objetivo con el camino. Métrica 3 y sus documentos no son un objetivo en sí mismo.

¿Qué consejo daría a los alumnos que están a punto de terminar la carrera y que se van a incorporar al mercado laboral?
No perder la confianza en que lo que saben es útil y debe aplicarse.

Y la indiscreta… Si tuviera que recomendar una empresa, y sólo una, a un alumno recién licenciado, ¿cuál sería?
Universidad.

Reflexiones... Juan Miguel Gómez

2008-12-18T16:22:00.000+01:00

¿Cuál considera que es el factor que más influye en el éxito de un proyecto software?
Planificación de Recursos: tiempo y costes.

¿Qué factor cree que es el más crítico, el más complejo de gestionar?
El factor Riesgo, por cuanto tiene de incertidumbre, y la tupla tiempo-coste.

Motivación… ¿Cree que un Ingeniero de Software trabaja más y mejor si está motivado o piensa que ha de realizar su trabajo de la mejor manera posible por el simple hecho de ser un profesional y porque le pagan por ello?
Son dos cosas diferentes. El profesional que es tiene una ética implícita. El profesional bien motivado es doblemente efectivo.

Nuevos horizontes… ¿Hacia dónde va la ingeniería del software? ¿Cuál es el paradigma del futuro?
Dos líneas:
Semántica: Integración e Interoperabilidad y Desarrollo.
Saas: Proyectos de Software en la “Nube” (Cloud Computing).

¿Cuál cree que es la cualidad más importante que tiene que poseer un ingeniero de software?
Tesón.

¿ESA o Métrica v3?
ESA, no doubt!

Una vez casi finalizada la asignatura… ¿cuál es la panorámica que tiene del trabajo realizado por los alumnos este año?
Excelente, voluntad y esfuerzo, un grupo notable.

¿Qué consejo daría a los alumnos que están a punto de terminar la carrera y que se van a incorporar al mercado laboral?
Diferenciación. Ánimo. Pasión. Recordad dos palabras: SaaS y Cloud Computing.

Y la indiscreta… Si tuviera que recomendar una empresa, y sólo una, a un alumno recién licenciado, ¿cuál sería?
The Sky is the limit.

Reflexiones... Ángel García

2008-12-18T16:20:00.001+01:00

¿Cuál considera que es el factor que más influye en el éxito de un proyecto software?
Una correcta gestión de los riesgos.

¿Qué factor cree que es el más crítico, el más complejo de gestionar?
El personal.

Motivación… ¿Cree que un Ingeniero de Software trabaja más y mejor si está motivado o piensa que ha de realizar su trabajo de la mejor manera posible por el simple hecho de ser un profesional y porque le pagan por ello?
La motivación es pan para hoy, agua para mañana. Todos debemos hacer bien nuestro trabajo desde el primer momento, nos pagan para ello, a nadie le gusta que otro, al que paga (un camarero p.e) haga mal su trabajo (derramando la cerveza p.e.).

Nuevos horizontes… ¿Hacia dónde va la ingeniería del software? ¿Cuál es el paradigma del futuro?
Hacía la gestión de procesos.

¿Cuál cree que es la cualidad más importante que tiene que poseer un ingeniero de software?
Ser una persona honesta.

¿ESA o Métrica v3?
Jarrrrllll, ninguna en particular, cualquiera es buena si se utiliza bien o mala si se utiliza mal.

Una vez casi finalizada la asignatura… ¿cuál es la panorámica que tiene del trabajo realizado por los alumnos este año?
Excelente.

¿Qué consejo daría a los alumnos que están a punto de terminar la carrera y que se van a incorporar al mercado laboral?
Primero que terminen el proyecto fin de carrera y que sean siempre ingenieros, es decir, que se dediquen a resolver problemas.

Y la indiscreta… Si tuviera que recomendar una empresa, y sólo una, a un alumno recién licenciado, ¿cuál sería?
Cualquiera, en todos los lados cuecen habas, jajajajaja. Pero yo elegiría una con potencial de crecimiento, que estuviera en un buen sector y no en un sector estancado.

Reflexiones... Ricardo Colomo

2008-12-18T16:19:00.001+01:00

¿Cuál considera que es el factor que más influye en el éxito de un proyecto software?
El personal.

¿Qué factor cree que es el más crítico, el más complejo de gestionar?
El personal.

Motivación… ¿Cree que un Ingeniero de Software trabaja más y mejor si está motivado o piensa que ha de realizar su trabajo de la mejor manera posible por el simple hecho de ser un profesional y porque le pagan por ello?
Los trabajadores del conocimiento, como los Ingenieros de Software necesitan motivación intrínseca y extrínseca para llevar a cabo su trabajo.

Nuevos horizontes… ¿Hacia dónde va la ingeniería del software? ¿Cuál es el paradigma del futuro?
Es difícil de precisar. Desde el punto de vista de las personas quiero creer que a la innovación continua en las formas de trabajo y en las relaciones entre los integrantes de proyectos de desarrollo de software.

¿Cuál cree que es la cualidad más importante que tiene que poseer un ingeniero de software?
La de cualquier otra persona: honestidad.

¿ESA o Métrica v3?
Respuesta típica: depende.

Una vez casi finalizada la asignatura… ¿cuál es la panorámica que tiene del trabajo realizado por los alumnos este año?
El capital humano de los alumnos de la UC3M es inmejorable. En potencia representan una visión del futuro más que alentadora. En acto, han cumplido con mis expectativas: calidad de compromiso.

¿Qué consejo daría a los alumnos que están a punto de terminar la carrera y que se van a incorporar al mercado laboral?
Que nunca dejen de formarse.

Y la indiscreta… Si tuviera que recomendar una empresa, y sólo una, a un alumno recién licenciado, ¿cuál sería?
La Universidad Carlos III de Madrid.

Reflexiones...

2008-12-18T16:12:00.003+01:00

Los siguientes post están pensados para que los profesores de la asignatura puedan darnos una opinión personal sobre distintos aspectos relativos con la Ingeniería del Software que, en otro marco, sería más complejo expresar.

Esperamos que os resulten entretenidas y que los consejos que en ellos se muestran os sean de utilidad en un futuro no muy próximo.

¡Mucho ánimo con el último empujoncillo!

La fase de Diseño desde un punto de vista Dual

2008-12-18T10:17:00.002+01:00

En este proyecto, como en prácticamente todo el que se precie, hemos tenido que desarrollar el diseño del Sistema que nos ocupa. En este caso, nos hemos basado en la metodología Métrica v3 del Ministerio de Administraciones Públicas, pero perfectamente se podría haber empleado otro estándar, como el de la Agencia Espacial Europea (ESA).

Aquí lo que queremos es mostraros también otro enfoque de la fase de diseño, visualizándolo desde la parte del negocio, desde el punto de vista organizacional, donde se tienen en cuenta más los procesos de negocio que se ven implicados que los de la propia creación de la arquitectura del sistema de información que se va a desarrollar.

El esquema que veréis a continuación presenta ambos paradigmas. Uno, el tecnológico, pasado por el filtro de las metodologías Métrica v3 y ESA, y el otro, el de negocio, empleando estándares de Gestión de Proyectos como PMBOK e ITIL, de los que ya hemos hablado en entradas anteriores.

Como veis, ofrece una visión dual, la izquierda, con todas las fases, digamos tecnológicas, requeridas para el diseño del sistema de información, y por otra los procesos y productos de negocio que intervienen y que se generan en esta parte del proyecto software.

Esperamos que os resulte interesante tal comparación, sobre todo porque nosotros estamos acostumbrados a enfocarlo todo desde el primer punto de vista, cuando en realidad son múltiples los factores del segundo que participan y resultan críticos en él.

(Pincha encima para ampliar)

Otro estándar para la Gestión de Proyectos... ITIL v3 (II)

2008-12-17T09:48:00.005+01:00

Vamos a continuar el post anterior, entrando a comentar un poco cuál es la estructura de ITIL y cuáles son los libros que lo componen.

Aunque el tema de Gestión de Servicios (Soporte al Servicio y Entrega de Servicios) es el más ampliamente difundido e implementado, el conjunto de mejores prácticas ITIL provee un conjunto completo de prácticas que abarca no sólo los procesos y requerimientos técnicos y operacionales, sino que se relaciona con la gestión estratégica, la gestión de operaciones y la gestión financiera de una organización moderna.

Los ocho libros de ITIL y sus temas son:

Gestión de Servicios de TI:
1. Prestación de Servicios.

2. Soporte al Servicio.

Otras guías operativas:
3. Gestión de la infraestructura de TI.
4. Gestión de la seguridad.
5. Perspectiva de negocio.
6. Gestión de aplicaciones.
7. Gestión de activos de software.

Para asistir en la implementación de prácticas ITIL, se publicó un libro adicional con guías de implementación:
8. Planeando implementar la Gestión de Servicios.

Adicional a los ocho libros originales, más recientemente se añadió una guía con recomendaciones para departamentos de TI más pequeños:
9. Implementación de ITIL a pequeña escala.

Las principales ventajas que ofrece la implantación/uso de ITIL para las organizaciones son:

La organización TI desarrolla una estructura más clara, se vuelve más eficaz, y se centra más en los objetivos corporativos.
La administración tiene más control y los cambios resultan más fáciles de manejar.
Una estructura de proceso eficaz brinda un marco para concretar de manera más eficaz el outsourcing de los elementos de los servicios TI.
Seguir las mejores prácticas de ITIL alienta el cambio cultural hacia la provisión de servicio, proporcionando una introducción en un sistema de administración de la calidad.
ITIL establece un marco de referencia para la comunicación interna y la comunicación con los proveedores, como así también la estandarización y la identificación de los procedimientos.

Otro estándar para la Gestión de Proyectos... ITIL v3 (I)

2008-12-17T09:43:00.005+01:00

En anteriores post ya hicimos referencia a distintas metodologías para la Gestión de Proyectos, como PMBOK. Hoy vamos a contaros algo acerca de otro de los estándares más empleados en este área de conocimiento: ITIL.

La Biblioteca de Infraestructura de Tecnologías de Información (Information Technology Infrastructure Library), es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de Tecnologías de la Información (TI) desarrollada por el ITSMF (IT Service Management Forum). ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.

ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:

Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos.
El establecimiento de estrategias para la gestión operativa de la infraestructura TI.

Los objetivos de una buena gestión de servicios TI han de ser:

Proporcionar una adecuada gestión de la calidad.
Aumentar la eficiencia.
Alinear los procesos de negocio y la infraestructura TI.
Reducir los riesgos asociados a los Servicios TI.
Generar negocio.

En su concepción inicial, ITIL constaba de 10 libros centrales cubriendo las dos principales áreas de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30 libros complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del negocio. En ITIL v3 se acometió una reestructuración para simplificar el acceso a la información necesaria para administrar sus servicios, estableciendo finalmente la existencia de 8 libros. Los libros centrales se han agrupado en dos, cubriendo las áreas de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la duplicidad y mejorar la navegación. El material ha sido también actualizado y revisado para un enfoque conciso y claro.

Ya se ve la luz...

2008-12-17T00:15:00.003+01:00

Pues sí, se acerca el final... El Histórico, un par de cambios en el Documento de Diseño, en el de Pruebas y en el de Implantación y podremos decir que todo ha terminado...

...todas esas noches en vela...
todos esos documentos de Word...
todas esas líneas tecleadas...
todos esos diagramas UML...
todos esos "retoques" con el Paint...
todos esos gabinetes de crisis...
todos esos "jaaaaaaaaaaaaaarl"...
todos esos cigarritos...
todos esos documentos tirados...
todos esos requisitos...
todos esos recuentos de horas(¬¬)...
todos esos céntimos de la oferta...
todos esos documentos sin nombre definido...
o con él equivocado...
todas esas interfaces...
todos esos métodos que no sabemos ni qué hacen...
todas las dioptrias que hemos perdido delante del ordenador...
todos esos fallos ortográficos...
todas esas patadas al diccionario...
todas esas definiciones para explicar bien los requisitos...
todas esas descripciones de métodos...
todas esas idas de olla...
todas esas risas...
todas esas frases perdidas en un universo paralelo...
todas esas "de manera correcta" o "que lo haga bien"...
todas esas cosas que sabemos que están mal y no nos han detectado...
todos esos "El documento X está aprobado"...
... todo esto y mucho más ...

Reflexiones sobre la Evaluación 360º

2008-12-16T23:59:00.002+01:00

Y por fin llegó el gran día... Ese día con el que ¿todos? soñábamos... El día en que ajustaríamos cuentas con nuestros maravillosos compañeros de proyecto que tantas y tantas gloriosas noches nos han hecho pasar... El día de la Evaluación 360º.

Básicamente este método de valoración consiste en puntuar, en diversas facetas, el trabajo de tus compañeros de grupo, incluyendo también una puntuación de uno mismo, (guay! nos podemos inflar la nota), hecho que carece de relevancia si nuestra nota no es similar a la que nos han otorgado los demás componentes del equipo.

Este es un arma de doble filo, pues por un lado lo ves como un mecanismo de venganza, pero por otro has de ser consciente que, en casi todos los casos, la gente ha trabajado mucho para sacar el proyecto adelante y que, por algo tan baladí como simples discrepancias personales, no puedes enviar todas esas horas y esfuerzo a la basura.

Por otro lado el sistema de evaluación global hace que una nota disacorde con las demás sea muy poco significativa, con lo cual, por tí mismo no vas a lograr ni cargarte ni enaltecer a nadie; ello implica que la responsabilidad y la reflexión acerca del voto sea algo muy a tener en cuenta y a evaluar muy detenidamente.

Con todo y con ello creo que, al menos en nuestro grupo, el resultado ha sido (toquemos madera) muy satisfactorio, pues hemos trabajado todos bastante bien y, a pesar de pequeños baches totalmente salvables, hemos sido capaces de sacar esto adelante sin tirarnos los trastos a la cabeza.

PD: Sí, somos de los pocos que lo podemos afirmar y estamos orgullosos de ello, a pesar de IS3, seguimos siendo coleguillas...

La Reingeniería de Procesos

2008-12-16T01:50:00.003+01:00

Este post pretende dar una visión global de lo que es uno de los paradigmas con más calado en el mundo empresarial actual.

La reingeniería se puede entender como la reconcepción fundamental y el rediseño radical de los procesos de negocio para lograr mejoras dramáticas en medidas de desempeño tales como en costos, calidad, servicio y rapidez.

Otra aproximación similar podría ser que constituye una recreación y reconfiguración de las actividades y procesos de la empresa, lo cual implica volver a crear y configurar de manera radical él o los sistemas de la compañía a los efectos de lograr incrementos significativos, y en un corto período de tiempo, en materia de rentabilidad, productividad, tiempo de respuesta, y calidad, lo cual implica la obtención de ventajas competitivas.

Tal y como se contempla en ambas definiciones, la reingeniería está orientada a los procesos, no a las tareas, de la forma en que un proceso se describe como un conjunto de tareas, actividades o acciones interrelacionadas entre sí que, a partir de una o varias entradas de información, materiales o de salidas de otros procesos, dan lugar a una o varias salidas también de materiales (productos) o información con un valor añadido.

El punto de partida para el éxito organizacional es tener procesos bien diseñados. El rediseño es un factor inherente a la reingeniería. Por contra, la principal advertencia de la reingeniería es que si uno no está convencido de llevarla a cabo o de sus bondades, lo mejor es ni siquiera empezar el cambio, porque entonces podemos quedarnos en el peor de ambos mundos.

Este paradigma no presenta modelos o metodologías de desarrollo, sino que cada ingenierio tiene que hacer su propio proyecto. Bien es cierto que sí existen una serie de pautas o principios de índole universal que son susceptibles de ser aplicados en la práctica totalidad de las organizaciones, al igual que se puede emplear la experiencia como factor clave para guiar este tipo de proyectos.

Así mismo se pueden establecer un conjunto de etapas que sí son comunes a todos los proyectos de reingeniería:

Preparación: Definir las metas y los objetivos estratégicos que justifiquen la reingeniería y los vínculos entre los resultados de la reingeniería y los resultados de la organización.
Identificación: El propósito de esta etapa es el desarrollo de un modelo orientado al cliente, identifica procesos específicos y que agregan valor. Aquí se incluye la definición de clientes, procesos, rendimiento, éxito, recursos, etc. Además requiere un conocimiento profundo de toda la empresa y sus procesos.
Visión: El propósito de esta etapa es desarrollar una visión del proceso capaz de producir un avance decisivo en rendimiento. La visión del nuevo proceso debe ser comprensible para todo el personal, describir las características primarias del proceso, debe ser motivadora e inspiradora
Solución: En esta etapa se produce un diseño técnico y un diseño cultural-organizacional de la empresa. El diseño social necesariamente debe ser realizado al mismo tiempo que el técnico, pues para que un proceso sea eficaz, estos diseños deben ser congruentes.
Transformación: El propósito de esta etapa es realizar la visión del proceso implementando el diseño de la etapa 4.

Por último, vamos a enumerar los trece principios básicos según los que se rige la reingeniería:

Consiste en empezar de cero, en una hoja en blanco: se considera que todo lo anterior estaba mal hecho, en base a los resultados obtenidos.
Consiste en cambios radicales, brutales, espectaculares: cambios de 100%, no de cambios incrementales de 20 o 30%.
Está enfocada a procesos, no a departamentos o áreas, trabajos, personas o estructuras.
Tiene una visión global, viendo los procesos desde una perspectiva integral.
La división del trabajo ya no funciona, no se trabaja en serie, sino de forma integrada y dinámica. Los actores han de ser capaces de desempeñar más de un rol.
Es enemiga de la especialización. Es multiespecialización (generalista), pues lo contrario lleva a la pérdida de flexibilidad.
Se apoya en el principio de la incertidumbre (Teoría del Caos): se basa en la intuición y en el supuesto de que no existe nada establecido ni predeterminado.
Su herramienta principal es la destrucción creativa: lo anterior ya no funciona y por lo tanto hay que destruirlo, pero de una manera creativa, construyendo los nuevos procesos.
No hay un "modelo de reingeniería": cada uno tiene que hacer su propio proyecto de reingeniería.
Lo más importante es un cambio de mentalidad o de enfoque: no debemos pensar en tareas aisladas, sino en procesos integrados.
En un primer momento debe realizarse de arriba hacia abajo: iniciado por el gerente de la organización, dado que si no se canalizan poder y recursos no prosperará.
En un segundo momento, la reingeniería requiere un impulso en sentido inverso, de abajo hacia arriba: si no involucra a todos los miembros de la organización fracasará, porque estos lo boicotearán, lo sabotearán o lo harán más lento.
Si uno no está convencido es mejor no hacer reingeniería: los resultados pueden ser desastrosos, ya que se desmantelaría lo que funcionaba en el pasado y no se acabaría de instalar los nuevos procesos.

Teorías de la Motivación (II)

2008-12-16T00:24:00.011+01:00

Como continuación del post anterior, vamos a seguir enumerando dos teorías más que presentan otro enfoque para el mismo problema.

Pirámide de Maslow

Esta teoría se basa en las necesidades que atañen a todo individuo y que se encuentran organizadas de forma estructural (como una pirámide), de acuerdo a una determinación biológica causada por la constitución genética del individuo. En la parte más baja de la estructura se ubican las necesidades más prioritarias y en la superior las de menos prioridad.

Así pues, dentro de esta estructura, al ser satisfechas las necesidades de determinado nivel, el individuo no se torna apático sino que más bien encuentra en las necesidades del siguiente nivel su meta próxima de satisfacción. Aquí subyace la falla de la teoría, ya que el ser humano siempre quiere más y esto está dentro de su naturaleza.

Maslow enunció que es cierto que el hombre vive solamente para el pan, cuando no hay pan. Pero ¿qué ocurre con los deseos del hombre cuando hay un montón de pan y cuando tiene la tripa llena crónicamente?.

Las necesidades según Maslow:

Necesidades fisiológicas: estas necesidades constituyen la primera prioridad del individuo y se encuentran relacionadas con su supervivencia (alimentación, el saciar la sed, el mantenimiento de una temperatura corporal adecuada, el sexo, etc.).
Necesidades de seguridad: con su satisfacción se busca la creación y mantenimiento de un estado de orden y seguridad (la necesidad de estabilidad, la de tener orden y la de tener protección, etc., nececesidades todas ligadas al miedo).
Necesidades sociales: una vez satisfechas las necesidades fisiológicas y de seguridad, la motivación se da por las necesidades sociales. Estas tienen relación con la necesidad de compañía del ser humano, con su aspecto afectivo y su participación social (comunicación con otras personas, amistad, manifestar y recibir afecto, pertenecer a un grupo y ser aceptado en él, etc.).
Necesidades de reconocimiento: también conocidas como las necesidades del ego o de la autoestima. Este grupo radica en la necesidad de toda persona de sentirse apreciado, tener prestigio y destacar dentro de su grupo social, de igual manera se incluyen la autovaloración y el respeto a sí mismo.
Necesidades de auto-superación: también conocidas como de autorrealización o autoactualización, que se convierten en el ideal para cada individuo. En este nivel el ser humano requiere trascender, dejar huella, realizar su propia obra, desarrollar su talento al máximo.

Factores de Herzberg

Esta teoría se basa en la creencia de que la relación que un individuo tiene con su trabajo es básica, y que su actitud hacia el mismo bien puede determinar su éxito o fracaso.

Su línea de investigación se basa en una simple cuestión: "¿Qué desea la gente de sus puestos?". En función de ella se estudió el comportamiento de distintos individuos, que expusieron pormenorizadamente todas las situaciones que determinaban un factor positivo o negativo en relación con sus puestos de trabajo.

Por el análisis de las contestaciones, Herzberg llegó a la conclusión de que las respuestas que la gente daba cuando se sentía mal. Factores intrínsecos, como logros, reconocimiento y responsabilidad, se relacionaron con la satisfacción con el puesto. Así mismo enunció que los factores que llevan a la satisfacción con el puesto se les separa y son diferentes a los que conducen a la insatisfacción con el puesto. Por tanto, los administradores que procuran eliminar los factores creadores de la insatisfacción con el puesto puede traer paz, pero no es necesario que sea la motivación, y bajo esta condición sólo aplacan a su fuerza laboral en lugar de motivarla. Herzberg caracterizó a los factores que crean la insatisfacción con el puesto como factores de higiene. Cuando estos factores son adecuados, la gente no estará insatisfecha; sin embargo, tampoco estará satisfecha. Para motivar a las personas en sus puestos, Herzberg sugirió la enfatización de motivadores, aquellos factores que aumentan la satisfacción con el puesto.

Los principales puntos en lo que ha sido criticada esta teoría han sido:

Cuando las cosas van bien, la gente tiende a tomar el crédito para sí mismos. Culpan a los factores externos de los fracasos.
Es dudosa la confianza que pueda tener la metodología de Herzberg, puesto que los calificadores tenían que hacer interpretaciones podría ser que contaminaran sus hallazgos al interpretar una respuesta en una forma y otra similar en forma muy distinta
No se utilizó una medida global de satisfacción. Una persona puede estar incómoda con parte de su puesto, y, sin embargo, pensar que es aceptable.

Esta teoría supone que existe una relación entre satisfacción y productividad, pero en realidad su investigación sólo se focalizó en la primera. Su talón de Aquiles radica precisamente en esto, en que se ha de presuponer que existe esta relación, y que es muy estrecha.

Finalmente se puede concluir globalmente que la autoestima es el sentimiento valorativo de nuestro ser, de nuestra personalidad, y ese es precisamente el factor que se ha de potenciar y enaltecer con la motivación, pues no sólo depende de uno mismo sino también del ambiente social, de trabajo y de los estímulos que ellos nos brindan.

Teorías de la Motivación (I)

2008-12-16T00:16:00.006+01:00

Hace ya un tiempo hablamos de la importancia que tiene la motivación en los equipos de trabajo, y de lo complejo que es mantener al grupo con ganas e ilusión por el trabajo de forma (casi)permanente. Hoy vamos a contaros algo sobre las distintas técnicas o escuelas existentes en este ámbito, explicando en qué se centra cada una y qué aporta de relevante frente a las demás.

Teorema de Taylor

Taylor fue uno de los más destacados promotores de la dirección científica del trabajo, fijando las reglas que permitían aumentar el rendimiento de las máquinas y herramientas. Se trata del primer autor que propone una organización del trabajo y que habla sobre la motivación .

Taylor propone una serie de acciones para incrementar la productividad:

Crear recompensas económicas
Contratación de trabajadores hábiles y diestros.
Realización de un análisis científico; estudiar las tareas detalladamente, su tiempo de ejecución,etc.

Teorema X-Y de McGregor

Douglas McGregor desarrolló en dos teorías, la X y la Y, en la que enunciaba que los directivos de la primera consideran a sus subordinados como animales de trabajo que sólo se mueven ante el yugo o la amenaza, mientras que los directivos de la segunda se basan en el principio de que la gente quiere y necesita trabajar.

Teoría X

El ser humano ordinario siente una repugnancia intrínseca hacia el trabajo y lo evitará siempre que pueda.
Debido a ello, la mayor parte de las personas tiene que ser obligadas a trabajar por la fuerza, controladas, dirigidas y amenazadas con castigos para que desarrollen el esfuerzo adecuado a la realización de los objetivos de la organización.
El ser humano común prefiere que lo dirijan; quiere soslayar responsabilidades, tiene relativamente poca ambición y desea más que nada su seguridad.

Teoría Y

El desarrollo del esfuerzo físico y mental en el trabajo es tan natural como el juego o el descanso. Al ser humano común no le disgusta esencialmente trabajar.
El control externo y la amenaza de castigo no son los únicos medios de encauzar el esfuerzo humano hacia los objetivos de la organización, el hombre debe dirigirse y controlarse a sí mismo en servicio de los objetivos a cuya realización se compromete.
Se compromete a la realización de los objetivos de la empresa por las compensaciones asociadas con su logro.
El ser humano ordinario se habitúa a buscar responsabilidades. La falta de ambición y la insistencia en la seguridad son, generalmente, consecuencias de la misma experiencia y no características esencialmente humanas.
La capacidad de desarrollar en grado relativamente alto la imaginación, el ingenio y la capacidad creadora para resolver los problemas de la organización, es característica de grandes sectores de la población.
En las condiciones actuales de la vida industrial las potencialidades intelectuales del ser humano están siendo utilizadas sólo en parte.

¿Qué teoría es más acertada? Es cierto que la X se puede considerar obsoleta, pero bien es cierto que está presente todavía en muchas corrientes directivas. Si bien el autor propone la adopción de la Teoría Y para aumentar la motivación de los empleados.

En el siguiente post continuaremos comentando más teorías sobre algo aparentemente tan trivial como es la motivación, pero que representa uno de los mayores problemas en la Gestión de Proyectos.

Recomendaciones para las Pruebas

2008-12-15T23:52:00.004+01:00

Al igual que hicimos en fases anteriores del Proyecto, vamos a daros un par de apuntes sobre las pruebas del sistema, así como dejaros alguna impresión o consejo que os pueda ser útil a la hora de realizar este documento.

La creación y realización de las pruebas del sistema, es una de las partes más importantes en cualquier proceso de desarrollo software ya que probar una aplicación supone generar casos de prueba, ejecutarlos en la aplicación y observar su comportamiento, de manera que podamos determinar su correcto funcionamiento. Cuando un producto software se comporta de manera incorrecta durante la realización de las pruebas, el ingeniero encargado de realizar las mismas, sabe que necesita ser depurada para determinar la causa y dicha depuración nos ayuda a identificar y corregir los errores de la aplicación.

La generación manual de los casos de prueba puede consumir bastante tiempo, y la fase de pruebas del software ha llegado a ser una de las más caras del ciclo de vida ya que la realización de las mismas cuesta entre un 40 y un 75 por ciento del tiempo de las fases de desarrollo y mantenimiento del ciclo de vida software. A pesar de esto, las pruebas software han sido la técnica más usada para asegurar la calidad del software.

Como consejo particular, cuando vayas a realizar el documento de pruebas del sistema, lo primero que debes hacer es conocer bien para qué sirve la aplicación y cómo va a llevar a cabo cada una de sus funcionalidades, ya que gracias a este conocimiento serás capaz de partir de una serie de pruebas específicas y unitarias para cada módulo individualmente (de manera que acotes más los errores) para después pasar a realizar las pruebas de integración, que te permitirán comprobar el correcto funcionamiento conjunto de los módulos de la aplicación. Las pruebas de aceptación y del sistema, son pruebas más completas en las que se prueba el producto software en su totalidad, comprobando su correcto funcionamiento y la consecución de los requisitos establecidos por el cliente.

Esperemos que superemos con éxito también esta fase, la última realmente dura del proyecto, que cada vez toca más a su fin... ¡Ánimo!

Un estándar para el gobierno de los Sistemas de Información: COBIT

2008-12-15T23:11:00.008+01:00

Hemos hablado en post previos acerca de estándares para la Gestión de Proyectos, pero en los últimos años ha aparecido un nuevo modelo para el control y administración de los mismos y que supone una pequeña antítesis a PMBOK y similares, COBIT.

COBIT (Control OBjectives for Information and related Technology u Objetivos de Control para tecnología de la información y relacionada) es un modelo para el Gobierno de la TI desarrollado por la Information Systems Audit and Control Association (ISACA) y el IT Governance Institute (ITGI), y cuyo principal objetivo consiste en proporcionar una guía a alto nivel sobre puntos en los que establecer controles internos con tal de:

Asegurar el buen gobierno, protegiendo los intereses de los stakeholders (clientes, accionistas, empleados, etc.).
Garantizar el cumplimiento normativo del sector al que pertenezca la organización.
Mejorar la eficacia y eficiencia de los procesos y actividades de la organización.
Garantizar la confidencialidad, integridad y disponibilidad de la información.

El estándar define el término control como: "políticas, procedimientos, prácticas y estructuras organizacionales diseñadas para proveer aseguramiento razonable de que se lograrán los objetivos del negocio y se prevendrán, detectarán y corregirán los eventos no deseables", por lo que abarca desde aspectos organizativos (p.ej. flujo para pedir autorización a determinada información, procedimiento para reportar incidencias, selección de proveedores, etc.) hasta aspectos más tecnológicos y automáticos (p.ej. control de acceso a los sistemas, monitorización de los sistemas mediante herramientas automatizadas, etc.).

Obviamente todo control tiene, por naturaleza, un objetivo, es decir el resultado deseable de una acción. En este caso, COBIT presenta 34 objetivos de nivel altos que cubren 215 objetivos de control clasificados en cuatro dominios: Planifica y Organiza, Adquiere y Pone en práctica, Entrega y Apoya, y Supervisa y Evalúa. Estos mismos dominios son los empleados para la clasificación de los procesos de negocio relacionados con las TI:

Planificación y Organización
Adquisición e Implementación
Entrega y Soporte
Supervisión y Evaluación

En definitiva, cada dominio contiene procesos de negocio (desglosables en actividades) para los cuales se pueden establecer objetivos de control e implementar controles organizativos o automatizados:

Por otra parte, la organización dispone de recursos (aplicaciones, información, infraestructura y personas) que son utilizados por los procesos para cubrir los requisitos del negocio:

Efectividad (cumplimiento de objetivos).
Eficiencia (consecución de los objetivos con el máximo aprovechamiento de los recursos).
Confidencialidad.
Integridad.
Disponibilidad.
Cumplimiento regulatorio.
Fiabilidad.

Para finalizar, este estándar proporciona una serie de directrices a alto nivel para la definición y evaluación de todos los procesos de negocio relativos a los Sistemas de Información, compatibilizando su uso con otras guías o cuerpos de conocimiento más específicos (CMM, ITIL,...).

IQS4 o cuando la desviación ya no es tal

2008-12-14T17:33:00.005+01:00

Una vez efectuado el último Informe de Seguimiento, y analizando el gráfico de recursos acumulados, vemos que esa gran desviación que se producía en los primeros compases del proyecto ya no es tal, que los recursos estimados y los reales son muy parejos y que esa gran ganancia que presumíamos que íbamos a tener se ve reduciendo conforme avanzan las semanas.

Actualmente el número de horas reales dedicadas al desarrollo del proyecto es de 685, frente a las 743 que se planificaron para el proyecto total, es decir, se presenta una desviación de 58 horas, algo que, si bien no se llegará a cubrir con el Documento Histórico del Proyecto, sí que va mermando, sobre todo si la comparamos con las desviaciones relativas de los dos primeros Informes, el beneficio que se presuponía al proyecto.

Los principales factores que han causado esta compensanción del esfuerzo han sido:

Cambios en el Diseño que afectan a documentos previos (principalmente al Análisis).
Modificaciones en el propio Análisis que han conllevado alteraciones del Diseño, como identificación o variación de Requisitos o de Casos de Uso.
Descubrimiento de nuevas funcionalidades de la aplicación que ha sido necesario reflejar.
Errores propios del Diseño, como consecuencia de la inexperiencia en proyectos de este tamaño.
Falta de cohesión entre unas partes y otras, ya que al trabajar en paralelo muchas veces se comenten errores de coordinación que se arrastran durante toda la fase.
Subestimación de la magnitud del propio Documento de Diseño, pues no considerábamos a priori que era tan denso y que requería de tal nivel de detalle.

Cuando tengamos los datos finales arrojados por el Histórico del Proyecto ya los comentaremos para ver cuál ha sido la cuantía de nuestro beneficio; esperemos que esto no siga decreciendo...

Los Patrones de Diseño Web

2008-12-11T00:34:00.005+01:00

Hemos hablado mucho sober patrones de diseño sober la lógica de negocio, sobre la base de las aplicaciones, pero también existen una serie de patrones destinados a diseñar de una forma atractiva y usable los sitios web.

Los patrones documentan una solución a un problema recurrente, de tal manera que no sólo dejan constancia de esa experiencia en un formato simple y comprensible, sino que posibilitan la reutilización de la misma experiencia una y otra vez en diferentes aplicaciones.

En este caso, existen trece grupos, cada uno enfocado a una función particular (por ejemplo, la Homepage), y en cuyo seno albergan una serie de patrones con una funcionalidad mucho más específica.

Estos grupos son:

A - Site Genres: Dan pautas sobre cómo captar consumidores en función de la finalidad del negocio que alberga el sitio.
B - Creating a Navigation Framework: Guía sobre cómo implementar la navegabilidad, compatibilidad con navegadores y estrategias de búsqueda.
C - Creating a Powerful Homepage: La página principal es la más importante del sitio web, aquí se explica cómo optimizarla.
D - Writing & Managing Content: Habla de otras estrategias para captar seguidores además de a través del Homepage.
E - Building Trust & Credibility: Ofrece soluciones para un factor tan crítico como es el ganarse la confianza y la credibilidad de los usuarios.
F - Basic E-Commerce: Proporciona una senda para hacer el portal profesional y atractivo a los clientes.
G - Advanced E-Commerce: Similar al anterior, pero más profesional si cabe, para buscar nuevas oportunidades de negocio.
H - Helping Customers Complete Tasks: Patrones o guías para estructurar el sitio web para facilitar la realización de las tareas a los usuarios.
I - Designing Effective Page Layouts: Describe cómo organizar de forma correcta las distintas partes del sitio web.
J - Making Site Search Fast & Relevant: Indica cómo diseñar el sitio de tal forma que las búsquedas sean más efectivas.
K - Making Navigation Easy: Técnicas para mostrar y organizar los elementos de navegación de forma sencilla, para encontrarlos fácilmente.
L - Speeding Up Your Site: Guía cómo hacer una página lo más rápida posible, con el fin de no perder usuarios por la lentitud de carga.
M - The Mobile Web: Cómo optimizar la página para adaptarla a navegadores móviles y a la gente que los utiliza.

Como veis ofrecen múltiples soluciones para problemas muy concretos. Si queréis saber más, consultad el libro "The Design of Sites", de Van Duyne, Landay y Hong, donde detallan los distintos patrones, el problema que pretenden resolver y cómo lo hacen; es realmente interesante.

La importancia de... encontrar la información oculta en la red

2008-12-09T23:23:00.007+01:00

Casi seguro que alguna vez habéis oido hablar de Data Mining o Minería de Datos, que no es más que el estudio y análisis de grandes fuentes de información para encontrar patrones o datos ocultos, que a primera vista no se aprecian, con el fin lograr mejoras en algún proceso determinado.

El crecimiento de la información que se encuentra en la web ha sido exponencial debido a la necesidad de los usuarios de contar con datos. La información de la web es finita pero el número de páginas web es infinita. Actualmente existen alrededor de 4 mil millones de páginas estáticas, es decir la información que poseen los buscadores web, pero sin embargo es importante mencionar que la mayoría de las páginas web no son dinámicas, es decir son aquellas que se generan automáticamente con datos extraídos de bases de datos.

Existen diferentes problemas a los que se enfrentan los usuarios debido al crecimiento exponencial. Uno de esos problemas es el que representa encontrar información relevante.

La Web Mining se define como el uso de técnicas para descubrir y extraer de forma automática información de documentos y servicios web. La Web Mining es el proceso de descubrir y analizar información “útil” de los documentos de la Web. Se puede definir como el descubrimiento y análisis de información relevante que involucra el uso de técnicas y acercamientos basados en la minería de datos (Data Mining) orientados al descubrimiento y extracción automática de información de documentos y servicios de la Web, teniendo en consideración el comportamiento y preferencias del usuario.

En la web mining, los datos pueden ser recolectados en diferente niveles; en el área del servidor, en el lado del cliente, en los servidores proxys, etc. El proceso general de web mining es el siguiente:

Recuperación de Información: Nos referimos básicamente al proceso de descubrimiento automático de documentos relevantes de acuerdo a una cierta búsqueda. Estos documentos relevantes pueden ser noticias electrónicas, newsgroups, newswires, contenido de las html, etc.
Extracción de Información: Tiene como objetivo transformar los documentos extraídos en el proceso de recuperación de información, en documentos que sean más fáciles de leer y de analizar.
Generalización: Reconocimiento de Patrones generales de una página en particular o bien también patrones de diferentes páginas.
Análisis: Una vez que los patrones han sido identificados, la parte humana juega un papel importante haciendo uso de herramientas adecuadas para entender, visualizar e interpretar los patrones

El proceso de web mining se divide en tres partes: la minería del uso (análisis de archivos de servidores Web, logs de acceso, logs de proxy, de navegador, sesiones, etc.), la minería del contenido (recogida de datos e identificación de patrones relativos a los contenidos de la web y a las búsquedas que se realizan sobre los mismos) y la minería de la estructura (revelar como están relacionados los hipervínculos entre las distintas páginas para generar un informe estructural sobre la página y el sitio web). En la figura siguiente se observa en detalle los pasos que utiliza cada tipo de minería en su proceso.

La importancia de... la Gestión del Conocimiento

2008-12-08T17:17:00.009+01:00

La Gestión del Conocimiento (del inglés Knowledge Management) es un concepto aplicado en las organizaciones, que pretende transferir el conocimiento y experiencia existente entre sus miembros, de modo que pueda ser utilizado como un recurso disponible para otros en la organización.

Engloba a un conjunto de políticas, estructuras organizativas, procedimientos, aplicaciones tecnológicas que persiguen mejorar la efectividad de la toma de decisiones de un grupo o una corporación. Usualmente el proceso requiere técnicas para capturar, organizar, almacenar el conocimiento de los trabajadores, para transformarlo en un activo intelectual que preste beneficios y se pueda compartir.

Es más que probable que el conocimiento de una empresa u organización sea uno de sus activos más importantes, con lo que su correcta administración es algo básico en un mercado tan voraz y feroz como el actual.

Esta disciplina pretende conseguir, a partir de una fuente de datos inicial, llegar al saber, de tal forma que éste pueda emplearse como ventaja competitiva en el mercado. Partiendo de los datos (elementos constitutivos del conocimiento, hechos, mediciones), se pretende llegar a la información (interpretación de los datos, de sus relaciones, su significado), de ahí al conocimiento (conceptualización de la información para resolver un problema) y, finalmente, al saber, que es el conocimiento aplicado, integrado y asimilado a través de la experiencia, y perfeccionado por la práctica y la madurez. Ello genera una agudeza especial frente a las situaciones que conllevan a la toma de decisiones altamente complicadas y cambiantes.

La mayoría de los esfuerzos comerciales de la administración del conocimiento han incluido la construcción de una cierta forma de memoria corporativa para capturar destreza, para apresurar el aprendizaje, para ayudar a la organización a recordar, para registrar el análisis razonado de la decisión, logros del documento o para aprender de los últimos errores.

Un estándar para el desarrollo del producto software: SWEBOK

2008-12-08T12:43:00.005+01:00

Hace algunos días escribíamos un post acercad del PMBOK, un estándar creado por el Project Management Institute para optimizar y guiar la Gestión de Proyectos. Hoy vamos a hablar de otro estándar, éste más enfocado a la Ingeniería del Software, y desarrollado por el IEEE: el SWEBOK.

SWEBOK (Software Engineering Body Of Knowledge) referencia al Cuerpo de Conocimiento de un campo tan complejo como es la Ingeniería del Software, es decir, a la descripción jerárquica del conocimiento de este área estructurado en dos niveles de jerarquía: áreas de conocimiento y componentes de conocimiento. Es un compendio de las mejores prácticas de este campo de la ingeniería con la finalidad de que sirvan como referencia a la hora del desarrollo de nuevos proyectos.

La idea de este desarrollo surgió basándose en que la Ingeniería del Software es una disciplina que poco o nada se parece a otras en la ciencia, por lo que es necesario definir un estándar o una guía para la mejora del proceso de creación de software. A diferencia de otros productos, el software se desarrolla, no se fabrica como cualquier otro objeto a partir de una materia prima, con un proceso de elaboración, etc., sino que es un producto de labores de ingeniería como análisis de requisitos, diseño, control de calidad,...

Las Áreas de Conocimiento en que se divide el SWEBOK son:

Requerimientos de Software: Un requerimiento es definido como una propiedad que debe ser exhibida para resolver algún problema del mundo real.
Diseño de Software: Es una fase que abarca todo el ciclo de vida de un producto software, pues se trata de la administración de los cambios, así como el mantenimiento de los requisitos, de tal forma que se refleje lo que en realidad el ítem final va a ser.
Construcción de Software: Implementación de un producto que sea funcional a través de la combinación de codificación, validación y pruebas unitarias.
Pruebas de Software: Verificación dinámica del comportamiento de un programa, sobre un conjunto finito de casos de prueba.
Mantenimiento de Software: Mejoras a implementar en el software una vez que está operativo, producto de anomalías, cambios en el ambiente operativo, nuevos requisitos, etc.
Gestión de la Configuración de Software: Proceso de de control de los cambios en el producto, con el fin de mantener la integridad en el ciclo de vida del mismo.
Gestión de la Ingeniería del Software: Administración de ciertos procesos complejos como la gestión de la organización, de los proyectos y de las métricas del software.
Procesos de Ingeniería del Software: Definición, implementación, medida y cambio de los procesos de ingeniería del software.
Métodos y herramientas de la Ingeniería del Software: Control del ambiente y métodos de desarrollo del software.
Calidad de Software: Consideraciones de calidad que trascienden los procesos del ciclo de vida.

(Pincha en la imagen para ampliarla)

Por último, aquí tenéis la página oficial de SWEBOK, donde os podréis descargar o simplemente consultar toda la documentación del estándar.

Herramientas para la gestión de Proyectos: Zoho Projects

2008-12-07T20:14:00.014+01:00

Os vamos a hablar hoy de una herramienta para la gestión de proyectos muy difundida y con una gran aceptación en la actualidad: Zoho Projects. Estamos hartos de oir hablar de lo compleja que es la gestión de un proyecto, de lo complicado que es coordinar a todos los miembros del equipo de trabajo, de la necesidad de un repositorio donde almacenar toda la documentación generada... Pues bien, esta herramienta permite hacer todo esto y mucho más de una forma sencilla, intuitiva y eficaz.

Así mismo ofrece control total para gestionar proyectos de cualquier tipo; permite asignar tareas a los miembros que se encuentren vinculados, junto con el plazo para que se lleven a cabo, llevar la cuenta de las acciones que ya se han realizado y lo que falta por hacer, o cargar archivos, entre otros. Una de las principales ventajas es que ofrece integración con las demás herramientas on-line de Zoho, como pueden ser procesadores de textos, hojas de cálculo, editor de Wikis, CRM, etc., lo cual proporciona un servicio muy completo para esta compleja tarea.

Entre sus principales funcionalidades están:

Definir tareas, permitiendo la actualización de las mismas en base a su progreso.
Definir listas de tareas, agrupando las más relevantes.
Establecer dependecias entre distintas tareas a realizar.
Establecer diferentes objetivos a alcanzar en el proyecto, para su gestión independiente.
Control del calendario, donde se reflejan las distintas tareas, hitos, entregables...
Gestión de toda la documentación generada en el proyecto, con un repositorio que es susceptible de clasificación.
Creación de distintas etiquetas para la clasifiticación de los documentos.
Gestión de subversiones de todos los productos que se van realizando.
Elaboración de diagramas de Gantt a partir de la planificación realizada.
Gestión de horas trabajadas, así como una herramienta para el control de este seguimiento.
Acceso concurrente a la aplicación, con partes privadas para los distintots usuarios.
Recibir notificaciones por correo electrónico cuando se asigne una tarea a un usuario o cuando la fecha de vencimiento se aproxime.
Clasificar a los miembros de un proyecto según sus papeles en el mismo.
Foro de discusión, donde se podrá hablar sobre distintos temas relacionados con el proyecto.

Por último, os vamos a dejar un enlace a un vídeo para que veáis cómo se utiliza la herramienta y evaluéis la practicidad y utilidad de la herramienta.

Herramientas para la gestión de las Pruebas del Sistema

2008-12-04T11:54:00.011+01:00

Ha llegado el momento de definir las pruebas que se realizarán para verficar y validar el sistema. En este post vamos a hablaros de una herramienta que facilita notablemente la realización de las pruebas definidas en el Documento de Pruebas del Sistema (o en el de Diseño del Sistema, según si se han integrado ambos o no) en entorno Java: JUnit.

Normalmente el conjunto de pruebas se realiza a partir de la especificación de lo que se espera de un programa, de ahí se pasa a preparar una batería de casos de prueba. Para programas pequeños (como solía venir siendo hasta ahora en nuestra carrera universitaria) éstos se pueden escribir en papel y ejecutarse disciplinadamente de forma manual, algo factible si se han de realizar, por decir una cifra, unos veinte tests. Pero si nos enfrentamos a un problema mucho más grande, con cientos de pruebas que llevar a cabo, es conveniente automatizar este proceso, de forma que se puedan realizar muchas veces, tanto durante la fase de desarrollo como durante la de aceptación.

JUnit es un framework que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Esto se refleja en la respuesta del mismo: en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, se devolverá un fallo en el procedimiento correspondiente.

El concepto fundamental en esta herramienta es el caso de prueba (test case), y la suite de prueba (test suite). Los casos de prueba son clases o módulos que disponen de métodos para probar los métodos de una clase o módulo concreta/o. Así, para cada clase que quisiéramos probar definiríamos su correspondiente clase de caso de prueba. Mediante las suites podemos organizar los casos de prueba, de forma que cada suite agrupa los casos de prueba de módulos que están funcionalmente relacionados.

Las pruebas que se van construyendo se estructuran así en forma de árbol, de modo que las hojas son los casos de prueba, y podemos ejecutar cualquier subárbol (suite) de forma recursiva.
De esta forma, construimos programas que sirven para probar nuestros módulos, y que podremos ejecutar de forma automática. A medida que la aplicación vaya avanzando, se dispondrá de un conjunto importante de casos de prueba, que servirá para hacer pruebas de regresión. Eso es importante, puesto que cuando cambiamos un módulo que ya ha sido probado, el cambio puede haber afectado a otros módulos, y sería necesario volver a ejecutar las pruebas para verificar que todo sigue funcionando. Esto último es básico en grandes sistemas donde la reingeniería es un proceso constante y se llevan a cabo múltiples modificaciones en el sistema, que pueden afectar al resto del mismo.

En la imagen anterior vemos un ejemplo de batería de pruebas realizado con JUnit, donde indica la cantidad de test realizados, los que fallan y los que son pasados con éxito.

Herramientas para la gestión del Acceso a Datos: Hibernate y DAO

2008-12-03T19:15:00.006+01:00

Existen múltiples estrategias o herramientas para optimizar el acceso a la capa de datos (Base de Datos) y mantener la persistencia objeto-relacional en una aplicación Web implementada con Java EE. Una de las más conocidas y extendidas es Hibernate.

Se trata de una herramienta de mapeo objeto-relacional que proporciona un framework para llevar a cabo esta operación de asociación entre dos paradigmas conceptualmente muy distintos, el orientado a objetos y el relacional. En el caso de enfrentarnos a un problema sencillo en el que los objetos no revisten una complejidad extrema, mantener la persistencia no es algo complejo, pero la cosa cambia cuando los objetos que queremos almacenar presentan una gran cantidad de atributos compuestos, asociaciones y agregaciones, donde se han de guardar numerosas referencias, con lo que el tamaño de los datos en el repositorio se incrementan de forma exponencial sin que ello suponga un beneficio global para el sistema.

Para lograr este mapeo, Hibernate, permite al desarrollador detallar cómo es su modelo de datos, qué relaciones existen y qué forma tienen. Con esta información, el mapeador faculta a la aplicación para manipular los datos de la base operando sobre objetos, con todas las características de la POO. Hibernate convertirá los datos entre los tipos utilizados por Java y los definidos por SQL. Hibernate genera las sentencias SQL y libera al desarrollador del
manejo manual de los datos que resultan de la ejecución de dichas sentencias, manteniendo la portabilidad entre todos los motores de bases de datos con un ligero incremento en el tiempo de ejecución.

Otra de las ventajas que aporta esta herramienta es que las relaciones son definidas una sola vez por el equipo de desarrollo y se almacenan en un fichero XML que es leido de forma directa por el propio mapeador, con lo que no es necesario estar constantemente indicando dónde va cada objeto o de qué tabla se ha de obtener qué dato.
Y la otra herramienta de la que queríamos hablar era del patrón de diseño de Java EE Data Access Object. Proporciona una interfaz común para el acceso a los datos, utilizando un Objeto como medio de acceso al repositorio físico. Esto permite abstraer y encapsular las operaciones relacionadas con el tratamiento de la propia BBDD.

La ventaja de usar objetos de acceso a datos es que cualquier objeto de negocio (aquel que contiene detalles específicos de operación o aplicación) no requiere conocimiento directo del destino final de la información que manipula. Ello implica que estos objetos se pueden emplear para hacer independiente la aplicaciónde la herramienta de persistencia que utilice (JDBC o incluso el propio Hibernate), con lo que la tecnología subyacente puede ser modificada sin
que las otras partes de la aplicación hayan de sufrir cambio alguno.

El principal inconveniente que presenta el uso de este patrón es que la complejidad de emplear otra capa intermedia adicional a la de persistencia incide en un aumento considerable del tamaño total del programa, lo cual repercute en el rendimiento del mismo, que decrecerá.

El Modelo de Capacidad y Madurez: CMM-CMMi

2008-12-03T01:33:00.005+01:00

Muchas veces hemos oído hablar del término madurez relacionado con la Ingenería del Software pero, realmente, ¿cómo se puede medir la madurez de un producto o empresa? Para dar respuesta a esta pregunta, surgió CMM.

CMM (Capability Maturity Model o Modelo de Capacidad y Madurez) es un modelo orientado a la mejora de los procesos empresariales, evaluando la calidad de los productos que desarrolla y clasificándolos según cinco niveles de madurez. Fue desarrollado por el SEI (Software Engineering Institute) a mediados de los años ochenta a petición del Departamento de Defensa de los Estados Unidos con la finalidad de evaluar a las distintas compañías que le proporcionan software. Este modelo está basado en conceptos de calidad total y de mejoramiento continuo.

CMMi (Capability Maturity Model Integration) es la evolución natural de CMM y surge con la intención de mejorar la usabilidad de los modelos de madurez integrando varios modelos diferentes en un solo framework. Así mismo describe las prácticas de ingeniería de software y gestión que permite a las organizaciones madurar sus procesos de desarrollo y mantenimiento del software, para cualquier proyecto en cualquier entorno. El CMMi presenta un conjunto de prácticas recomendadas en una serie de áreas clave que permiten mejorar el potencial del proceso de software. Abarca veintidós áreas de proceso, que van desde la Gestión de la Configuración y de los Requisitos hasta la Formación Organizacional, y se van concatenando en los distintos niveles de madurez.

CMMi, al igual que CMM presenta cinco niveles de madurez. Para poder estar en uno de ellos se han de cumplir todos los requisitos del mismo y de todos los niveles anteriores, de tal forma que si una organización cumple todos los requerimientos para estar en nivel 3 pero le falta uno de nivel 2 y sí cumple con los de nivel 1, se clasificará en este último. Los cinco niveles son los siguientes:

Inicial: las organizaciones no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.
Repetible: las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
Definido: las organizaciones disponen, además de una buena gestión de proyectos, de correctos procedimientos de coordinación entre grupos, de formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos.
Gestionado: las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
Optimizado: la organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.

(Pinchar sobre la imagen para ampliar)

Para dar una idea de la dificultad que supone alcanzar la excelencia, únicamente hay dos empresas en todo el mundo, Infosys y Tata Consulting Services, que tienen un nivel 5 CMMi, mientras que en España, Indra y Everis pelean por estar en el nivel 4.

Sistemas de Soporte a la Decision: el Business Intelligence

2008-12-01T22:46:00.006+01:00

El Business Intelligence o Inteligencia de Negocio es un paradigma relativamente novedoso que hace referencia al conjunto de estrategias y herramientas destinadas a la obtención de conocimiento empresarial a través de un análisis de los datos contenidos en los repositorios organizacionales.

A grandes rasgos, suele definirse como la transformación de los datos de la compañía en conocimiento para obtener una ventaja competitiva. Desde un punto de vista más pragmático, y asociándolo directamente a las tecnologías de la información, podemos definir Business Intelligence como el conjunto de metodologías, aplicaciones y tecnologías que permiten reunir, depurar y transformar datos de los sistemas transaccionales e información desestructurada (interna y externa a la compañía) en información estructurada, para su explotación directa o para su análisis y conversión en conocimiento que sirva de soporte a la toma de decisiones sobre el negocio.

Ello viene motivado porque el exceso de información no es poder, pero el conocimiento sí lo es. En muchos casos, la transformación y el análisis de toda la información y los datos que las propias compañías generan se convierte en un verdadero problema y, por lo tanto, la toma de decisiones se vuelve desesperadamente lenta, de ahí la importancia de este paradigma.

Al igual que comentábamos cuando hablábamos de los ERP, una solución BI se debe concebir como un sistema integral, con una visión y perspectiva global del mismo, de tal modo que se consideren y tengan en cuenta todas sus fases para dar lugar a un producto de calidad y que realmente satisfaga las necesidades del cliente.

Como se aprecia en la figura anterior, en el campo de Business Intelligence se diferencian distintos componentes que forman una arquitectura o Framework global sobre el que basarse para desarrollar cualquier proyecto sobre esta materia. Una solución integral BI se compone de los siguientes elementos:

Diseño conceptual de los sistemas: qué información necesitamos para la gestión y toma de decisiones, qué formato ha de tener, de dónde proceden los datos que necesitamos y cual es su disponibilidad.
Construcción del almacén de datos (DataWarehouse): éste no es más que una base de datos corporativa que replica los datos transaccionales una vez seleccionados, depurados y especialmente estructurados para el objetivo que persigamos.
Selección de herramientas de explotación de la información: Cuadros de Mando Integrales (CMI), Data Mining, etc.

Los principales proveedores de este tipo de soluciones son Oracle, SAP, Cognos y BusinessObjects que ocupan más del 80 % de la cuota total de mercado en lo que a estas tecnologías se refiere. Así mismo, en los últimos años están teniendo un gran auge las múltiples firmas que ofrecen sus productos Open Source, instalándose en un gran número de empresas habida cuenta de que carecen de costes de adquisición y que cada vez ofrecen unas mejores prestaciones.

El Software Colaborativo

2008-12-01T22:01:00.005+01:00

El Groupware o Software Colaborativo es el conjunto de sistemas de información o aplicaciones informáticas que persiguen la integración de todo el trabajo de un equipo con múltiples miembros accediendo de manera concurrente a los recursos proporcionados.

El groupware se basa en tres elementos básicos: la organización, la tecnología y las personas. Aunque la plataforma tecnológica tiene gran importancia, más importantes aún son los aspectos organizativos, es decir, una buena definición de los procedimientos con los que se va a trabajar, así como los aspectos sociales y culturales, es decir, la buena o mala disposición de los empleados para trabajar en equipo.

Así mismo existen tres factores que resultan críticos en una solución de software colaborativo:

Comunicación: aplicaciones que permiten el continuo flujo de información entre los distintos departamentos empresariales, transferencia de archivos, páginas web colaborativas, correo electrónico organizacional.
Conferencia: sistemas para llevar a cabo un intercambio de información de forma interactiva entre los distintos usuarios del software, tales como mensajería instantánea, donde podría tener cabida Twitter, CRMs, ordenadores con escritorios compartidos, etc.
Gestión colaborativa: aplicaciones para administrar el desarrollo de equipos de trabajo, tales como sistemas de gestión de proyectos, de gestión de conocimiento (Knowledge Management), de control de los flujos de trabajo (Workflows),...

Existen numerosas aplicaciones de esta índole, muchas de ellas Open Source (eGroupWare, OpenGroupWare, el propio Moodle, etc), entre las que destacan Google Apps y Microsoft Share Point, propiedad de los dos grandes gigantes de Internet. En la primera se engobla una solución con GMail como gestor de correo electrónico, GTalk para mensajería instantánea, Google Calendar para gestión de eventos, Google Docs para crear y gestionar documentos, Google Site para compartir información desde tu propia estación de trabajo, etcétera.

Sistemas de Información Empresariales: el ERP

2008-12-01T21:13:00.007+01:00

Vamos a hablar hoy acerca de uno de los paradigmas o tecnologías que más han revolucionado los sistemas de información empresariales en los últimos años: los ERP.

Un Sistema de Planificación de Recursos Empresariales (Enterprise Resource Planning) es un sistema que permite la gestión e integración de la información de la empresa, automatizando gran parte de los procesos de negocio que se llevan a cabo en la misma y optimizando los recursos disponibles. Se trata, por tanto, de una herramienta integral de gestión, compuesta por varios subsistemas encargados de funcionalidades específicas, como producción, compras, ventas, logística, etc., cuyo fin último es el de unificar todas estas en una sola plataforma desde la que se pueda administrar todo. Ese es el núcleo del ERP, lo que lo diferencia de las aplicaciones de software de gestión, esa necesidad de integración, de que toda la información esté disponible para todo el mundo todo el tiempo.

Los objetivos fundamentales de los ERP son:

Acceso global a la información de manera fiable y precisa.
Optimización de los procesos empresariales.
Supresión de procesos de reingeniería innecesarios.
Flujo de información constante entre los distintos componentes de la organización.

Este tipo de sistemas se caracterizan por girar en torno a una Base de Datos centralizada, que hace las veces de repositorio, donde se almacena toda la información de la empresa y donde los distintos departamentos o áreas de conocimiento pueden ir a consultar. Ello conlleva que esta información ha de ser consistente y completa, así como transparente, para evitar posibles conflictos entre los propios departamentos o incluso a nivel organizacional. Esto es quizá uno de los factores por los que más se ha criticado desde ciertos sectores a los ERP, porque las distintas áreas de negocio se ven obligadas a compartir su conocimiento, algo que, en muchos casos, se tenía como un bien muy preciado y secreto y no era en absoluto susceptible de ser divulgado.

Las tres características fundamentales que definen a los ERP es que son:

Adaptables: cada ERP está concebido para ser configurado en base a las necesidades de cada empresa y a los procesos que en ella participan. Este es el gran valor añadido de estos sistemas.
Integrales: permiten el control centralizado de todos los procesos empresariales, entendiendo ello como una relación constante entre los distintos departamentos de la compañía.
Modulares: la funcionalidad del ERP está dividida en paquetes o módulos, que pueden ser aplicados y adaptados a la solución global que cada empresa necesita.

Las principales ventajas que proporcionan son...

Permite alcanzar un elevado grado de integridad de los datos.
Los sistemas ERP engloban las mejores prácticas para diferentes procesos.
El enfoque ERP simplifica y estandariza los sistemas a lo largo de la empresa haciendo más fácil de actualizar los sistemas en el futuro.

Y los principales inconvenientes...

La empresa necesita someterse a importantes reingenierías de procesos para adaptarse.
Los ERP incrementan los costes en TI.

Por último, y para dar una muestra del auge de esta tecnología en el mundo empresarial, mostraros la cantidad de ofertas que existen en Infojobs en este campo (hemos tomado indistintamente SAP/ERP).

Aplicaciones de las Redes Sociales

2008-11-29T17:38:00.008+01:00

Cuando oimos el término red social siempre se nos viene a la cabeza algo como Facebook o MySpace, y lo asociamos inmediatamente a sitios donde colgar fotos, crear grupos de amigos, etiquetar gente, etc. Pero las redes sociales son una herramienta muchísimo más poderosas que todo eso y existen muchísimas aplicaciones que las emplean con una perspectiva profesional o empresarial.

Por poner un ejemplo, LinkedIn. Se trata de una red social orientada a profesionales, donde un usuario puede crearse un perfil, adjuntando su currículum vitae, experiencia profesional, aficiones, etc., de tal forma que se puedan establecer contactos directos en la búsqueda de puestos de trabajo de profesionales para una empresa. Así mismo, existen miles de expertos en la propia red que pueden ayudar al usuario a resolver cualquier cuestión que ataña a un ámbito profesional. Tiene más de 25 millones de usuarios, entre los que se encuentra hasta Bill Gates.

Otra buena muestra es Unience, una aplicación basada en redes sociales que pretende ayudar en la toma de mejores decisiones de inversión en bolsa, así como de ser un punto de encuentro y referencia para la comunidad financiera. Su éxito está basado en que ésta es una de las comunidades más solidarias a la hora de compartir información, muestra de ello la multitud de foros existentes para tal fin. Inicialmente estaba formada por sólo un millar de usuarios, con un perfil experto en las finanzas, pero posteriormente se está ampliando con nuevos usuarios. Otra de las ventajas que proporciona es que no sólo hay opiniones, sino también datos objetivos, como estadísticas, análisis detallado de la cartera de inversiones de cada individuo, etc., comparando su estado con el de otros o incluso con el Ibex 35, lo cual dota de un valor añadido importantísmo al sitio.

La medicina, otro de los campos en auge en esto de la web social, también cuenta con numerosas redes sociales. Una de ellas es iMedix, que proporciona un buscador a los usuarios para poder obtener información relevante, escogida de diferentes fuentes existentes en la red, según nuestros criterios de búsqueda. En este mercado, como no podía ser de otra manera, han irrumpido con fuerza los dos grandes gigantes de Internet, Google y Microsoft, con Google Health y HealthVault. El primero de ellos pretende que cada usuario tenga, de forma online, su historial médio, almacenando en el mismo cualquier información relativa, como vacunas, operaciones, enfermedades padecidas, etc. A su vez, pretende ampliar sus servicios, ofreciendo la posibilidad de compartir la propia información con otros usuarios, así como proporcionar un buscador de médicos especializados y una aplicación para contactar con los mismos. En el caso de HealthVault, se trata de un administrador de historiales médicos que permite a los usuarios y a sus doctores, almacenar y consultar todo el historial clínico de forma online y segura, asegurando la privacidad de los datos de los propios internautas.

Por último vamos a hablar de una de las vertientes más extendidas de las redes sociales: el turismo. En este caso de Turismo 2.0, una red en la que los distintos usuarios pueden introducir imágenes, vídeos, recomendaciones o preguntas acerca de distintos destinos, así como chatear de forma directa con otras personas en busca de consejos. A su vez, las personas registradas en este sistema podrán crear blogs individuales donde postear sobre sus experiencias o, incluso tener un lugar donde anunciarse, en caso de formar parte del sector hostelero. Se trata de una de las redes más populares en cuanto a viajes se refiere y promete ser un referente en este sector.

Como veis las redes sociales no se limitan únicamente a Tuenti, sino que pueden tener otras finalidades de otra índole, con un perfil mucho más profesional.

Ah, finalmente comentaros que, el otro día, charlando con una amiga experta en RRHH me comentó que muchísimas empresas, en sus procesos de selección de personal, consultan en las redes sociales para ver y comprobar el verdadero perfil del candidato... así que tened cuidado con vuestro Facebook.

Los Patrones de Diseño Java EE (II)

2008-11-27T23:08:00.003+01:00

Vamos a continuar con el anterior post en el que hablábamos sobre los patrones de diseño de Java EE, recordando que quedaban por detallar la Capa de Negocios y de Integración.

Capa de Negocio

Esta es la capa que presenta un mayor número de patrones, algo bastante razonable porque es aquella que se encarga de la gestión de toda la lógica de negocio de la aplicación Java EE.

Business Delegate: Un objeto de la capa de presentación llama a métodos remotos de los objetos de la capa de negocio, se produce una búsqueda del elemento requerido, generando posteriormente una llamada al servicio en cuestión.
Transfer Object: Encapsula la serialización de un objeto que debe ser traspasado por la red. El flujo de ejecución que sigue comienza con la realización de la petición para, a continuación, crear el objeto Transfer Object que encapsulará el traspaso del objeto requerido por el cliente.
Session Facade: Crea una fachada para encapsular las complejas interrelaciones de los distintos elementos de negocio, proporcionando un servicio uniforme y manejando el flujo de ejecución de los subelementos.
Aggregate Entity: Encapsula la creación de un Bean de entidad compuesto por otros Beans de entidad.
Transfer Object Assember: Es una combinación del Transfer Object y el Session Facade. El primero lo emplea para serializar el objeto, mientras que el segundo llevar a cabo la encapsulación de la creación de un objeto compuesto por otros.
Value List Handler: Maneja la ejecución de sentencias SQL, empleando para ello Beans de Sesión.
Service Locator: Utilizado para abstraer toda la utilización de JNDI (Interfaz de Nombres y Directorios de Java) y de la creación de cualquier contexto inicial de complejo, además de para la encapsulación de búsqueda o creación de los objetos Home y EJB.

Capa de Integración

Data Access Object (DAO): Crea un objeto que es un medio para el acceso a la Base de Datos de la aplicación, de forma que se abstraen y encapsulan todas las operaciones relacionadas con el tratamiento del acceso a datos.
Service Activator: Se utiliza para recibir peticiones y mensajes asíncronos por parte del cliente, buscando el elemento de negocio que contiene el método que se ha de invocar.

Por último vamos a enumerar una serie de ventajas e inconvenientes que presentan este tipo de patrones de diseño.

Ventajas

Estandarización de la solución y consecuente posibilidad de reutilización.
Mejor aprovechamiento de las características la POO.
Interoperabilidad de los patrones.
Aumento del rendimiento a medio plazo.
Diseño de la aplicación de forma robusta.
Adaptada a posibles modificaciones y nuevas adiciones.

Inconvenientes

Necesidad de análisis y estudio previo de los distintos patrones.
Incremento del tiempo de desarrollo.
Posible ligero aumento del coste del proyecto.

Arquitecturas Orientadas a Servicios: SOA

2008-11-27T10:28:00.004+01:00

La Arquitectura Orientada a Servicios (SOA – Service Oriented Architecture) es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos de software de usuario. Se trata de una arquitectura de software ágil que permite la creación y/o el cambio de los procesos de negocio desde la perspectiva de las TI de forma ágil, a través de la composición de nuevos procesos utilizando las funcionalidades de negocio que están contenidas en la infraestructura de aplicaciones actuales o futuras.

En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado.
A diferencia de arquitecturas orientadas a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para la comunicación entre nodos, los servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación; permitiendo el uso en cada nodo de lenguajes de programación heterogéneos y obligando a únicamente coincidir en el contrato entre nodos con necesidades de comunicación.

SOA define las siguientes capas de software:

Aplicaciones básicas, que son sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad.
De exposición de funcionalidades, donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (Servicios Web).
De integración de servicios, facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración.
De composición de procesos, que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio.
De entrega, donde los servicios son desplegados a los usuarios finales.

Los beneficios que puede obtener una compañía que adopte el modelo de arquitectura SOA son:

Optimización de los tiempos de modificación en los procesos.
Accesibilidad para migrar a distintos modelos de negocio, tales como los basados en tercerización o colaborativos.
Capacidad de integración de distintas tecnologías en una sola lógica de negocio.
Posibilidad de modificación de elementos de la capa de aplicación de la arquitectura sin afectar a otros procesos de negocio.

SaaS

2008-11-27T10:24:00.003+01:00

Vamos a hablaros de un paradigma muy de moda en la actualidad de las TICs, SaaS (Software as a Service).

Software as a Service (Software como Servicio) propugna a un modelo de distribución de software en la que se sumistra, a parte del propio sistema, otra serie de servicios como soporte técnico, help desk o mantenimiento. La ventaja que ofrece es que el software requerido se distribuye y aloja en Internet, por lo que el usuario no necesita en ningún momento instalarlo en su computadora personal; y todo lo referente al mismo, datos, sesión, son guardados en un servidor externo proporcionado por la compañía que oferta sus servicios. La gran ventaja que ofrece esto es que se puede alcanzar cualquier segmento de mercado con esta distribución, ya sea una corporación grande, un usuario estándar o una pequeña empresa.

Este tipo de arquitecturas se denominan multi-tenant o multipropietario, en las que sobre un único recurso operan múltiles usuarios que son dueños, por así decirlo, del mismo.

Este modelo presenta numerosas virtudes, como que el acceso, distribución y gestión del propio software a través de la red, lo cual le dota de una disponibilidad muchísimo mayor.

Otro aspecto interesante es que el uso de la aplicación se lleva a cabo en servidores centralizados, en vez de estar alojados en sitios del propio cliente, con lo cual el acceso al mismo se realiza a través de la Web.

También resulta interesante comentar que los datos son guardados en un servidor externo, con lo cual el cliente no requiere de grandes capacidades de almacenamiento en caso de trabajar con grandes volúmenes de información (metadatos, etc.). Así mismo, esto garantiza también que se tendrá siempre copias de seguridad de los mismos, derivando esa responsabilidad en la compañía suministradora, sin tener el cliente que preocuparse de ello.

El modelo de distribución se basa en que la propia compañía suministradora ofrece los servicios de mantenimiento y soporte. Ello conlleva que se tiene en un mismo sitio toda la información, procesamiento y lógica del negocio, algo que a las compañías TIC’s beneficia mucho, pues desaparece ese concepto (en muchos casos realidad) de la dispersión y falta de integración y comunicación entre los distintos procesos del negocio.

SaaS lleva implícito que decrezca la inversión inicial, lo que conlleva un menor riesgo, al poder utilizar el software sin tener que realizar una inversión inicial en máquinas y software para el funcionamiento óptimo de la aplicación. Esto supone un beneficio importante para los directores de la empresa contratante.

Así mismo, este modelo tiene la fortaleza de que todas las actualizaciones y nuevas funcionalidades se pueden tener de manera inmediata, sin necesidad de esperar a que las nuevas versiones estén disponibles, o se tengan que instalar, amén de que no se requerirá personal alguno dedicado a esta tarea. Se dispondrá de todas las actualizaciones y mejoras de manera inmediata.

La empresa centra su esfuerzos en su negocio, realmente se externalizan los sistemas hasta el punto de no dedicar esfuerzos en la elección y mantenimiento de los sistemas. No obstante, siempre requerirá atención del departamento TI pero en mucha menor medida.

Por último, señalar que la aplicación sigue el prototipo “uno-a-muchos”, que viene a determinar que el propio producto es realizado por una empresa y distribuido y utilizado por muchos clientes.

Los Patrones de Diseño Java EE (I)

2008-11-27T01:34:00.005+01:00

En un post anterior ya hablamos de los distintos patrones de diseño existentes, que respondían a soluciones para una serie de problemas que se repetían con cierta frecuencia en los sistemas de información. Sin embargo la creciente demanda de desarrollo de aplicaciones empresariales en entorno web ha hecho que sea necesaria una definición de un nuevo conjunto de soluciones enfocadas a este ámbito: los patrones de diseño JEE (Java Enterprise Edition).

Se dividen en cinco capas: Cliente, Presentación, Negocios, Integración y Recursos, de las cuales nos centraremos en las tres centrales, pues son las que presentan un mayor interés de cara al desarrollo de sistemas con orientación empresarial.

En el siguiente esquema se muestran los distintos patrones y las relaciones que se establecen entre ellos. Seguidamente pasaremos a comentar el primer grupo, el correspondiente a la Capa de Presentación.

Capa de Presentación

Decorating Filter/Intercepting Filter: Maneja varios tipos de peticiones que requieren un procesamiento determinado; especialmente aplicado a procesos de validación de sesión.
Front Controller: Acepta todas las peticiones de un cliente y las direcciona a los manejadores apropiados.
View Helper: Encapsula la lógica de acceso a bases de datos en beneficio de la capa de presentación.
Composite View: Elemento de la Vista compuesto por otros elementos del mismo tipo.
Service to Worker: Similar al MVC, emplea dos subpatrones, el Front Controller para el Controlador y el View Helper para la Vista.
Dispatcher View: Similar al MVC y al anterior, pero el Controller no realiza acciones sobre el Helper.

En un post posterior continuaremos la descripción de las dos capas que restan, la de Negocio y la de Intregración.

Patrones Arquitectónicos: el MVC

2008-11-27T00:55:00.006+01:00

Las arquitecturas lógicas para el diseño de aplicaciones web se dividen entre dos patrones o modelos: el Cliente-Servidor y el MVC (Modelo-Vista-Controlador). La primera, más tradicional y clásica en sistemas con un tiempo de vida largo, y la segunda, más de moda en la actualidad por el paradigma que propone. Para este post nos vamos a centrar en esta última, dado que su uso está extendidísimo y es la más indicada para aplicaciones web.

El patrón MVC o Modelo-Vista-Controlador basa su robustez en que la lógica de la interfaz de usuario varía mucho más rápido que la lógica de negocio y almacenamiento, con lo que pretende separar las capas, de tal forma que un cambio en una de ellas no tenga un impacto elevado en otra. Está dividida en tres capas o niveles:

Modelo: gestiona los datos y la lógica del negocio.

Accede a la capa de almacenamiento de datos. Independencia del modelo con el sistema de almacenamiento.
Define las reglas de negocio, la funcionalidad del sistema.
Registro de las vistas y controladores de la aplicación.

Vista: presentan la información del sistema al usuario y generar los eventos de la interacción con éste.

Captura eventos del usuario y se los envía al sistema a través del controlador.
Recibe mandatos del controlador y muestra información al usuario.

Controlador: recibe eventos del usuario, invoca servicios ofrecidos por el modelo y selecciona la vista adecuada para presentar los resultados.

En la siguiente figura se aprecia la interacción entre los distintos componentes. Hay versiones o apreciaciones del MVC en las que se permite la conexión entre la Vista y el Modelo, sobre todo para operaciones muy simples que apenas tengan complejidad o impacto en la lógica del sistema. Nosotros creemos que, si es precisamente un patrón que trata de separar estas capas de negocio, es mejor que no existan tal relación, teniendo que pasar todas las peticiones a través del Controlador. Y este argumento se refuerza en las aplicaciones Web, donde la Vista suele estar distribuida y existe un altísimo grado de concurrencia en el acceso a los datos del sistema.

Por lo anterior, el flujo de control que sigue este patrón es:

El usuario interacciona con la interfaz (Vista) y genera un evento.
El controlador captura dicho evento y lo gestiona.
El controlador accede al Modelo y lo actualiza.
El controlador invoca la Vista necesaria para presentar los nuevos datos al usuario.

En función de la tecnología en la que estéis desarrollando el diseño existen numerosos frameworks para implementar el MVC, por ejemplo Struts para Java, CakePHP para PHP y Spring.NET para .NET.

Un estándar para la Gestión de Proyectos: el PMBOK

2008-11-26T09:47:00.013+01:00

En este post vamos a hablar de uno de los más (si no el más) importantes estándares de Gestión de Proyectos. El PMBOK (Project Management Body Of Knowledge) aglutina una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro del campo de la Gestión de Proyectos. Fue desarrollado por PMI (Project Management Institute) y proporciona una serie de fundamentos para este área funcional, aplicables a proyectos de múltiple índole: software, ingeniería, construcción...

Postula que un proyecto exitoso va a ser consecuencia de la colaboración y conflictos entre el equipo de gestión o dirección y el de trabajo, y para muestra, una de las frases introductorias del libro: "Buenas prácticas no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado".

Concibe que es en los propios miembros del equipo de trabajo (Gestor de Proyectos y responsables) en los que reside el conjunto de conocimientos (Body of Knowledge) que se han de aplicar para dirigir un proyecto, representando un conjunto vivo, amplio y que es fruto de la unión entre experiencia, estudio y desarrollo. Por ello, la finalidad del PMBOK no es la de proporcionar nueve pasos básicos para el éxito en la gestión de un proyecto, ni pretende mostrar disciplinas, experiencias y técnicas que pueden ayudar a conseguirlo, sino que identifica un subconjunto de éstas que dan lugar a buenas prácticas de ingeniería.

El PMBOK propone cinco procesos básicos y nueve áreas de conocimiento comunes a la mayor parte de los proyectos. Los procesos interactúan a través de un proyecto o fase, y son descritos en base a: Inputs (documentos, diseños,...), Outputs (documentos, productos de ingeniería,...) y aquellas herramientas y técnicas que, aplicadas a las entradas, dan lugar a las salidas.

Los procesos son: Inicio, Planificación, Ejecución, Supervisión y control, y Cierre. No representan fases rígidas ni excesivamente estructuradas, pero básicamente responden al modelo "planear, hacer, revisar y actuar".

Las nueve áreas de conocimiento identificadas en el PMBOK son:

Gestión de la Integración de Proyectos.
Gestión del Alcance en Proyectos.
Gestión del Tiempo en Proyectos.
Gestión de la Calidad en Proyectos.
Gestión de Costos en Proyectos.
Gestión del Riesgo en Proyectos.
Gestión de Recursos Humanos en Proyectos.
Gestión de la Comunicación en Proyectos.
Gestión de la Procura (Logística) en Proyectos.

Esperamos que este post os haya servido para tener una visión global más amplia de un campo tan complejo como la Gestión de Proyectos y que comprobéis que ésta no es una tarea trivial, sino que requiere no sólo de mucho conocimiento, sino también de experiencia.

Por último, deciros que aquí tenéis disponible la última versión del estándar en castellano, publicada en 2004.

Los Ciclos de Vida del Software (II)

2008-11-25T19:05:00.009+01:00

Vamos a continuar la labor comenzada en el post anterior acerca de los distintos modelos de ciclos de vida de software.

Ciclo de vida PROTOTIPADO

Este modelo se basa en la realización continua de diversos prototipos, cada vez más refinados, a partir del conjunto inicial de necesidades del cliente, de tal manera que los entragables van aumentando en su complejidad, con el fin de incrementar la comprensión que tiene del sistema tanto el usuario como el desarrollador.

Su principal ventaja es ese control continuo que se tiene sobre el producto que se está desarrollando, porque está supervisado y guiado por el propio cliente, que va modificándolo a su parecer, con lo que se evita la entrega de sistemas que, al final, no satisfacen las necesidades reales del usuario.

En su contra, estas características pueden hacerle débil, porque el cliente puede exigir plazos más cortos al ver sistemas en "pseudofuncionamiento", creyendo que son los finales. Algo similar puede ocurrir en el equipo de desarrollo, que puede caer en el relajamiento y descuido del compromiso de calidad adquirido.

Ciclo de vida EN ESPIRAL

En este modelo las actividades se conforman en una espiral, representando cada bucle un conjunto determinado de actividades. Éstas no están fijadas a priori, sino que se van eligiendo en base a los distintos análisis de riesgos que se van elaborando en las sucesivas iteraciones, comenzando siempre por el último bucle efectuado.

Cada bucle empieza identificando los objetivos, las alternativas y las restricciones del ciclo. Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado, empezar a plantear el próximo.

El segundo paso es evaluar las diferentes alternativas que se plantean teniendo en cuenta los objetivos a conseguir y las restricciones impuestas. Frecuentemente,este paso identifica las áreas de incertidumbre del proyecto con sus correspondientes riesgos. Si existen riesgos, el siguiente paso conlleva la formulación de una estrategia efectiva en coste (utilizando prototipos, simulación, bancos de prueba, cuestionarios para los usuarios...) para resolverlos.

El tercer paso consiste en revisar los resultados del análisis de riesgos, y el cuarto paso en planificar la fase posterior. Una vez realizado el primer ciclo se volvería a empezar, modificando los requisitos y reformulando los objetivos, estrategias, alternativas, etc.

Como veis hay mútiples alternativas... en nuestro proyecto casi todos optamos, en un principio, por un modelo en cascada, algo que viene determinado por los distintos hitos y entregables que hay que cumplir, pero creemos que va mutando en un modelo híbrido, puesto que se van realizando distintas etapas de manera disjunta con el fin de obtener una mayor productividad y, casi siempre, debido a los rechazos por parte del cliente.

Los Ciclos de Vida del Software (I)

2008-11-25T19:01:00.005+01:00

En este post vamos a hablar de los distintos ciclos de vida que se pueden aplicar en el desarrollo de un proyecto software. El ciclo de vida es el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software, y que abarca desde su concepción hasta su retirada.

Para este artículo nos vamos a centrar en los cuatro que consideramos principales o más importantes: cascada, incremental, prototipado y en espiral.

Ciclo de vida en CASCADA ("Waterfall")

Este modelo es el más antiguo de cuantos vamos a comentar y resulta especialmente sencillo de gestionar. Se basa en varios principios, como que una nueva fase no puede comenzar hasta que no se termine la anterior, que para poder pasar de una fase a otra se han de haber cubierto todos los objetivos de la predecesora o que al final de cada fase se pueda revisar el estado del proyecto por parte de los stakeholders.

Por contra presenta, habida cuenta de su longevidad, algunos inconvenientes. Uno de ellos es que no refleja el proceso real del desarrollo del software, porque muy raramente un proyecto sigue un flujo secuencial, sino que siempre hay iteraciones. Otro es que el paso por todo el ciclo es lento y pesado, porque requiere que se finalice una fase para pasar a la siguiente, y por último, requiere de mucha paciencia por parte del cliente, porque no posee un prototipo de su sistema hasta los últimos compases del proyecto.

Ciclo de vida INCREMENTAL

Este modelo satisface la necesidad de una secuencia no lineal de los pasos de desarrollo. En el modelo incremental se va creando el sistema software añadiendo componentes funcionales al sistema (llamados incrementos). En cada paso sucesivo, se actualiza el mismo con nuevas funcionalidades o requisitos, es decir, cada versión o refinamiento parte de una versión previa y le añade nuevas funciones. El sistema software ya no se ve como una única entidad monolítica con una fecha fija de entrega, sino como una integración de resultados sucesivos obtenidos después de cada iteración.

Se ajusta a entornos de alta incertidumbre, por no tener la necesidad de poseer un conjunto exhaustivo de requisitos, especificaciones, diseños, etc., al comenzar el sistema, ya que cada refinamiento amplía los requisitos y las especificaciones derivadas de la fase anterior.

Así mismo, constituyó un avance sobre el modelo en cascada, pero también presenta problemas. Aunque permite el cambio continuo de requisitos, aún existe el problema de determinar si los requisitos propuestos son válidos. Los errores en los requisitos se detectan tarde y su corrección resulta tan costosa como en el modelo en cascada.

En el siguiente post os hablaremos de los otros dos que nos hemos dejado en el tintero...

¡Facebook quiere comprar Twitter!

2008-11-25T09:24:00.007+01:00

Según una información publicada en el diario económico norteamericano Financial Times, Facebook ha ofrecido la cantidad de 500 millones de dólares, unos 390 millones de euros, por Twitter.

También según la propia noticia, Twitter es una de las empresas de Internet que más interés despierta entre inversores e internautas, pues ofrece un sistema de comunicación muy rápido, sencillo y útil, unido esto a que puede empotrarse en cualquier portal y admite múltiples configuraciones y personalizaciones.

Así mismo, es curioso el medio de pago ofrecido por Facebook a la compañía de microbloggin, pues pretende llevarlo a cabo a través de la cesión de acciones de la propia compañía compradora.

Por último, señalar que el fundador de Twitter, Bizz Stone, ha recalcado que su deseo expreso de que ésta siga siendo un ente independiente y que no quiere ningún tipo de cesión de derechos ni nada similar.

Esta noticia da una noción de la magnitud que Twitter ha adquirido en la comunidad internauta, pues el crecimiento que ha experimentado en su corta vida ha sido realmente gigantesco.

Open Social

2008-11-25T01:06:00.005+01:00

¿Os habéis planteado alguna vez si existiera algo similar a Internet pero con Redes Sociales? Sí, sí, una especie de "red de redes" sociales... ¡Pues existe! Y se llama Open Social.

Y, como no podía ser de otra manera, quién si no, Google está detrás de todo ello. El objetivo de esta iniciativa es el de proveer un conjunto de API’s comunes que tiene como finalidad el proporcionar un recurso para el desarrollo de aplicaciones con fines sociales, pudiendo establecer conexiones y consultas con distintas redes sociales. De esta forma se puede tener acceso desde un único recurso a múltiples redes, con lo que la cantidad de información al alcance del usuario aumenta de manera exponencial.

Su infraestructura gira en torno al establecimiento de dos tipos de usuarios: los sites o Contenedores y las empresas o Desarrolladores que la emplean como base para la creación de aplicaciones.

Para el primero de ellos se cuenta con un repositorio casi inagotable de información, habida cuenta de los integrantes de la plataforma: Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, MySpace, Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo y XING. Para hacernos una idea de la magnitud de estos sites, exponemos algunos datos que darán una visión más clara de ello: MySpace (alrededor de 190 millones de usuarios), Orkut (unos 62 millones de usuarios), LinkedIn (aproximadamente 11 millones de usuarios) y Oracle (2ª mayor empresa de desarrollo de software del mundo, únicamente por detrás de Microsoft).

El objetivo principal de esta iniciativa es que cualquier sitio web de contenido social pueda implementar la API y dar cabida en él a aplicaciones sociales de cualquiera de los partners de Open Social, con lo que se pueda crear una red virtual empleando recursos de varios de ellos.

La API en sí se divide en tres módulos:

Profile and Friends Information: datos del perfil de usuario y amigos del mismo.
Activities: conjunto de actividades llevadas a cabo por el usuario (subir fotos, histórico de contactos, etc.).
Persistence Data API: datos de todas las aplicaciones adscritas a Open Social. Dota de persistencia a esta capa de la aplicación, evitando la pérdida de datos.

Esperamos que esta información haya despertado vuestro interés por las redes sociales, un instrumento que va muchísimo más allá de simples repositorios de fotos o de sitios para hacer amigos.

Recomendaciones para el Diseño

2008-11-24T23:41:00.005+01:00

Sumergidos como estamos en la fase de Diseño queremos continuar con la iniciativa surgida en el Análisis y mostraros algunas recomendaciones o impresiones que cada uno hemos tenido en el desarrollo de este punto y que esperamos que puedan resultar útiles para este o próximos Diseños de Sistemas de Información.

Antes de comenzar, simplemente recalcar que se trata del punto, creemos, más importante de todo este proyecto, pues va a dar lugar a una definición detallada del futuro sistema a implementar, incluyendo todas las pautas que los desarrolladores tendrán que tener en cuenta para esa tarea.

"Basarte en tus propios conocimientos sobre las diferentes tecnologías que se pueden utilizar, ya que aunque siempre se puede hacer un trabajo de investigación previo sobre una tecnología que no se conozca, el resultado nunca va a ser igual que si ya has utilizado esa tecnología para el diseño en otras ocasiones."

"No sólo es necesario realizar un buen diseño de la base de datos que va a albergar toda la información del sistema, sino que hay que ser totalmente estricto en el desarrollo de las tablas de la base de datos para que estas concuerden con la realidad que se pretende capturar, tanto en el ámbito de su descripción, como en el del tipo de los diversos parámetros que contienen."

"Cuando vayas a realizar el diseño de un sistema de información, lo primero que debes tener presente es que el proceso de diseño incluye concebir y planear algo en la mente, un dibujo, modelo o croquis, y que tu opción de resolución debe proporcionar una idea completa de lo que es el software, enfocando sus funcionalidades, comportamientos y dominio de datos, desde el punto de vista de la implementación. El diseño debe ser una guía que puedan leer y entender el equipo encargado de desarrollar el código y las personas encargadas de probar y mantener el software. Por ello, debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente."

"A la hora de desarrollar la explotación de los componentes del sistema, es recomendable ir realizando el trabajo sobre subsistemas cuya funcionalidad este recogida de forma clara y concisa, para obtener un buen diseño."

"En el momento de la definición de clases y métodos, hay que tener siempre en cuenta que el sistema puede ser desarrollado por gente que desconozca por completo la aplicación, con lo que los nombres y documentación utilizados han de ser descriptivos y reflejar de manera clara cuál es su funcionalidad, así como cualquier parámetro que se pueda necesitar."

Ojalá estos pequeños trucos os sirvan de ayuda y puedan serviros de guía de cara a futuros proyectos.

La importancia de... la gestión de la relación con el cliente: el CRM

2008-11-24T10:10:00.007+01:00

Como ya habréis podido comprobar tras estos dos meses de trabajo, una de las partes más complejas de la gestión de un proyecto es el trato con el cliente. Existen múltiples estrategias para la captación y administración de clientes, pero hoy nos vamos a centrar en una que está muy de moda en la actualidad y que parece ser que da buenos resultados: el CRM.

El CRM (Customer Relationship Management o Administración de la Relación con los Clientes) es una estrategia que permite a las empresas identificar, atraer y retener a sus clientes, además de ayudarles a incrementar la satisfacción de éstos y a optimizar así la rentabilidad de sus negocios. Hablamos, por tanto, de CRM como estrategia, lo que implica no sólo disponer del software adecuado que te permita gestionar las relaciones con los clientes, sino que además, supone un cambio en los procesos de la empresa y la implicación de todos los empleados de la misma para que esta estrategia tenga éxito. Así mismo, el CRM no sólo hace referencia a esta estrategia, sino también a los sistemas informáticos que le dan soporte.

Si nos centramos en las TIC puras, el CRM es un software para la administración de la relación con el cliente, dando soporte a la gestión de esta tarea, a los procesos de venta y publicidad y marketing, y que puede dar una visión al cliente de múltiples aspectos del proyecto, como el grado de avance del mismo, el estado de diversas tareas, etcétera.

La gran ventaja de un CRM es que permite acceder a la información de forma centralizada y el cambio de datos se realiza “una sola vez”.

Beneficios de tener un CRM:

Aumento de las ventas.
Reducción de costes.
Se graba la información una vez.
Compartir información es inmediato.
Toda la compañía conoce dónde encontrar información sin perder tiempo buscándola.
Satisfacción del cliente, ya que quien le atienda conoce todo su histórico de relación.
Toda la compañía sabe más sobre ellos mismos y la actividad empresarial.
El negocio se gestiona mejor ya que se dispone de datos para tomar decisiones.
Se entienden mejor los canales de venta.
Se identifican los comerciales más eficientes.

Como habréis visto esta estrategia empresarial incide en un notable valor añadido en este factor clave que es, dentro de la gestión de proyectos, la administración de la relación con el cliente.

Patrones de Diseño UML (II)

2008-11-22T20:09:00.009+01:00

Como ya introdujimos en el anterior post sobre Patrones de Diseño, éstos pueden dar solución a múltiples problemas que se presentan de forma recurrente durante la fase de diseño de distintos Sistemas de Información, y que permiten definir algunos estándares para abordar estos inconvenientes de una forma más directa, facilitando de manera notable la labor del Diseñador.

Descripción de los patrones

Patrones de creación

Abstract Factory: proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
Builder: separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
Factory Method: define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.
Prototype: especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
Singleton: garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Patrones estructurales

Adapter: convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
Bridge: desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
Composite: combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
Decorator: añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
Facade: proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
Flyweight: usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
Proxy: proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.

Patrones de comportamiento

Chain of Responsibility: evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
Command: encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.
Interpreter: dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
Iterator: proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
Mediator: define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.
Memento: representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.
Observer: define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
State: permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
Strategy: define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
Template Method: define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
Visitor: representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.

Un ejemplo de uso

En este caso nos vamos a basar en el patrón Observer para la explicación del uso de los patrones. Nos hemos decidido por éste porque está considerado casi vital en las arquitecturas que siguen el MVC (Modelo-Vista-Controlador), que es la que empleamos nosotros en el proyecto. Esto es así porque estos sistemas varían mucho en tiempo de ejecución y se han de capturar de alguna forma todos los eventos que suceden, con el fin de que el sistema se actualice con la mayor brevedad posible. En el supuesto actual, se suscriben 'listeners' a los objetos que pueden disparar eventos, para hacer esto de la forma más óptima posible.

Vemos como el Sujeto tiene una lista de Observadores adscrita, que según vaya capturando eventos irán notificando al primero qué ha sucedido para que éste cambie su estado.

Como podéis ver se requiere de un elevado grado de abstracción y se generan muchísimas más clases, pero el funcionamiento global es mucho más eficiente y las soluciones aportadas son óptimas.

La importancia de... una buena metodología para la revisión

2008-11-22T19:54:00.007+01:00

Hace unos días, hablando con una compañera, me comentaba algunas de sus vivencias en la asignatura. La que más me impactó fue, sin duda ninguna, que era ella la que, en su grupo, se encargaba de integrar cada una de las partes de cada documento, realizadas por los distintos miembros del grupo, así como de revisar el documento final. Aparte de la enorme carga de trabajo que ello supone, creemos que lleva implícito, de forma inevitable, una peor calidad en las revisiones, por aquello de que ven más catorce ojos que dos, lo que repercute en tener que realizar más modificaciones, y por ende, más versiones de los documentos.

La experiencia a lo largo del desarrollo del proyecto ha ido modificando nuestra forma de realizar las revisiones. Al principio, dada la corta extensión de los documentos, cada miembro del grupo llevaba a cabo una revisión del texto en su totalidad, lo cual generaba siete archivos diferentes, con infinidad de comentarios que luego había que integrar en el definitivo. Ello suponía, además, que muchas veces los propios comentarios chocaban entre ellos, produciéndose inconsistencias y dudas acerca de qué era lo que de verdad queríamos reflejar en el documento. Al ver que esta metodología incidía en una carga de trabajo extra muy grande y que los resultados obtenidos eran simplemente normales, decidimos cambiar.

El siguiente intento, y hasta ahora el último, consiste en la técnica de las revisiones cruzadas. Esto viene a definir que cada miembro del equipo revisará una parte del documento, siempre excluyendo la que él haya realizado (esto es algo básico, porque en ese punto se pierde objetividad), y luego se juntará todo en una sesión de integración con todos los componentes del grupo. Esta versión ha sufrido un leve cambio, pasando a llevarse a cabo por parejas en vez de forma individual, de tal manera que dos personas revisan cada parte, lo cual hace que se gane en calidad y que, sin repercutir en un trabajo enorme, se consigan unas versiones finales más refinadas.

Creemos que esta última metodología, a pesar de que puede que no produzca unos documentos tan refinados como la primera, es mejor dado que tanto la carga de trabajo individual como grupal se ve disminuida notablemente, incidiendo en una mayor disponibilidad de tiempo para poder llevar a cabo otras tareas del proyecto.

¿Cómo lo hacéis vosotros?

Patrones de Diseño UML (I)

2008-11-22T19:07:00.008+01:00

Inmersos como estamos en la fase de Diseño, vamos a hablar un poco sobre algunas técnicas que se pueden emplear para optimizar esta actividad, dando así al desarrollador un esquema mucho mejor de cara a la implementación del sistema.

En este post vamos a comenzar a hablar sobre los Patrones de Diseño UML, algo que todos ya conoceréis y que, a pesar de que su uso conlleva un leve trabajo extra conceptual, facilitan notablemente esta tarea.

Según el libro de Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software, un Patrón de Diseño es "una solución simple y elegante a un problema específico y común del Diseño Orientado a Objetos (DOO)". Así mismo, se apostilla que "son soluciones basadas en la experiencia y cuya fiabilidad está demostrada".

Este paradigma viene dado por detección de la repetición constante de problemas en los distintos diseños de Sistemas de Información, lo que conlleva que se defina una colección de patrones que reflejen las soluciones óptimas para cada uno de esos problemas. No es un concepto trivial de entender, requiere un proceso de estudio previo y asimilación, pero una vez que se supera dicho ciclo, los diseños creados en base a patrones presentan un mayor grado de flexibilidad, modularidad y reutilización.

Los patrones se dividen en tres grupos generales:

Patrones de estructura: describen como las objetos pueden ser combinados formando estructuras complejas y nuevas funcionalidades. A su vez se dividen, en un segundo nivel en:

Estructural de la clase: Proporcionan interfaces más útiles mediante herencia.
Estructural del objeto: Creación de objetos complejos mediante objetos individuales para formar grandes estructuras.

Patrones de creación: tratan de la forma de instanciar los objetos.

Creacional de la clase: Instanciación de la clase mediante herencia.
Creacional del objeto: Patrones más escalables y dinámicos.

Patrones de comportamiento: definen la comunicación entre los objetos.

Comportamiento de la clase: distribuyen el comportamiento entre clases mediante herencia.
Comportamiento del objeto: analizan la comunicación entre objetos interconectados.

A continuación, se ve el diagrama con los distintos patrones y cómo interactúan entre ellos.

En otro post comentaremos brevemente la funcionalidad de cada uno de los patrones así como un pequeño ejemplo de uso de uno de ellos.

Palmadita en la espalda

2008-11-21T09:11:00.001+01:00

Ya ha concluido la primera fase del concurso de blogs... La verdad es que la competencia está siendo muy dura y todos los blogs que participan en el concurso tienen un gran nivel, con lo cual esto no está siendo nada fácil. Ello, además, supone un trabajo extra bastante considerable a la ya de por si fuerte carga de trabajo de la asignatura, por lo que hay momentos en los que cuesta continuar, pero hay que admitir que que te reconozcan un trabajo motiva, y motiva muchísimo, para no detenerse.

No queríamos dejar pasar la oportunidad de felicitar a todos nuestros compañeros que también estén llevando a cabo esta ardua tarea de mantener un blog, y animarles a que sigan trabajando, que esto no ha hecho más que empezar y que lo importante es ser constante y trabajar duro.

¡Mucho ánimo a todos!

19-N

2008-11-20T00:06:00.006+01:00

Esta mañana ha tenido lugar un acontecimiento que, esperemos, haga reflexionar a más de uno. Nos hemos concentrado más de tres mil personas frente al Ministerio de Ciencia e Innovación y hemos dejado claro que no nos vamos a quedar callados mientras continue esta tropelía.

Como muestra de que este acto ha tenido calado y repercusión, echad un ojo a estos enlaces, donde los medios se hacen eco de nuestra protesta:

El Mundo (1)
El Mundo (2)
20 Minutos

A continuación, os dejamos una muestra gráfica de lo que ha sido la concentración, adornada con algunas de las frases que se han coreado...

"Es teleco el que no bote, eh"

"Telecos, cabr...es, robais atribuciones"

"Uno cero uno, o todos o ninguno"

"Cero uno cero, fuera zapatero"

"Os vamos a tirar el servidooooooooor"

"Zapatero, somos ingenieros"

"Ingenieria informatica: no compila"

"Regulación, de la profesión"

En fin... esperamos haber contribuido un poquito a la causa y a que, de una vez por todas, tengamos reguladas nuestras competencias.

Desde aquí os animamos a que nos ayudéis a recordar todas aquellas cosas que nos hayamos dejado en el tintero... ¡Ánimo!

La importancia de... la gestión del cambio

2008-11-18T00:32:00.007+01:00

Tras dos Informes Quincenales de Seguimiento nos vamos dando cuenta de la importancia de la Gestión de Proyectos y de la Gestión de Cambios, así como las desviaciones que, en base a múltiples factores, se producen en los proyectos informáticos.

Planificar bien es relativamente complejo, pero planificar y gestionar un proyecto sin desviaciones es, cuanto menos, una quimera. De ahí la importancia de saber gestionar y tratar los cambios que se van produciendo, llevando a cabo constantes replanificaciones, basadas siempre en la experiencia del desarrollo de proyectos. La desviación siempre va a estar ahí, pero de esta manera, atajándola fase a fase, se puede minimizar, consiguiendo un deterioro menor tanto en lo referente a términos de tiempo como de costes.

Según el reporte elaborado por Standish Group, todo un referente en el estado de los proyectos de software, "Extreme Chaos", los proyectos se clasifican en tres tipos:

finalizado con éxito: si se completa a tiempo, dentro de presupuesto y cumpliendo con todas las características y funciones especificadas.
no satisfactorio: el proyecto se completa y es operacional, pero con desviación en presupuesto y tiempo y con menos características y funciones de las que fueron especificadas inicialmente.
finalizado con fracaso: proyecto cancelado antes de completarse.

En la tabla siguiente puede verse el porcentaje de proyectos exitosos, y su evolución en el tiempo:

Como se puede apreciar, el porcentaje de exitosos va aumentando, pero aquellos proyectos que conluyen con desviaciones no merman, lo cual muestra a las claras que las metodologías empleadas no son tan efectivas ni eficientes como debieran ser.

De manera análoga, se pueden establecer una serie de factores que influyen, en mayor o menor medida, en el éxito de un proyecto, tales como la experiencia, la gestión de recursos humanos, el Jefe de Proyecto, etc. En el siguiente gráfico se puede apreciar el impacto que tiene cada uno en este aspecto.

Se aprecia como, tanto los Recursos Humanos (usuarios y Jefe de Proyecto) y su cualificación, como la confianza en el equipo de trabajo son los dos indicadores de éxito más importantes y que más van a marcar el devenir del proyecto. Este dato aporta una visión clara de lo importante que es la implicación de cada uno de los miembros del equipo, así como de un Jefe compentente. Esto nos puede servir para nuestro proyecto, porque, tal y como se puede ver, somos uno de los activos más importantes y que más podemos influir para terminarlo con éxito y con la menor desviación posible.

Twitter, ahora en tu DS

2008-11-15T20:08:00.005+01:00

Trasteando un poquito por Internet nos hemos encontrado con DSTwitter, un nuevo cliente de la aplicación que nos ocupa diseñada para ser utilizada en la consola Nintendo DS. Además de las funcionalidades típicas de Twitter tiene un valor añadido: fue creado por Acdrtux, una empresa de diseño y desarrollo web española.

Presenta las siguientes características:

Es multilingüe: acepta inglés, francés, italiano, alemán y castellano, configurándose automáticamene en función del firmware de la propia consola.
Carga de avatares en formato GIF.
Muestra el tiempo relativo de envío de cada twiteo, tal como hace el cliente web (hace X minutos, etc.).
Uso de la conexión WiFi para enviar y recibir mensajes, con medidor de calidad de señal.
Teclado táctil.
Aceptado por twitter.com como cliente oficial de twitter.

No deja de ser una curiosidad más acerca de la aceptación y expansión de esta herramienta, y de la cantidad de ampliaciones, plug-ins y adaptaciones que se han realizado en base a ella.

Por último, si os lo queréis descargar, aquí tenéis el enlace:

Descargar DSTwitter

Ingeniería en Informática

2008-11-14T09:19:00.005+01:00

Bueno, como todos habréis visto/leído/escuchado, se está llevando a cabo un proceso para desvirtuar nuestra profesión, no pudiéndose equiparar nuestro título (ni el de Ingeniería Química, con los que desde aquí nos solidarizamos) con los de las demás Ingenierías. Estaréis ya cansados de oir cosas, así que sólo queríamos dejaros un par de enlaces para que véais que la cosa se está moviendo y que hay un halo de esperanza.

Decano de Informática de la UPM

El Senado nos apoya

Y otro que hace un llamamiento a las movilizaciones y donde podéis encontrar mucha más información:

Más información

Luchemos y defendamos ésto que tanto y tanto esfuerzo nos está costando conseguir...

PD: Momento cumbre de la entrevista con el Decano de la UPM:

P. ¿Por qué no puede alguien que ha estudiado Matemáticas o Bellas Artes, por ejemplo, y tiene talento, trabajar de informático en una empresa que lo quiera contratar?

R. Le hago yo otra pregunta: ¿Por qué no puede hacer un puente ese señor?

P. Parece distinto.

En fin...

La importancia de... la motivación

2008-11-14T00:34:00.001+01:00

Llevábamos ya tiempo queriendo hablar de algo que consideramos vital para cualquier trabajador, y por extensión, para cualquier ingeniero de software: LA MOTIVACIÓN.

El hombre, por el simple hecho de ser hombre (y eso se ve reforzado en nuestro amado país), trabaja mejor si está agusto, si está rodeado de un ambiente de trabajo agradable, si su trabajo se ve, no ya recompensado, sino valorado. Es algo inherente al propio ser humano, rendimos más si estamos mejor.

Leyendo un poquito sobre motivación de equipos de trabajo, creemos que se pueden establecer dos corrientes de pensamiento bien diferenciadas:

El ingeniero, por el hecho de ser un profesional y recibir un sueldo por ello, ha de hacer su trabajo de la mejor manera posible.

El ingeniero rinde más y genera más beneficios si se le valora el trabajo y si está motivado.

Nosotros, a título particular, nos identificamos más con esta última. Una persona motivada, contenta, y con ganas de hacer las cosas bien va a hacer siempre mejor su trabajo que otra que no tiene otra motivación que la de su rutina diaria y su sueldo a final de mes.

Es lícito comentar que por motivación no sólo se entiende una compensación de índole económica o material, sino que entendemos que va más allá. Porque muchas veces el reconocimiento del trabajo bien hecho, una felicitación por parte del cliente, una palabra de ánimo de tu Jefe cuando estás hundido,... motiva de una manera infinitamente mayor que cualquier regalo o retribución monetaria.

Y, sino, cuando llega el lunes o jueves y vas a tu revisión de IS3 hartito de tanto trabajo, medio asqueado, y ves que, de repente se hace la luz y te aprueban un par de documentos, ¿¿¿¿¡¡¡¡¿no te sientes otra vez a tope y con las pilas cargadas para seguir dándolo todo?!?!?

Las herramientas de modelado UML

2008-11-13T23:56:00.001+01:00

Andamos liadillos con el diseño y, a pesar de haber decidido la herramienta a utilizar en la Oferta, se nos ocurre la idea de escribir un post acerca de este tema. Existen en el mercado multitud de suites para realizar diagramas UML, pero en casi todas hemos encontrado alguna pega.

Las principales taras van desde que el no soportar UML 2.x a realizar diagramas muy poco atractivos desde el punto de vista visual, pasando por mil pequeños detalles que a unos gustan más, y a otros, menos. Vamos a hablaros un poco de aquellas que hemos ido usando todos estos años y comentando un poco nuestras impresiones.

Por ejemplo, Altova UModel, una herramienta que soporta UML 2.x, que crea unos diagramas de componentes y de clases bastante atractivos visualmente, pero que no permite introducir componentes en el diagrama de clases (sólo deja paquetes) y los diagramas de Casos de Uso son realmente feos a la vista.

Por otro lado, dTinf Cake Studio, que no soporta UML 2.x, que es bastante pesado de manejar, por el control sobre relaciones, para mover entidades dentro de los diagramas, etc, pero éstos resultan bastante atrayentes.

Microsoft Visio. No sabemos si se podría introducir aquí, porque realmente no se basa en estándares UML, aunque permite realizar diagramas con tal lenguaje. A su favor tiene la gran facilidad de manejo, pues es muy intuitiva y no requiere apenas familiarización previa.

Rational Rose es quizá la herramienta más famosa y potente para modelado UML, es de IBM y tiene una gran aceptación a nivel mundial. La única pega que se le puede poner es que requiere de un conocimiento del entorno bastante avanzado para tener un manejo ágil del mismo.

Finalmente, nosotros nos hemos decidido por Enterprise Architect, que permite UML 2.x, sus diagramas son bastante atractivos y es moderadamente sencilla de manejar.

Por último, citar que existen muchas otras, como Telelogic, VisualParadigm, etc., que podréis usar, nosotros sólo os damos pistas para que probéis y, finalmente elijáis la que más os satisfaga.

El infierno llegó

2008-11-13T00:37:00.002+01:00

Comienza la parte, en nuestra humilde opinión, más dura de la asignatura: la fase de diseño. Cuando comenzamos a trabajar el ella nos dimos cuenta de lo complicado que es plasmar toda esa información que tenemos en lenguaje natural en un conjunto de diagramas que sirvan para describir la arquitectura del sistema.

Esta fase no consiste sólo realizar un diagrama de clases que refleje todas aquellas entidades que serán necesarias para que la descripción del sistema sea completa, sino que, comenzando a un alto nivel, será necsaria una definición de los distintos subsistemas que conformarán CLICKR, la comunicación entre ellos, sus características, etc. El pasado martes aquello parecía un hervidero. Primeramente se discutió sobre el patrón arquitectónico que emplear, que si un MVC tradicional, que si uno de capas... Luego, una vez que creíamos que teníamos solucionado un poco el asunto, llegó lo peor.

Y es que un diseño de bajo nivel no es algo trivial. Primeramente, y partiendo de la base de que la tecnología usada será Java, hemos de comentar que existen multitud de herramientas, librerías o tecnologías para implementar los distintos módulos, y desde aquí recomendamos encarecidamente que, a menos de que se conozca muy bien la citada tecnología, se desista de su uso, porque se va a perder un tiempo precioso en aprender algo que, probablemente luego pueda estar mal.

Nos volvimos locos en un mar tecnológico: que si JSP o JSF para la capa de presentación, que si Hibernate para el mapeo objeto-relacional, que si DAO para el acceso a la capa de datos, que si Struts para la implementación del Modelo-Vista-Controlador, que si Spring o EJB para la lógica del negocio, que si usar patrones de diseño tradicionales como Handler o Singleton, que si no usar nada de eso...

Lo dicho, mucha suerte y evaluad bien todas las alternativas antes de decantaros por ninguna, porque hay cosas realmente interesantes que pueden ahorrar bastante trabajo a la hora de implementar (nuestro enfoque tradicional), pero que pueden ser un suplicio para diseñarlas (nuestro enfoque actual).

¡Ánimo!

La importancia de... la gestión de los requisitos

2008-11-12T00:20:00.002+01:00

Tras el post anterior, y un poco fastidiados por algunos cambios que tuvimos que hacer en el DAS provocados por modificaciones en el EVS, hemos estado buceando por Internet y hemos descubierto algo que antes nos parecía un horror y que ahora vemos como una ayuda bastante interesante y a tener en cuenta: las Herramientas de Gestión de Requisitos.

En un principio puede parecer una tarea tediosa, la de tener que introducir requisito a requisito en la aplicación, con todos los atributos que éstos tienen, las dependencias, etc. Pero muchas veces un requisito mal definido, una funcionalidad mal interpretada o, simplemente un cliente "especial", pueden hacer que se tenga que volver hacia atrás y haya que modificar el Estudio de Viabilidad, con los consiguientes trastornos que ello acarrea, porque un error en una fase crece exponencialmente conforme va avanzando el proyecto, y es entonces cuando te das cuenta de la dimensión del problema.

Este tipo de herramientas permiten realizar variaciones entre requisitos de software y de usuario, estableciendo la trazabilidad entre ambos, y manteniendo la consistencia, sin que la eliminación de uno pueda suponer una catástrofe en el resto. Así mismo se permite una gestión de los mismos, pudiendo variar sus atributos conforme va avanzando el proyecto, puesto que, por ejemplo, la estabilidad en un momento puede ser media y, con el tiempo, pasar a alta. Otro aspecto muy interesante a tratar es el del control de las matrices de trazabilidad, que se realizan y actualizan de manera automática con la simple inserción del requisito de usuario fuente con respecto al de software, lo cual evita una actividad bastante aburrida, ya que no sólo se ha de realizar la primera vez, sino que también la gestión y mantenimiento de la misma puede llegar a resultar exasperante. También existen herramientas que permiten visualizar el posible impacto que puede tener un cambio en el resto del proyecto, siendo tarea del Jefe del Equipo el evaluar si esa modificación es realmente asumible o el coste que va a tener implícito puede ser mayor que el beneficio de provoque.

Por último, citar algunas de estas herramientas, algunas de ellas de libre distribución, que pueden ser útiles para este tipo de trabajo: Caliber-RM, DOORS, SoftREQ, ReuseStudio, RTM Workshop, Requisite Pro, etc., y citar la aplicación desarrollada para tal fin por nuestro compañero Marcos en su PFC de ITIG: Requirements Management Tool. Una aplicación, desarrollada en formato Web, que es capaz de competir con gran cantidad de las suites existentes en el mercado.

Recomendaciones para el Análisis

2008-11-11T23:38:00.001+01:00

Una vez prácticamente finalizada la fase de análisis (a falta de un par de modificaciones en el DAS), queremos plasmar cuáles son nuestras impresiones, así como dar algunos consejos que puedan ser útiles de cara a futuros Análisis de Sistemas de Información. Lo primero que queremos comentar es que, a pesar de que pueda resultar algo trivial, o incluso banal, esta fase es fundamental para nuestro proyecto, pues todo lo que hagamos ahora será la base del futuro sistema, con lo cual las decisiones que tomemos habrán de ser consistentes, pues un pequeño cambio en este punto puede suponer un cambio inasumible en fases posteriores.

A continuación os vamos a mostrar algunas de las recomendaciones que distintos miembros del equipo dan en base a su experiencia como Analistas:

"Realizad un gráfico de bajo nivel que contemple las distintas funcionalidades que posee el sistema, de tal forma que, posteriormente, la extracción de los distintos Casos de Uso resulte notablemente más sencilla y, por extensión, esto se vea reflejado también en la fase de obtención de requisitos."

"Revisad la descripción de los requisitos. Por un lado es fundamental comprobar que ésta describe correctamente la funcionalidad que se pretende plasmar, y por otro, se ha de intentar definir cualquier término que pueda presentar ambigüedad, con el fin de hacer que el cliente tenga una comprensión clara de lo que se dice y que tenga la sensación de que realmente se está entendiendo lo que él desea."

"Centrad el diseño conceptual en las funcionalidades básicas de la aplicación, sin preocuparse demasiado por las posibles variaciones que podría tener el diseño según la tecnología utilizada. Es muy importante que el diseño de clases (modelo conceptual) sea adaptable a cualquier tecnología."

"Se debe dedicar una gran cantidad de tiempo en realizar un análisis en profundidad de los requisitos, cubriendo todas las funcionalidades que se describieron en la oferta y que el cliente querrá que estén reflejadas en el futuro sistema."

"Sentaos tranquilamente y revisad que los distintos módulos del Análisis son consistentes. El trabajo en paralelo es fundamental, pero muchas veces cada uno interpreta las cosas de una manera y pueden aparecer errores que a la postre pueden resultar fatales. No es necesario mucho tiempo, pero sí estar seguros de que nuestra parte concuerda con las demás."

Bueno, esperamos que estos consejillos puedan seros de ayuda y que os eviten alguna versión de más.

Sobre la Gestión de la Configuración

2008-10-29T09:51:00.000+01:00

Trabajando en el Plan de Gestión de Configuración nos hemos dado cuenta de que no es un proceso banal, tal y como pudiera parecer en un principio, sino que el documento que se genera va a tener una importantísima repercusión en todo el trabajo que desarrollemos en el futuro. El principal objetivo de este Plan es el de mantener la integridad de nuestro producto a lo largo de todo el ciclo de vida del producto software, habida cuenta de las numerosas modificaciones que va a sufrir a lo larto de todo el proceso de trabajo a causa de reuniones con el cliente, malentendidos en el funcionamiento, etc. Todo esto infiere, de una forma irremediable en el siguiente plan a tratar, el de calidad.

En lo que a nosotros se refiere, va a marcar las directrices para múltiples aspectos de nuestro proyecto:

Identificación de los documentos: se especificará cuál será la nomenclatura de los distintos productos generados a lo largo de las distintas actividades del mismo (documentos de desarrollo, actas de reuniones, actas de gestión de cambios, etc.).
Establecimiento de las bibliotecas de almacenamiento del sistema: en ellas se crearán múltiples directorios para ir almancenando los distintos productos generados, ya sean versiones beta, definitivas, copias de seguridad, control de tiempos,etc., tales como biblioteca maestra, de backup, de seguimiento...
Gestión de cambios: se diseñarán los formatos de las hojas de control de estado de los documentos, de las solicitudes de cambios, de los informes, de las certificaciones de aceptación, etc., así como una definición de cuál será el proceso que sigue un cambio desde que se propone hasta que se acepta/rechaza.

Una vez explicado cómo se ha de hacer, es interesante ver que este plan realmente tiene ventajas y que puede aportar un valor añadido a nuestro producto.

Mantenimiento integral de la integridad de los distintos elementos del proceso, en una atmósfera de cambio continuo.
Control de la evaluación y ejecución de los cambios.
Visión objetiva y concreta acerca de la creación y evolución del producto.
Robustez ante auditorías y revisiones, pues se muestra el estado del avance real del proyecto.
Reducción de costes de desarrollo, manteniendo una estabilidad en el proyecto.
Aseveración de la integridad del producto en la operación, actualización y consistencia de toda la documentación generada.
Incremento en la eficiencia y efectividad de la administración.

Por todo ello podemos asegurar que, a pesar de ser un documento no excesivamente extenso, sí es fundamental para un mejor proceso de desarrollo del proyecto y creemos que seguirlo fielmente puede ayudarnos a ser más eficientes en nuestro trabajo.

Métricas para el Control

2008-10-29T01:53:00.003+01:00

A raíz de encontrarnos inmersos en la primera sesión de control del proyecto, se nos ha ocurrido investigar algo sobre métricas o métodos para la mejora del control de los proyectos, de la planificación de los mismos y del rendimiento de los trabajadores. Con este post se pretende dar una visión global de dos de estas métricas: PSP (Personal Software Process) y TSP (Team Software Process). Éstas surgen por la necesidad de poder aplicar un modelo de madurez (CMM) a proyectos pequeños, yendo desde el ingeniero de software como entidad hasta el equipo de desarrollo; de ahí la primera P (Personal) de PSP y la T (Team) de TSP.

PSP

Fue definido por Watts S. Humphrey, y tiene como principios:

Cada ingeniero es diferente, por lo que debe planificar su trabajo en base a su propia trayectoria profesional.
Para mejorar, los ingenieros deben usar procesos personales bien definidos y cuantificados.
Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos, que no es fruto del azar, sino del esfuerzo por hacer un trabajo de calidad.
Cuanto antes se detecten y corrijan los errores, menos esfuerzo será necesario.
Es más efectivo evitar los defectos que detectarlos y corregirlos.
Trabajar bien es la forma más rápida y económica de trabajar.

Así mismo, el ingeniero, como profesional, debe:

Planificar el trabajo.
Esforzarse por cumplir la planificación.
Esforzarse por obtener productos de calidad.
... y esto en un contexto de mejora continuo.

Actividades de PSP:

Planificación: estimar errores, creación de una planificación del proyecto, estimación de tamaño y recursos.
Diseño de Alto Nivel: diseño del componente y creación de prototipos.
Revisión de diseño de Alto Nivel: verificar errores en el diseño.
Desarrollo: generar el código, revisarlo, compilarlo y corregir errores.
Análisis de Resultados: medir la efectividad del proceso en base a todas las mediciones tomadas durante el mismo.

PSP es un método que puede proporcionar una gran mejoría en el rendimiento del Ingeniero de Software y, para ello, se centra en una serie de aspectos en los que incide para lograr tal mejoría. El primero de ellos es el Control del tiempo, que infiere en que el Ingeniero ha de medir el tiempo que dedica a cada una de las tareas, teniendo en cuenta posibles interrupciones y anotando aquellas fases que se concluyan. En este punto entran en liza el Resumen Semanal de Actividades y la Tabla de Registro de Tiempos, formularios en los que se anotan las horas dedicadas a cada actividad por día. Ello permite ver en qué tareas se dedica más tiempo y establecer unas planificaciones futuras más ajustadas. Otro aspecto es la Planificación, que tiene como pilar el punto anterior, puesto que en base al recuento de tiempos veremos qué actividades necesitan mayor dedicación y cuales menos. El Tamaño del producto es otro punto importante. Aquí entra en juego el Resumen de Plan de Proyecto, documento que recoge las estimaciones tanto de tamaño como de posibles errores, así como los datos reales, de tal forma que nos dan una visión clara de cómo de bien planificamos o en qué fallamos más. Todo esto también afecta al punto de la Planificación, que es el epicentro de PSP.

Como conclusión, a pesar de ser un proceso muy costoso, que puede hacer que el profesional pierda motivación, sí que se ha demostrado que las personas que emplean este método consiguen una mejoría notable, con unos datos, en un periodo de tiempo razonable, netamente superiores a los de un Ingeniero que trabaja sin métrica de control alguna.

TSP

Al igual que PSP, fue creado por Humphrey. Su idea es la de ajustar los principios de PSP al trabajo en equipo, algo fundamental en nuestros días. Propone que los datos ofrecidos por los ingenieros capacitados en PSP pueden ser utilizados para administrar equipos de desarrollo de software.

Proporciona directrices para que el equipo pueda establecer unos objetivos realistas y pueda planificar los procesos en los que se ve involucrado, con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y dar lugar a productos eficientes, fiables y de calidad.

Fases del ciclo TSP:

Lanzamiento: revisión de objetivos, formación de equipos de trabajo y describir las necesidades del cliente.
Estrategia: diseño conceptual, elaboración de estrategia de desarrollo, identificación de riesgos y estimación de tamaño del producto y del esfuerzo requerido.
Plan: estimación del tamaño de los componentes, identificación de tareas y establecimiento del plan de calidad.
Requisitos: análisis de las necesidades, establecimiento de requisitos y plan de pruebas.
Diseño: de alto nivel, especificando cada componente, establecimiento de estándares de codificación y plan de integración.
Implementación: diseño detallado, implementación, revisión, compilación y pruebas unitarias.
Pruebas: integración y pruebas globales del sistema.
Postmortem: análisis del producto desarrollado y documentación.

La principal pega que tiene esta métrica es que añade un trabajo extra al propio del PSP, y esto, en un equipo de trabajo acosado por plazo de entrega inviables, cantidades ingentes de trabajo, etc., puede resultar una tarea que, en vez de sumar, reste.

A pesar de todo, y de que es mucho más reciente y, por lo tanto, menos maduro, que PSP, se trata de un método que, si se elabora de una forma estricta y constante puede dar lugar a mejores prácticas de ingeniería y un aumento del rendimiento de los equipos de trabajo.

Primeras impresiones

2008-10-06T17:37:00.005+02:00

Parece que nos hemos salvado de la quema... por lo menos por ahora.

Esta mañana nos han corregido la oferta, el primer documento a entregar del proyecto de IS3, y salvo algunos errores tontos (calificados como "de Barrio Sésamo") y cosillas fácilmente modificables, no hemos salido muy mal parados, o al menos esa es la sensación que nos ha quedado.

Esta semana pasada nos ha servido para ir dándonos cuenta, a escala bastante reducida, de lo que va a significar esta asignatura a lo largo de todo un cuatrimestre: muchas reuniones, muchas horas de trabajo, y sobre todo la dificultad de coordinar a 7 personas a la vez para que se pongan de acuerdo (aunque sólo sea para elegir un día de reunión). De todas formas lo afrontamos con optimismo y vitalidad, por lo menos ahora, ya veremos cómo estamos en noviembre...

Es gracioso comprobar cómo, al igual que pasa en los grupos de amigos y en otros conjuntos más o menos reducidos de personas, es complicado ponerse de acuerdo hasta para elegir la tontería más insignificante (quién no se habrá pasado discutiendo con los colegas durante 2 horas para decidir a qué garito nos vamos de copas... como si eso importase). Pues eso, nosotros somos capaces de tirarnos una hora delante de la pantalla de un ordenador intentando decidir qué nombre le ponemos a nuestro producto, llegando al extremo de consultar un generador automático de nombres (bastante pésimo, por otra parte). En fin, qué sería de nosotros sin esos momentos de dispersión.

Y hablando de momentos de dispersión, nuestro proyecto se basa en "Twitter.com" (para entenderlo, hay que verlo hasta el final, como las buenas pelis):

Y nada más, como punto final hay que felicitar a nuestro compañero de equipo Marcos, que tras mucho esfuerzo y sacrificio se ha sacado una merecida Matrícula en su PFC de la Ingeniería Técnica. Esperamos que te vaya todo igual de bien en esta etapa.

Todo tiene un comienzo...

2008-09-29T23:15:00.000+02:00

Este blog pretende ser un lugar donde contar nuestras vivencias, las experiencias que nos sucedan a lo largo de este proyecto que acabamos de comenzar. Esperamos que os sirva de ayuda, de guía o incluso, por qué no, de paño de lágrimas.

Está pensado por y para vosotros. ¡Disfrutad!