miércoles, 31 de diciembre de 2008

El Cuadro de Mando Integral

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.

martes, 30 de diciembre de 2008

El WorkFlow

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)

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.

lunes, 29 de diciembre de 2008

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

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

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).

miércoles, 24 de diciembre de 2008

¡Feliz Navidad!

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 !!!

jueves, 18 de diciembre de 2008

Reflexiones... Luis Puente

¿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

¿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

¿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

¿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...

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

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)

miércoles, 17 de diciembre de 2008

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

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)

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...

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 ...

martes, 16 de diciembre de 2008

Reflexiones sobre la Evaluación 360º

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

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:
  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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)

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)

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
  1. El ser humano ordinario siente una repugnancia intrínseca hacia el trabajo y lo evitará siempre que pueda.
  2. 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.
  3. 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
  1. 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.
  2. 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.
  3. Se compromete a la realización de los objetivos de la empresa por las compensaciones asociadas con su logro.
  4. 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.
  5. 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.
  6. 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.

lunes, 15 de diciembre de 2008

Recomendaciones para las Pruebas

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

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,...).

domingo, 14 de diciembre de 2008

IQS4 o cuando la desviación ya no es tal

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...

jueves, 11 de diciembre de 2008

Los Patrones de Diseño Web

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.

martes, 9 de diciembre de 2008

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

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.

lunes, 8 de diciembre de 2008

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

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.