• Dirección de informática es una denominación bastante pobre, que se centra en los ordenadores y olvida muchos otros aspectos relevantes de las tecnologías de la información. No obstante, ha sido utilizada durante mucho tiempo y tampoco es necesario huir de esta denominación.
• Dirección de Tecnologías de la Información es un término más amplio, pero está centrado en la tecnología y no tanto en su utilización. Indica que vemos esta dirección como una dirección que debe centrarse en la gestión de los elementos tecnológicos. El nombre más cercano en inglés sería CTO o Chief Technology Officer.
• Dirección de Sistemas de Información es una denominación que indica una visión de esta dirección centrada en la información y en la forma en la que esta se gestiona en la empresa. La más cerca traducción al inglés es CIO, Chief Information Officer.

En este post vamos a utilizar Dirección de Sistemas de Información o Dirección de TI de forma indistinta, pero debemos entender los matices que se esconden tras estas pequeñas variaciones en la denominación.

1.- La Dirección de Sistemas de Información tiene un papel complicado dentro de las organizaciones.

La Gestión de las Tecnologías de la Información es un trabajo complejo, en continuo movimiento. La informática en concreto y las tecnologías de la información en general, están sufriendo un continuo cambio que produce que los conocimientos que eran útiles hace unos pocos años, ahora sean poco relevantes y tengamos que estar en una continua absorción de nuevas tecnologías, estándares y oportunidades.

La Dirección de TI sigue teniendo que gestionar la tecnología. Los activos de la empresa son muy valiosos y muchos de ellos están relacionados con las tecnologías de la información. Es necesario vigilar el correcto funcionamiento de los sistemas, su seguridad, el mantenimiento y actualización de los sistemas.

Las empresas se mueven en un entorno cada día más competitivo, con mayores dificultades para obtener el éxito, y tienen que exprimir al máximo los normalmente escasos recursos disponibles para obtener una significativa ventaja. La Dirección de Sistemas de Información debe apoyar los objetivos cada día más exigentes, normalmente con recursos cada día más escasos.

La Dirección de Sistemas debe comprender cada día más el negocio, debe entender para qué se utilizan las tecnologías y comprender cuales son los criterios empresariales que rigen las diferentes inversiones. El Director de Sistemas debe hablar el lenguaje del negocio.

En muchas ocasiones los informáticos disponen de un conocimiento muy preciso del funcionamiento de las aplicaciones y por lo tanto tienen datos muy concretos sobre el funcionamiento interno de las empresas. Pero, este detalle les impide ver el conjunto, los objetivos y los criterios empresariales que hay detrás de estos sistemas. Los informáticos son -en estas situaciones- molestos, siempre están poniendo pegas a las ideas de mejora y evolución empresarial, sobre todo a aquellas más radicales y emprendedoras que pueden llegar a ser las más importantes para la evolución del negocio.

En otro extremo está el Director de Sistemas que, en su intento de hablar el lenguaje de los negocios, ya no habla de su área y se inmiscuye en el trabajo de las demás direcciones diciendo a todo el mundo lo que tiene que hacer. También suele ocurrir que el resto de direcciones también cruzan sus fronteras y hablan sin parar de temas técnicos, deciden autónomamente sobre la implantación de sistemas e incluso contratan proveedores tecnológicos sin consultar. En estos casos sólo queda poner orden en la organización.

2.- El Gobierno de TI

Son todavía muchas las direcciones de sistemas que no tienen un auténtico control sobre su área, desconocen realmente donde se están realizando las inversiones, no disponen de planes de sistemas e incluso no controlan a sus proveedores. En estos casos se suelen aprovechar de mezcla entre la confianza y desconocimiento que tiene la dirección sobre las actividades de la dirección de sistemas.

El Gobierno de TI es un área especialmente importante. Vimos en el post Estándares para la Gestión de TI, primera parte que existen una serie de guías y buenas prácticas que podemos seguir para guiarnos en este gobierno. Estas guías junto a herramientas para la gestión de departamentos de IT como ITM Plaftorm permiten a la Dirección de Sistemas gestionar con excelencia todos los aspectos de su área, desde las personas hasta los proveedores, de las máquinas a los procesos.

La gestión de los Sistemas de Información no puede ser un “ir hacia adelante” sin más. Es necesario disponer de adecuados sistemas de planificación y control. Las planificaciones se deberán cambiar todas las veces que el negocio lo necesite, pero siempre se deberá mantener un control preciso sobre toda la actividad del área.

3.- El puesto de Director de Sistemas

El puesto del Director de Sistemas sigue avanzando desde un planteamiento excesivamente técnico a un planteamiento estratégico y de negocio. El papel actual del Director de Sistemas sigue siendo más táctico que estratégico, aunque paulatinamente se va asumiendo que debe centrarse en la aportación de ventajas competitivas por medio del uso de la tecnología de la información.

La transformación del papel de los Directores es un desafío para las organizaciones. El Director de Sistemas requiere una nueva formación orientada al negocio, sin dejar de tener una base tecnológica. Muchos son los Directores de Sistemas que han conseguido este cambio, bastantes son los que ya han empezado este recorrido, pero, desgraciadamente, hay algunos que se resisten a esta nueva forma de abordar su función.

Si usted, como Director General, no consigue que su Director de Sistemas esté alienado con los objetivos de la empresa y hable en términos de negocio, intente que cambie, pero si no lo consigue, busque a otro para ocupar ese lugar, no se resigne. Los Sistemas de Información de su organización son algo demasiado valioso como para no sacarles todo el partido. Las Tecnologías de la Información ofrecen ventajas competitivas de las que se puede aprovechar. Busque el equipo que pueda ofrecerle el mejor alineamiento entre la tecnología y el negocio.

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

El riesgo en un proyecto es un evento o condición incierta que, en caso de ocurrir, tiene un efecto positivo o negativo sobre los objetivos de un proyecto. Habitualmente nos centramos en los riesgos con efecto negativo, es decir, aquellos que suponen una amenaza para el éxito del proyecto, aunque estándares como PMBOK también hablan de “riesgos positivos”.

Debemos ser capaces de gestionar esta incertidumbre y por lo tanto manejar los riesgos de forma activa y eficiente, no simplemente lamentarnos por las cosas que nos ocurren y aparentemente estaban fuera de nuestro control.

2.- Gestión de Riesgos

El PMBOK establece la gestión de riesgos como una de las áreas de conocimiento que todo jefe de proyecto debe manejar de forma eficiente.

Ilustración 1: Procesos en la Gestión de Riesgos (PMBOK)

 El paso más importante es identificar los riegos preguntándonos: ¿Qué puede pasar que afecte de forma significativa al proyecto? Se considera que un riesgo tiene una causa y, si ocurre o materializa el riesgo, una consecuencia o efecto. Es importante hacer la identificación de riesgos estableciendo las causas y los efectos, es decir, expresando con claridad que puede pasar y en que nos afecta.

Una vez identificados los riesgos deben valorarse siguiendo dos criterios fundamentales:

• la probabilidad que el riesgo se materialice
• el impacto que tiene este riesgo en los objetivos del proyecto

Con esta valoración podremos calcular de forma sencilla la exposición que tenemos a cada riesgo. Si damos un valor numérico a la probabilidad y otro valor numérico al impacto, podemos hacer una sencilla multiplicación entre ambos valores para conocer nuestra exposición al riesgo.

Ilustración 2: Matriz de Exposición al Riesgo

 Será prioritario gestionar los riesgos a los que tengamos una mayor exposición, es decir, los que tienen  mayor probabilidad e impacto. No tiene mucho sentido gestionar riesgos que es muy improbable que ocurran o riesgos que apenas tendrán impacto sobre nuestro proyecto.

3.- Plan de Mitigación y Plan de Contingencia

Una vez identificados y valorados los riesgos podremos gestionarlos, es decir, podemos tomar medidas para reducir nuestra exposición al riesgo. Gestionar un riesgo supone:

• Establecer un plan de mitigación del riesgo, es decir, realizar acciones para reducir la probabilidad de que un riesgo se materialice.
• Establecer un plan de contingencia, es decir, realizar acciones para prepararse ante la ocurrencia del riesgo y reducir el impacto que este riesgo tiene en el proyecto.

Estos planes pueden ser de muchos tipos, no es posible establecer guías absolutamente generales, y en gran medida será a experiencia e incluso la imaginación quienes nos llevarán a encontrar “soluciones” para cada gestionar cada uno de los casos.

La gestión de riesgos puede conllevar el tener que realizar nuevas tareas en el proyecto, y por lo tanto puede llegar a afectar al coste o plazo inicial. En ocasiones se tiende a no abordar estos planes y esperar a que se produzcan los problemas. Esperar a tener una situación de crisis es bastante irresponsable y la gestión anticipada de riesgos es extremadamente recomendable. “Los riesgos no están para lamentarse, están para gestionarlos”.

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

Tal y como vimos en el post anterior, lo primero que debemos hacer es saber qué tenemos que hacer. Una vez conocemos más o menos el alcance, debemos realizar una estimación. Un problema habitual al que se enfrentan proveedores o departamentos de TI es que se les pide que hagan esta estimación antes de la toma de requisitos y su correspondiente análisis funcional. Se llega a exclamar frases como: “si no sé qué tengo que hacer, como te voy a decir el tiempo y coste del proyecto”.

En la práctica es necesario dar una estimación con un conocimiento muy escaso del alcance. No podemos evitarlo. Pero todos, usuarios y técnicos, clientes y proveedores, debemos saber que esta es una estimación muy poco precisa, que tiene mucho riesgo y que por lo tanto no puede ser tomada como una verdad absoluta.

Los usuarios y clientes se sienten tentados en utilizar estas estimaciones iniciales, normalmente realizadas por analogía con proyectos similares, para presionar en las negociaciones y así obtener mejores condiciones. Estas estimaciones top-down o de arriba abajo, deben revisarse en cuanto se disponga de información detallada con la que podamos contrastar y no simplemente ser utilizadas con verdades hasta que ya tenemos desviaciones significativas en plazo y coste.

2.- Análisis de esfuerzos

La planificación de los proyectos conlleva el desglose del trabajo en tareas más o menos pequeñas y manejables. Este proceso de Estructura de Descomposición del Trabajo (EDT), o Work Breakdown Structure (WBS), es la base para realizar un análisis de esfuerzo o estimación bottom-up o de abajo arriba, que va acumulando las valoraciones de cada parte y ofrecerá una valoración mucho más precisa del proyecto.

Aunque hay muchos métodos de valoración de las piezas de software, las valoraciones siguen siendo subjetivas, aunque más detalladas. Para intentar evitar esta subjetividad, desde hace varias décadas se han ido generando métodos formales para realizar estimaciones de esfuerzo.

Algunas de estas técnicas son:

• Puntos función
• COCOMO
• Mark-II
• Slim
• ObjectMetrix

De una forma u otra estos sistemas formales de estimación tienen en cuenta:

• Se parte de una Unidad de Medida: subsistema, casos de uso, clases, componentes, interfaces, páginas Web, ficheros, etc.
• Se realiza una valoración de la Complejidad/Tamaño/Reutilización de cada elemento: Alta, media, baja
• Se pondera la Productividad (tecnología – personas): Java, .NET, PHP, etc.
• Se establecer una Distribución de Esfuerzo de cada Fase: Análisis y maquetación 20%, Diseño 20%, Construcción 40%, Pruebas 12%, Instalación 5%, Gestión y planificación 3%
• Por último, se tienen en cuenta actividades de gestión, como reuniones del grupo de trabajo y de seguimiento, documentación, etc.

Una vez conocido el esfuerzo debemos establecer la planificación, que organiza el esfuerzo, los recursos y las actividades de forma temporal. Los proyectos tienen un tamaño “natural”. Intentar comprimir la planificación de forma excesiva produce una presión que aumenta el riesgo, complica la gestión y pone en peligro la propia planificación. Además, un proyecto, cuanto más grande es, más energía requiere para labores de coordinación y comunicación. La estructura y organización del proyecto también afecta a la planificación.

3.- Partir de la capacidad y no del alcance

En los proyectos es habitual tener una acumulación de buffers de seguridad (Cadena Crítica de Goldratt) que se incorporan en la planificación para gestionar imprevistos. Esto, unido a que el trabajo se expande hasta ocupar todo el tiempo disponible (Ley de Parkinson), hace que las planificaciones rara vez son excesivas y los proyectos casi nunca acaban antes de lo planificado.

Por ello se han planteado métodos alternativos basados en definir un plazo concreto de tiempo y un conjunto limitado de recursos. Una vez que conocemos las constricciones o limitaciones de plazo y coste, entonces decidimos que funcionalidades son abordadas, es decir, que “cabe” dentro de estas limitaciones.

Este “modelo de caja” es bastante práctico en entornos con definiciones muy cambiantes y poco definidas, donde es más fácil conocer que limitaciones de plazo y esfuerzo tengo, para desde ahí analizar que alcance podemos abordar con estas limitaciones.

En el siguiente post revisaremos los riesgos en proyectos de TI y cómo podemos realizar una gestión activa de los mismos.

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

En el post “IEDGE – Estándares para la Gestión de TI, segunda parte” describíamos las 9 áreas de conocimiento que define el PMBOK. De estas áreas de conocimiento hoy vamos a revisar la que quizás tiene un mayor y más importante papel en el éxito de los proyectos: la Gestión del Alcance.

Ilustración 1: Procesos en la Gestión del Alcance (PMBOK)

 Según un estudio realizado por Clive Finkelstein (uno de los padres de la ingeniería de la información) más de la mitad de los problemas que se presentan los proyectos de desarrollo de software, se deben a problemas relacionados recopilación de los requerimientos, muy por encima de problemas de diseño técnico o programación.

Ilustración 2: Origen de los Problemas en el Desarrollo de Software (Finkelstein)

Si nos fijamos bien, los mayores problemas se producen en las fases más tempranas de los proyectos, mientras que en la práctica los problemas en fases posteriores como la programación, no afectan de una forma tan significativa al proyecto, ya que son mucho más sencillos de resolver.

2.- La ingeniería de requisitos

La idea que tiene el ingeniero de software y la que tiene el usuario o cliente sobre el alcance puede estar muy alejada una de otra. Hay que ser capaces de compartir esa “imagen mental” que cada uno tiene sobre el sistema que hay que construir, algo que es especialmente complicado por el carácter inmaterial del software, que hace muy difícil describir cual debe ser el alcance que debe tener.

Para resolver en cierta medida esta problemática ha surgido lo que se ha venido en denominar la ingeniería de requisitos. Aunque seguramente llamar ingeniería a estas técnicas es un poco exagerado, da muestra del esfuerzo para ser capaces de fijar de forma clara y unívoca el alcance de los sistemas.

Existen una serie de técnicas formales para obtener y reflejar los requisitos, pero al fin y al cabo, dependerá de la capacidad y experiencia de los analistas el realizar las preguntas correctas e identificar las lagunas o problemas que puedan surgir. Por muchas reuniones que mantengamos, es difícil saber si nos hemos olvidado algo. Muchas veces cuando describimos los requisitos nos fijamos en las características más importantes o novedosas y olvidamos o no hacemos hincapié en otras menos relevantes. Un analista con experiencia es clave para obtener toda la información necesaria para saber el ámbito del proyecto.

3.- Los cambios en los requisitos

En muchos casos, y por mucho que nos esforcemos, los requisitos no van a poderse mantener fijos durante la vida del proyecto y van a surgir cambios de alcance. En ocasiones estos cambios van a ser fruto de elementos externos: cambios en el mercado, cambios en la legislación. Pero en otras muchas ocasiones van a ser fruto de especificaciones poco definidas o de nuevas ideas que van surgiendo a la vista de lo que se va desarrollado.

La existencia de los cambios debe aceptarse, no es posible ignorarlos. Pero los cambios deben gestionarse y no incorporarlos al alcance del proyecto sin más. Cada cambio debe ser valorado, analizando el impacto que tiene sobre el trabajo ya realizado, revisada la coherencia que tiene con el resto de requisitos del sistema, identificando el efecto que puede tener en coste y plazo.

Una vez realizado una correcta identificación de las consecuencias de un cambio de alcance, es cuando se puede proceder a su aprobación, a poder ser formal, que permita comunicar a todos los involucrados en el proyecto, que se ha producido un cambio y que por lo tanto, el alcance original del proyecto y posiblemente su coste y/o plazo se han visto afectados.

En siguiente post revisaremos la complejidad y problemática de la estimación de esfuerzo en los proyectos de TI y las soluciones que se han ido dando para aumentar la precisión en esta materia.

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

6.- Ciclo de vida en espiral

Siguiendo en esta línea iterativa, B. Boehm definió un modelo evolutivo para el desarrollo rápido de versiones incrementales denominado ciclo de vida en espiral. En este modelo se parte de un concepto básico, sobre el cual se desarrolla rápidamente un sencillo prototipo que permite confirmar que el concepto es válido. A partir de aquí se va incrementando la funcionalidad y validando en cada paso que estamos en la línea correcta, evolucionando el sistema de forma consistente.

Ilustración 4: Ciclo de Vida en Espiral

 Este es un modelo especialmente adecuado cuando tratamos con proyectos innovadores o donde  los requisitos no están muy claros, pero por contra produce un importante nivel de “estrés” en los participantes (tanto técnicos como usuarios), pues tiene como objetivo una iteración muy rápida.

Es importante mantener el control en este tipo de proyectos, pues tienen una cierta tendencia la velocidad sin control. Aun cuando el método recalca la importancia del análisis de riesgos y la planificación de cada ciclo, es común que se termine convirtiendo en un proceso desorganizado donde los requisitos son implementados a medida que van llegando sin garantizar la coherencia e integridad del conjunto.

7.- Variaciones al modelo en espiral

Dado que los modelos en espiral o iterativos parecen reducir el tiempo de entrega de los sistemas, se han producido bastantes variantes sobre estos modelos, en general encaminados en dar un mayor control y efectividad a las iteraciones.

En esta línea el Ciclo de vida RAD utiliza un modelo en espiral incluyendo una restricción de tiempo (caja de tiempo), con varios equipos en paralelo y realizando integraciones constantes. Al introducir la limitación temporal se garantiza que los esfuerzos no van a ser consumidos sin un punto de control, aunque tiene importantes riesgos en la comunicación entre los equipos y las presiones que produce la caja de tiempo de cada versión.

El Ciclo de vida del Proceso Unificado (RUP) ha sido una de las metodologías en espiral más difundidas gracias al éxito del Lenguaje Único de Modelado (UML, por sus siglas en inglés). Este modelo permite que en cada fase se vaya haciendo más hincapié en unos aspectos que en otro, así en las fase iniciales se hace más trabajo relacionado con los requisitos y el análisis del sistema, para en las últimas centrarse más en las pruebas.

Ilustración 5: Ciclo de Vida RUP

 8.- Metodologías ágiles

La necesidad de realizar desarrollos muy rápidos sobre entornos con requisitos muy poco definidos y cambiantes -como en muchas ocasiones han sido las nuevas plataformas de Internet- ha propiciado una nueva generación de metodologías de desarrollos basadas en la agilidad y rapidez, sin perder el control. Desde el eXtreme Programming (XP) y hasta el más recientemente SCRUM, estas metodologías ágiles han ofrecido mecanismos para realizar desarrollos extremadamente rápidos sin una sustancial pérdida de control, eliminando muchos elementos que consideran innecesariamente complejos o burocrácticos..

En concreto SCRUM también establecer el modelo de caja de tiempo (que aquí se denomina Sprint). Para ello se define el periodo de tiempo de cada ciclo (normalmente entre 2 a 4 semanas), decidiendo que funcionalidades del conjunto de requisitos (product backlog) se pueden desarrollar en este ciclo (sprint backlog). En Scrum hay una serie de roles muy definidos para cada miembro del equipo y se realizan revisiones diarias sobre la evolución del proyecto, realizando un seguimiento y comunicación muy intensa entre los miembros del equipo.

No todos los proyectos son susceptibles de seguir este tipo de metodología ágil. Sólo son adecuadas en desarrollos muy rápidos y con equipos pequeños y muy experimentados.

Aunque sencillas, estas metodologías ágiles son bastante estrictas, ya que en ocasiones son adoptadas por programadores que realmente quieren volver al modelo primitivo y al desarrollo como arte, por lo dejan de seguir las normas que estas metodologías establecen y simplemente vuelven al desarrollo sin control y sin método.

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

En el post sobre Estándares para la Gestión de TI describíamos el ciclo de vida de los proyectos tal y como lo describe el PMBOK, es decir, Inicio – Planificación – Ejecución – Cierre. Ya advertíamos en ese post que no se debe confundir este ciclo de vida de los proyectos con las fases o etapas de la ejecución del proyecto como tal.

Ahora, de la mano de la ingeniería de software vamos a dar un repaso al ciclo de vida del desarrollo de software, es decir, al “Marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso” (definición de la norma ISO 12207-1).

2.- Elementos base del desarrollo de software

Lo organicemos como lo organicemos, cualquier proceso de desarrollo de software tiene más o menos los siguientes elementos:

• Requisitos: toma de requisitos de alto nivel sobre qué tiene que hacer el sistema que hay que desarrollar.
• Análisis: revisión de los requisitos componiéndolos como un todo coherente, revisando si existen carencias o inconsistencias.
• Diseño: descripción de los diferentes componentes tecnológicos y cómo van a interactuar entre ellos
• Programación / Parametrización: implementación de las diferentes funcionalidades por medio de lenguajes de programación o parametrización de paquetes o sistemas preexistentes
• Pruebas: confirmación que los desarrollos no contienen errores (pruebas unitarias), que el diseño es completo y consistente (pruebas de integración) y que los requisitos y objetivos se cumplen (pruebas funcionales y de usuario).
• Despliegue: aunque en ocasiones se olvida, el despliegue y capacitación de los usuarios también es parte del ciclo de vida del software y debe ser tenido en cuenta dentro de su gestión.

La organización de estos elementos definen los diferentes modelos del ciclo de vida del desarrollo de software que se han ido utilizando a través del tiempo en las diferentes organizaciones. Vamos a dar un repaso a algunos de estos modelos.

3.- Ciclo de vida “primitivo”

Aunque parezca increíble, más de un desarrollo se realiza en base a programar y probar, sin una definición clara de los objetivos o un diseño general de las diferentes piezas.

En muy pocas ocasiones da buen resultado y sólo es práctico en el caso de que el usuario y el programador sean la misma persona. En este desarrollo de tipo “personal” se puede encontrar sistemas de macros en Excel, desarrollos de aplicaciones en Access o pequeñas utilidades de productividad personal, pero no es, en general, un modelo aplicable a nivel empresarial.

Ilustración 1: Ciclo de vida primitivo

4.- Ciclo de vida clásico o en cascada

Este modelo de ciclo de vida en cascada fue creado por W.W. Royce [1970], y ha sufrido innumerables versiones y adaptaciones posteriores. Se caracteriza por estar compuesto por una serie de fases que se ejecutan secuencialmente. Cada fase finaliza con la obtención de productos que son utilizados en la fase siguiente

Ilustración 2: Ciclo de vida clásico o en cascada

Este ciclo de vida ha sido especialmente discutido y rechazado por muchas generaciones de programadores, si bien sus principios básicos se recogen en todos los modelos posteriores. Su principal pega es la dificultad de realizar “correcciones hacia arriba”, hacia las etapas anteriores del proceso, es decir, si en el diseño se detecta un error o conflicto en el análisis, es muy complicado volver atrás, ya que esa fase se ha dado por concluida y por lo tanto no se puede reabrir con facilidad.

No debemos rechazar este método sin más, sólo hay que tener en cuenta la posibilidad de poder revisar en fases posteriores el trabajo ya realizado. En desarrollos conocidos y estables es un método utilizado con éxito, sobre todo en grandes sistemas donde prácticamente toda la funcionalidad debe estar disponible desde la primera versión.

5.- Ciclo de vida iterativo

En la práctica casi todos los proyectos no cubren todos los requisitos en su primera versión, por lo que una vez realizada una entrega se vuelve a abordar una versión posterior que incluye nuevas funcionalidades. Asumir que esto es así desde un principio es lo que plantea el ciclo de vida iterativo: que una vez realizada la integración o entrega de una versión, se volverá a la fase de análisis para seguir avanzando en el desarrollo.

Ilustración 3: Ciclo de vida iterativo

Este tipo de ciclo de vida también tiene sus peligros, ya que puede convertirse en un ciclo sin fin y las entregas terminan quedando sin contenido, ya que prácticamente todo se queda siempre para la versión posterior, por lo que la gestión de las expectativas de los usuarios y clientes puede llegar a ser complicada si no se gestiona por medio de una comunicación y planificación clara. Con la adecuada comunicación y gestión de expectativas es un modelo muy útil para ir avanzando en la construcción de sistemas complejos de forma paulatina.

En el próximo post les hablaré de la evolución de los ciclos de vida de desarrollo de software: Ciclo de vida en espiral y sus variantes RAD y RUP

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

5.- Modelo de Madurez para el Desarrollo de Software

En el caso del proceso de Desarrollo de Software, uno de los estándares más aceptado dentro de la industria es un modelo de madurez, denominado CMMI (Software Capability Maturity Model), creado por Software Engineering Institute (SEI). El CMMI describe una serie de niveles que pueden alcanzarse en el desarrollo de software y en el que las empresas y organizaciones pueden certificarse:

• Nivel 1: Inicial (anárquico)
• Prevalece la anarquía, cada uno hace lo que quiere o puede, y tiene sus propias soluciones.
• Los programadores o desarrolladores se consideran artistas creativos no sujetos a reglas.
• El trabajo se realiza, pero de forma no controlada y en general poco eficiente.
• Es asumido por la empresa en que las cosas (actividades) son conocidas, pero no saben o no quieren cambiarlas.
• Es la situación en la que se encuentran la mayoría de las empresas y organizaciones.

• Nivel 2: Gestionado (repetitivo)
• La empresa ha logrado estabilizar un nivel repetitivo de control basado en compromisos, costos y cambios.
• Se asume que lo que se viene haciendo es correcto, sin intentar cambiarlo todo, aunque ahora está organizado de forma que es repetible.
• Todo está bien mientras no haya “perturbaciones”.
• Se usan métodos de comunicación no formal, permitiendo la subjetividad, pero haciendo más clara la ejecución de actividades.

• Nivel 3: Definido
• Su base es aprovechar los procesos que funcionan mejor.
• La empresa identifica el diseño, prueba, inspección, gestión, control de configuración y otros procesos que mejor funcionalmente en proyectos diferentes, y los integra para en el desarrollo de forma estable.
• Se entrena a toda la organización para que el personal tenga una referencia común de lo aprendido en proyectos anteriores y no tiene que reinventar los métodos de trabajo cada vez.

• Nivel 4: Gestionado de forma cuantitativa (administrado)
• La administración involucra los costos (cualitativos y cuantitativos) y la planificación de los procesos.
• La administración busca una mejora significativa de calidad.
• Se establece la medición detallada los procesos de desarrollo de software, que son asociados con los procedimientos, normas y estándares.

• Nivel 5: Optimo (mejora continua)
• La empresa tiene las bases para una mejora continua y busca optimizar cada vez más sus procesos de desarrollo de software.
• Se basa en el uso intensivo de mecanismos de optimización basados en métodos que usan la instrumentación de herramientas y técnicas.
• Se establece un programa formal y permanente de calidad de software y sus procesos.

Son muchas las empresas que han seguido este modelo para la mejora de sus procesos de desarrollo. No obstante, como en muchas otras ocasiones, la certificación en CMMI no garantiza el éxito en todos los proyectos. Algunos clientes se quejan de que sus proveedores con certificación CMMI también cometen errores, si bien, tienen que reconocer, que existen mecanismos y procedimientos para gestionar y resolver estos problemas y no es necesario improvisar soluciones basada exclusivamente en el esfuerzo y pericia personal.

La implantación de CMMI y su certificación no están al alance de cualquier organización y en general son empresas y departamentos relativamente grandes los que pueden abordar todos los procedimientos, normativas y herramientas que se  exigen para ir avanzando en los diferentes niveles, además del coste económico que supone la certificación.

Les recomendamos que lean el post IEDGE – Métodos y sistemas para asegurar la calidad de software en http://blog.iedge.eu/tecnologia-sistemas-informacion/erp-crm-scm/juan-carlos-melendez-metodos-y-sistemas-para-asegurar-la-calidad-de-software/

Para más información sobre CMMI también pueden consultar http://www.sei.cmu.edu/cmmi/

6.- Estándar para la Gestión de Proyectos

La gestión de proyectos no es una característica exclusiva del desarrollo de software o de los departamentos de TI. Más bien al contrario, es un tipo de gestión que realiza prácticamente todas las empresas, organizaciones y personas alguna vez en su vida.

Sectores como el de la construcción o la ingeniería son grandes “usuarios” de la gestión de proyectos. El desarrollo de software, o la implantación de Sistemas de Información también. Quizás, por su carácter inmaterial, los proyectos informáticos tienen algunas características especiales, ya que es más complicado entender su funcionamiento, evolución, diseño y en ocasiones su funcionamiento. Es por ello, que los proyectos relacionados con las Tecnologías de la Información son en general más complejos y difíciles de llevar a cabo.

Desde los años 50 se ha venido desarrollado una serie de técnicas, herramientas y metodologías para la gestión de los proyectos. Desde los sencillos y ampliamente utilizados Diagramas de Gantt, hasta los más sofisticados métodos de medición del rendimiento de los proyectos, disponemos de una gran cantidad de ayudas para la gestión de proyectos.

No obstante, los jefes de proyectos siguen afrontando un gran reto, dada la gran cantidad de elementos que tienen que tener en cuenta en su trabajo y no siempre cuentan con la formación y experiencia necesarias para abordarlos con éxito. Esta es, sin duda alguna, una de las principales causas de fracaso de los proyectos: la falta de preparación y capacidad de los jefes de proyecto.

El Project Management Body of Knowledge (PMBOK), desarrollado por el Project Management Institute (PMI) es una guía de fundamentos para la Dirección de Proyectos, de cualquier tipo y característica, que describe de forma precisa los conocimientos y herramientas que necesita conocer todo jefe de proyecto para poder abordar la tarea que le ha sido encomendada.

La guía del PMBOK define 9 áreas de conocimiento en las que agrupa cada una de las actividades, que van desde la Gestión Integrada del Proyecto, a las cuatro funciones principales (Gestión del Alcance, Gestión del Tiempo, Gestión del Coste y Gestión de la Calidad) y las cuatro auxiliares (Gestión de los Recursos Humanos, Gestión de la Comunicación, Gestión de Riesgos y Gestión de Compras):

Ilustración 1: Áreas de Conocimiento (PMBOK)

 A su vez, el PMBOK describe un ciclo de vida del proyecto (que no debemos confundir con las fases o etapas de cada proyecto) que incluye inicio, organización-planificación, ejecución y cierre. Este ciclo de vida se puede realizar una sola vez en todo el proyecto, o en cada fase o etapa:

Ilustración 2: Ciclo de Vida del Proyecto (PMBOK)

 Por cada una de las áreas de conocimiento y cada una de las etapas del ciclo de vida del proyecto el PMBOK define unas entradas, unas herramientas y técnicas que podemos utilizar y unas salidas que debemos generar, estableciendo de esta forma un completo mapa de los procesos que intervienen en la gestión de un proyecto.

Ilustración 3: Ejemplo de proceso (PMBOK)

El carácter generalista del PMBOK hace que sea aplicable a una gran cantidad de proyectos, tanto de desarrollo de sistemas informáticos, como de ingeniería, construcción, marketing o gestión empresarial, por lo que se ha convertido en una de las referencias más difundidas y utilizadas en la gestión de proyectos.

Como en otros casos, la certificación de un jefe de proyecto en PMBOK no garantiza el éxito en su gestión, pero nos asegura que dispone de unos conocimientos básicos para abordar la complejidad que supone la gestión de proyectos, y ofrece a las organizaciones y empresas un marco general de referencia sobre el que definir sus metodologías de gestión de proyecto, adaptadas a cada material y necesidades concretas.

Para más información sobre PMBOK les recomendamos que lean la nota técnica de esta signatura, así como los siguientes post, donde abordaremos con más detalle algunas de sus áreas.

Para más información sobre CMMI también pueden consultar http://www.pmi.org/

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

Cuando miles de empresas y organizaciones en cientos de países se encuentran con los mismos problemas en la gestión de sus los Proyectos Informáticos y en general con la gestión de las Tecnologías de la Información, uno se pregunta si no existirán soluciones ya probada y suficientemente extendida como para que no tengamos que “inventarnos” nosotros una solución desde cero.

La buena noticia es que existen buenas prácticas y estándares para la Gestión de Proyectos, Gestión de los Servicios y en general para la Gestión de los Departamentos de TI. La mala noticia es que no hay un solo estándar, hay prácticamente cientos.

Ilustración 1: Estándares relacionados con la Gestión de las Tecnologías de la Información

En este gráfico se recoge de forma sucinta algunos de los estándares más difundidos que tienen relación con la gestión de TI, desde estándares de calidad como TQM o 6 Sigma que son aplicados en empresas y departamentos de informática como medio de mejora, a sistemas de control empresarial como SOX en Estados Unidos o BASILEA en Europa que van incorporando cada día más controles operativos que afectan a TI; pasando por estándares de gestión o Gobierno de TI como función específica dentro de las empresas como VALIT o ISO38500; siguiendo por estándares de Auditoría Informática como COBIT; guías de Gestión de Servicios de TI como ITIL o de Madurez en el Desarrollo como CMMI; hasta llegar a marcos de referencia para la Gestión de Proyectos (no necesariamente informáticos) como PMBOK o PRINCE2, o metodologías orientadas al Desarrollo de Software como RUP o SCRUM.

Sólo dar un vistazo a este tipo de cuadro produce bastante desconcierto, he incluso un poco de vértigo. Todos desearíamos que fuera más sencillo, que hubiera una norma, una guía o un estándar que todos pudiéramos seguir y de esta forma garantizar el éxito de nuestros proyectos.

La realidad es que no existe una respuesta sencilla y además, hay muchas organizaciones más o menos interesadas en darnos una respuesta. Debemos entender que detrás de todo estándar, guía o norma existen una gran cantidad de certificaciones, cursos y servicios que hacen ganar dinero a bastante gente. Muchas de estas guías, normas y estándares son útiles, pero también esconden ciertos costes que debemos pagar para poder aprovecharlas.

Para complicarlo un poco más, algunos de estos estándares y normativas han producido casos de burocratización excesiva de la gestión, cargando de documentos y controles los procesos, pero sin producir realmente un efecto realmente significativo sobre el éxito de los proyectos.

Vamos a intentar despejar un poco este mare magnum de siglas y veamos algunos de los estándares y normativas más extendidas y más útiles de las que se utilizan en los diferentes niveles de Gestión de los Sistemas y Tecnologías de la Información, desde el Gobierno de TI hasta la Gestión de Proyectos.

2.- Estándares para el Gobierno de TI

El Gobierno de las Tecnologías de la Información o Gobierno de TI es, según el IT Governance Institute (ITGI), es el conjunto de herramientas y métodos “que ayuda a la Alta Gerencia asegurar que la organización obtenga un óptimo valor de sus inversiones de negocio relacionadas a TI, a un costo manejable y bajo un nivel de riesgo aceptable”. Es por lo tanto el gobierno de más alto nivel de la gestión de las tecnologías de la información, aquel que permite alinear los objetivos de negocio y los objetivos de la empresa.

Entre los estándares que han surgido en este nivel de Gobierno de TI podemos destacar VALIT, creado por el ITGI, y que organizar el conjunto total de prácticas de la dirección de TI en tres áreas:

• Gobierno del Valor (GV): establece el marco de trabajo general, la dirección estratégica de TI, las características deseadas del portafolio de inversiones, así como las restricciones y limitaciones aplicables para decidir las inversiones.
• Gestión de la Inversión (IM): basándose en los requerimientos del negocio, se definen los programas de inversión y se realiza una valoración de los mismos para determinar si son enviados al proceso de gestión de portafolios para su evaluación, evaluando su alineamiento a la objetivos estratégicos, su nivel de riesgo y la generación de valor para el negocio.
• Gestión del Portfolio (PM): se evalúa y prioriza los proyectos basándose en las restricciones de recursos y costos, e incorpora los proyectos seleccionados al portafolio (cartera) de proyectos activos de la compañía.

Recientemente se ha publicado un estándar ISO sobre el Gobierno de TI, la ISO/IEC 38500:2008 – IT Governance Standard. Esta norma agrupa una gran cantidad de estándares dispersos y ofrece un marco general de referencia para la dirección de los Sistemas de Información y la Tecnologías de la Información en las empresas y organizaciones, que está teniendo una gran acogida en el mercado.

Ilustración 2: Esquema de la ISO/IEC 38500:2008 (fuente AENOR)

 Para más información sobre VALIT pueden consultar www.itgi.org/valit/index.html

Para más información sobre ISO/IEC 38500:2008 pueden consultar http://www.38500.org/ y http://www.iso.org/iso/catalogue_detail?csnumber=51639

 3.- Estándar para la Auditoría de TI

El estándar más ampliamente difundido y utilizado para la Auditoría de TI es COBIT, creado por la ISACA. Está guía va mucho más allá de la auditoría, y de hecho es utilizada por muchas organizaciones como una guía de buenas prácticas en la Gestión de los Sistemas y las Tecnologías de la Información.

La guía de COBIT es realmente completa, además de ser muy madura (ya se ha publicado su versión 5). Cubre prácticamente todos los aspectos que se deben tener en cuenta para una correcta gestión de los Sistemas y Tecnologías de la Información en una empresa u organización.

Ilustración 3: El Cubo de COBIT (fuente ISACA)

 Para más información sobre COBIT pueden consultar http://www.isaca.org/COBIT

4.- Estándar para la gestión de los servicios de IT

Si vamos “descendiendo” dentro de las actividades de gestión de los departamentos de TI, nos encontramos que prácticamente la totalidad de sus procesos pueden ser descritos como servicios que prestan estos departamentos al conjunto de la empresa. Siguiendo esta orientación a servicios fue creado ITIL (Information Technology and Infraestructure Library) por la Central Computer and Telecommunications Agency (CCTA) del Gobierno Británico.

Este es un estándar ampliamente reconocido para la gestión de los servicios de TI, orientado a conseguir un alto nivel de disponibilidad de dichos servicios y un alto nivel de satisfacción de clientes y usuarios de estos servicios.

Los procesos ITIL están alineados con el estándar de calidad ISO 9000 y se encuentran vinculados con el Modelo de Excelencia de la EFQM (European Foundation for Quality Management), además de haber sido adoptados por el estándar ISO 20000.

Les recomendamos que lean el post “IEDGE – Fundamentos de la Gestión TI” en http://blog.iedge.eu/tecnologia-sistemas-informacion/erp-crm-scm/carlos-melendez-fundamentos-de-la-gestion-ti/ donde se hace una descripción de ITIL.

Para más información sobre ITIL también pueden consultar http://www.itil-officialsite.com/

En el siguiente post continuaremos esta descripción de los principales estándares para la Gestión de TI, en concreto veremos CMMI como modelo de madurez en el desarrollo de software y PMBOK como guía para la gestión de proyectos.

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

Los sistemas informáticos se han ido haciendo cada vez más amigables y sencillos para los usuarios. La curva de aprendizaje en el uso de los sistemas informáticos es cada vez más suave y cualquier “nativo digital” usa decenas de sistemas sin dificultad. Incluso los usuarios menos avanzados son capaces de hacer trabajos bastante complejos con herramientas cada vez más intuitivas.

La apariencia de sencillez esconde una cada día mayor complejidad. Los informáticos tienen que integrar de forma eficiente y sin errores una gran cantidad de sistemas operativos, bases de datos, librerías, aplicaciones, servicios, infraestructuras, etc.

La informática, lejos de ser una ingeniería madura y académica, está dominada por una frenética evolución y cambio. Esta evolución se ve acelerada por un mercado tecnológico de crecimiento exponencial, que no para de lanzar al mercado versiones y productos nuevos que sustituyen los sistemas existentes y los hacen rápidamente obsoletos.

Ilustración 1: Ilusión de simplicidad

 En ocasiones, sobre todo cuando se producen errores, la ilusión de simplicidad se rompe y se puede percibir la complejidad oculta que hay tras los más o menos ergonómicos y amigables sistemas que utilizamos en nuestra vida cotidiana y en nuestros trabajos y empresas.

La construcción de los Sistemas de Información y en general la gestión de las Tecnologías de la Información es un trabajo difícil, que debe ser capaz de compaginar la comprensión de las necesidades del usuario con la complejidad interna de la tecnología.

2.- El caos de los proyectos informáticos

Todo el que ha trabajado con equipo informáticos o de desarrollo de software sabe lo poco fiables que son sus estimaciones en cuanto a tiempo y esfuerzo, así como lo poco convincentes son sus promesas sobre la funcionalidad que tendrán los sistemas y sabe cómo muchos requisitos serán siempre implementados en la “siguiente versión”.

En la práctica el desarrollo de software es una actividad muy artesanal, que depende principalmente de la capacidad de las personas que lo construyeron y por ese mismo motivo terminan siendo necesarias para su mantenimiento y evolución. Aunque parezca sorprendente, en el desarrollo de software parece que se utiliza más el ingenio que la ingeniería.

Esta situación de caos en la construcción de software es lo que se ha denominado “LA CRISIS DEL SOFTWARE”. Desde los años 70 se viene hablando de esta crisis y aun no se ha resuelto. Otras actividades de TI, como el hardware o las comunicaciones, no han sufrido una crisis tan profunda y compleja, pero el desarrollo de software sigue siendo el mayor y más difícil problema al que se enfrentan de los directores de SI/TI.

The Standish Group publica desde 1994 el denominado Chaos Report, donde muestra el resultado de las encuestas que realiza a una gran cantidad de empresas de diferentes tamaños sobre el éxito de sus proyectos informáticos. Los datos son impresionantes:

Ilustración 2: Chaos Report – The Standish Group, 2004, 2006, 2009

 En 2009 poco menos del 25% de los proyectos no terminan, es decir, son cancelados y todos los esfuerzos realizados son dados como pérdida para la empresa (sin contar el coste de oportunidad que estas cancelaciones pueden suponer). Más del 40% de los proyectos no han cumplido plazos, coste o alcance. Sólo el 32% de los proyectos terminan dentro de unos márgenes razonables de éxito.

A esta situación habría que añadirle los defectos del software, es decir, cuantos errores aparecieron tras la puesta en marcha del sistema. La calidad del software, como efecto colateral, se ve afectada en gran medida por las presiones para cumplir plazos, costes o alcance. ¿De qué nos sirve un sistema informático entregado en plazo, coste y  alcance si está lleno de errores que nos impiden trabajar?

Parece que el caos se ha apoderado en gran medida de los proyectos informáticos.

3.- ¿Qué podemos hacer?

Desde luego no debemos resignarnos a esta situación y debemos hacer todo lo que esté en nuestra mano para que los proyectos informáticos de nuestras empresas se sitúen en el porcentaje de proyectos de éxito. No es imposible, es necesario aplicar las mejores prácticas y un poco de organización para que podamos aumentar de forma drástica la calidad nuestros proyectos.

Para ello vamos a revisar dos grandes líneas:

• La gestión de proyectos
• La ingeniería de software

Cualquier proyecto conlleva una gran cantidad de problemas y riesgos. El carácter único de cada proyecto hace que no podamos aplicar con facilidad procesos estandarizados que nos garanticen la consecución de nuestros objetivos. La problemática de gestión de proyectos no es exclusiva de los proyectos informáticos y es compartida por todos los proyectos empresariales, e incluso de la vida cotidiana. Todos hemos participado en algún proyecto y  seguramente tenemos experiencia de lo difícil que es planificar, ejecutar y controlar todos los aspectos que intervienen.

Afortunadamente las mejores prácticas en la gestión de proyectos se han reunido en METOLODOGÍAS Y ESTÁNDARES DE GESTIÓN DE PROYECTOS, que podemos seguir para facilitar su gestión. De estas metodologías y estándares vamos a tratar en los próximos post.

Para intentar paliar los problemas específicos de la construcción de software se ha intentado aplicar técnicas y métodos propios de la ingeniería, creando la INGENIERIA DEL SOFTWARE. El IEEE Std 610.12-1990 Standard Glossary of Software Engineering Terminology define la ingeniería de software como: “La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, la operación y el mantenimiento del software”.

No se asusten, no vamos a tratar aquí de los aspectos técnicos de esta ingeniería de software, solo trataremos algunos aspectos generales que combinados con la gestión de proyectos nos pueden ayudar a tener un mayor éxito en nuestros proyectos informáticos.

4.- Propuesta

Les invito a realizar un ejercicio de análisis y valoración de la los proyectos relacionados con las tecnologías de la información en sus respectivas empresas, especialmente de aquellos que han tenido problemas y dificultades. En especial les pido que respondan a las siguientes preguntas:

• ¿Qué tipo de problemas han surgido? ¿coste? ¿alcance? ¿plazo? ¿calidad?
• ¿Cuáles creen que han sido las causas de estos problemas?
• ¿Qué coste ha tenido para la empresa estos problemas?

¡Quedo a la espera de sus comentarios!

Pablo Almunia

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

Dos grandes cambios se han producido desde los inicios de Internet:

1.- ¿Qué están haciendo las empresas que están triunfando en la era de la Web 2.0?

Vamos a repasar  lo que están haciendo las empresas que están triunfando en la era de la Web 2.0, empresas como Google, Amazon, Ebay, Facebook, Twitter, Wikipedia…

• Fomentan la participación de los usuarios: puesto que los usuarios crean la mayor parte de los contenidos, es una buena estrategia fomentar al máximo su participación en nuestra web.
• Desarrollan aplicaciones dirigidas por los datos: es vital conseguir una masa crítica de datos clave de los usuarios: identidad, dirección, localización, gustos, preferencias…, para convertir su actualización, agregación y segmentación en un servicio. Esta estrategia es seguida por empresas como eBay y Amazon en el comercio electrónico, o Facebook o Twitter en las redes sociales. El valor de los servicios que prestan se mide por la escala y el dinamismo de los datos que gestionan.
• Convierten a los usuarios en co-desarrolladores: conseguir que los usuarios colaboren en la mejora de los contenidos y servicios, haciéndoles sentir que sus contribuciones y opinión importan. Como consecuencia, servicios como Gmail, Google Maps, Flickr, del.icio.us…, se encuentran un estado de “Beta continua” incorporando de forma permanente mejoras sugeridas por los usuarios.
• Aprovechan la inteligencia colectiva: la suma de interacciones de los usuarios con nuestra web aporta información sobre que contenidos o servicios tienen más éxito, o sobre cuáles son los más adecuados para su perfil. Esto permite establecer mecanismos automáticos de ponderación y recomendación, tal y como hace Google (Pagerank) y Amazon (Customers who bought this item also bought).
• Desarrollan aplicaciones multi-dispositivo: los contenidos y servicios deben desarrollarse pensando en su posible ejecución en múltiples dispositivos (iPad, iPhones, Smarphones…).

2.- La teoría de la larga cola (Long Tail)

Por último, vamos a examinar el concepto de “Long Tail” otra importante forma entender cómo ha cambiado la forma de comercializar productos en la era de la Web 2.0.

La teoría de la larga cola defiende que nuestra cultura y nuestra economía cada vez se apartan más de la concentración en un número relativamente reducido de éxitos (productos y mercados principales) situados a la cabeza de la curva de la demanda y se orienta más hacia una elevada cantidad de nichos situados en la cola. El término hace referencia concretamente a un gráfico de ventas que muestra una curva de demanda estándar que se podría aplicar a cualquier sector, desde el del ocio hasta el de los bienes de equipo (véase la ilustración 1). El eje vertical son las ventas; el eje horizontal son los productos. La parte azul oscuro de la curva son los éxitos, que han dominado nuestros mercados y nuestra cultura durante la mayor parte del siglo pasado. La parte azul claro son los productos que no son éxitos, es decir, los nichos, que es de donde va a provenir el nuevo crecimiento en el presente y en el futuro.

Ilustración 1: Long Tail

 Los principios económicos tradicionales de la venta minorista determinan que los establecimientos únicamente deben tener en existencias los probables éxitos, dado que el espacio en estantería es caro. Sin embargo, los minoristas on-line, desde Amazon a iTunes, pueden tener en existencias prácticamente todo, y la cantidad de productos nicho disponibles supera con creces a la de productos de éxitos. Lo mismo cabe decir de los vídeos que no están disponibles en una emisión televisiva un determinado día y de las canciones que no suenan en la radio.

Cuando se ofrece a los consumidores una selección infinita, queda de manifiesto la verdadera forma de la demanda. Y resulta que se trata de una forma menos centrada en los éxitos de lo que pensábamos. El su libro The Long Tail, Chris Anderson explica las consecuencias generales de esta realidad: de qué modo nuestra economía y nuestra cultura se están desplazando desde los mercados de masas hacia los millones de nichos. Describe el efecto de las tecnologías que han hecho que a los consumidores les resulte más sencillo localizar y adquirir productos nicho, gracias al “efecto del espacio infinito de estantería”: los nuevos mecanismos de distribución, desde la descarga digital hasta los mercados de igual a igual que eliminan los cuellos de botella de las retransmisiones y la venta minorista tradicional del mundo real.

¡Quedo a la espera de sus comentarios!

Gregorio Cortés

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: Para aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

1.- IP – El alimentador de datos de Internet

El protocolo IP (Internet Protocol) es la base de todas las comunicaciones en Internet. Siempre que accedemos a través de nuestro navegador a la página web de una organización, el proceso de comunicación se realiza a través del  protocolo IP, que define el intercambio de paquetes de datos entre el ordenador y los routers.

El protocolo IP define las siguientes reglas para la comunicación entre ordenadores en Internet:

• Direccionamiento IP: es un mecanismo de direcciones que permite identificar, de forma clara, al emisor y al receptor de un paquete de datos. (ej. 193.110.128.0 – www.elmundo.es).
• Enrutamiento: mecanismo para el transporte de los paquetes de datos, para que se curse por las diferentes redes a través de los nodos, y recorrer así el camino entre el emisor y el receptor. Un router transmite siempre un paquete de datos a otro router, algo más cercano al ordenador de destino qué este mismo.
• Formato de los paquetes de datos: coloca delante de cada paquete de datos una cabecera con la información de las direcciones del emisor y del receptor.

2.- TCP – Transporte seguro

Los paquetes IP permiten, al software de Internet, enviar datos a ordenadores remotos pero no representan un canal de comunicación seguro. Si los paquetes llegan al destinatario o si este los recibe incompletos o en el orden equivocado, es algo que el remitente no llega a saber. Pero como las aplicaciones de Internet dependen de un canal de comunicación seguro y fiable de uno a otro extremo,  el TCP (Transport  Control Protocol) forma parte indisoluble de Internet.

El protocolo TCP incorpora tres mecanismos claves para asegurar la comunicación entre ordenadores:

• Número de secuencia: a cada paquete de datos se la añade un número de orden que permite tanto ordenar los mismos en el  ordenador de destino como detectar duplicados
• Checksum: a cada paquete se le añade una información de control o comprobación (obtenida a partir de la suma de la información recibida) que permite establecer si la información recibida es o no correcta.
• Asentimientos (Acknowledge): envíos de confirmación del receptor al remitente (conforme o no conforme) sobre la correcta recepción del paquete de datos.

Ilustración 1: Esquema confirmación entre emisor  y receptor

3.- DNS – Agenda de Internet

Domain Name Server es la agenda de direcciones de Internet. Proporciona las direcciones de los ordenadores conectados y se encarga de la organización de esta enorme red compuesta por millones de participantes. El DNS contiene la correspondencia entre direcciones IP y nombre propio en forma de texto.  De esta forma, sólo tenemos que recordar el nombre de un cierto dominio, como por ejemplo www.elpais.com, en lugar de su dirección IP 194.169.201.203. Cada vez que introducimos el nombre de un dominio, el navegador contacta con un servidor DNS para que le traduzca ese nombre en una dirección IP.

El servidor DNS, ante una petición de este tipo, puede llevar a cabo cuatro acciones diferentes:

• Contestar con la dirección IP porque sabe cuál es.
• Contactar con otro servidor DNS para que averigüe la dirección IP del dominio solicitado, y que él desconoce.
• Contestar que no conoce esa dirección IP, pero facilitando la IP de otro servidor DNS que tenga más información.
• Devolver un mensaje de error porque el nombre del dominio requerido, simplemente, es inválido o no existe.

El DNS es una base de datos diseminada entre numerosos servidores DNS, es decir, que cada servidor DNS conoce la correspondencia entre direcciones IP y nombres de dominio de un determinado ámbito (por ejemplo el DNS de nuestro proveedor las direcciones IP de los dominios pertenecientes a su red). Cuando introducimos el nombre de un dominio nuestro navegador consulta al DNS de nuestro proveedor y si este no conoce la IP del dominio consultado, el mismo se encarga de consultar a otro DNS de nivel superior para averiguarla y contestar al DNS original. La resolución final de la IP del nombre del dominio puede conllevar consultas entre DNS varios niveles por encima del DNS inicial.

4.- HTTP – El protocolo de la Word Wide Web

Hypertext Transfer Protocol o HTTP es el protocolo usado en cada transacción de la World Wide Web. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor.

Al cliente que efectúa la petición (un navegador web o un spider) se lo conoce como “user agent”. A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc

5.- Así funciona la Web

Por muy variada y colorida que se presente la World Wide Web, en el fondo el sistema está basado en tres conceptos fundamentales:

• HTTP: como mecanismo de entendimiento entre el programa cliente, que es que llama las páginas y elementos de la World Wide Web, y el programa servidor, que es quien proporciona, a petición del cliente, estos elementos.
• HTML (Hypertext Markup Language): como lenguaje de descripción y formato para que las páginas de la World Wide Web. Es un lenguaje descripción de páginas de la Web que ha sido creado en función de las posibilidades específicas de la representación online.
• URLs (Uniform Ressource Locators): como mecanismo estándar para dar nombre a las páginas y elementos de la World Wide Web, asignándoles un título y una ruta de acceso unívocos. Son el requisito imprescindible para formular, dentro de las páginas HTML, referencias a cualquier servidor de la Web y sus contenidos.

Entre estos tres elementos hay una estricta división del trabajo. HTTP es el responsable de transferir los contenidos del servidor al cliente, HTML se encarga de la representación y los URL de formular direcciones de manera única.

¡Quedo a la espera de sus comentarios!

Gregorio Cortés

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: Para aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

Vamos a explicar lo que pasa cuando se conectamos desde nuestro ordenador a la página de Internet que queremos visitar. El primer paso consiste, en la mayoría de los casos, en que nuestro proveedor de acceso nos asigne una dirección IP libre entre las muchas de las dispone. Si nuestro proveedor trabaja con DCHP, junto con la dirección IP, nos comunicará inmediatamente los datos necesarios para el DNS y otros tipos de servidores.

Una vez asignada la dirección IP, la comunicación empieza al reconocerse entre sí los dos ordenadores (el nuestro y el servidor de nuestro proveedor de Internet). El protocolo TCP/IP empieza a empaquetar datos a transmitirlos a través de la conexión Ethernet, Wi-Fi…, de nuestra red local (LAN). En el otro extremo de la línea se “desempaquetan” los datos, se analizan y se continúa su procesamiento.

Supongamos que hemos comenzado con una ventana en blanco de navegador vacía en la pantalla e introducimos: www.iedge.eu. A continuación, la red intenta encontrar en qué rincón del mundo se encuentra el servidor de IEDGE, es decir,  cual es su dirección IP. Para ello, en el servidor de nuestro proveedor está en marcha el programa servidor DNS (Domain Name Server). Este programa averigua la dirección IP de www.iedge.eu y se la comunica al navegador. Cuando el DNS no puede averiguar por sí mismo la dirección IP, recurre a una instancia superior (otro DNS).  En último término, no sabemos de qué servidor DNS proviene la respuesta con la dirección IP, pero si al conectarse una segunda vez todo el proceso va más rápido, podemos estar casi seguros de que el DNS a tenido que preguntar a otro DNS y la respuesta se encuentra todavía guardada en un caché.

Después de comunicarle la dirección al navegador,  se cambia al protocolo HTTP y se busca un servidor HTTP activo que corresponda a la dirección trasmitida por el puerto 80. Para llegar hasta el servidor HTTP, los routers van enviando paquetes de datos, de una red a otra, hasta alcanzar el ordenador destino de la red destino. Una vez establecida la conexión, IEDGE envía datos a nuestro navegador. Los primeros bytes que recibe el navegador contienen el texto  <html>, que le permiten saber que el formato del contenido que debe interpretar es del tipo html.

La conexión a la página de IEDGE haya sido posible gracias a la intervención de los cuatro protocolos básicos para el funcionamiento de internet: IP, TCP, DNS y HTTP, más un quinto necesario para el funcionamiento de nuestra red local: Ethernet.

 Ilustración 1: Pila de protocolos de Internet

Estos cinco protocolos actúan en cuatro capas o niveles técnicos diferentes. Esta división en niveles es propia de los estándares de comunicaciones y sirve para dividir las responsabilidades y funciones necesarias para la comunicación, entre diferentes protocolos. En el próximo post les contaré en qué consisten cada uno de estos protocolos.

¡Quedo a la espera de sus comentarios!

Gregorio Cortés

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: Para aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool

1.- Concepto de cadena de suministro

La cadena de suministro se define como el conjunto de procesos a través de los cuales fluyen los productos desde los proveedores hasta los clientes finales, pasando por la propia empresa, por almacenes propios o ajenos, distribuidores… Esta definición se completa incluyendo la parte más “dinámica” de la cadena, que va más allá del mero flujo de materiales: los servicios, el dinero y, por supuesto, la información.

Los principales eslabones de toda cadena se suministro son:

• Proveedores: están al principio de la cadena de suministro. Según el tipo de empresa y el producto que elabore, el entramado de proveedores puede llegar a ser bastante complejo.
• Producción: una vez que la empresa dispone de la materia prima y los componentes necesarios, comienza el proceso de producción que los transformará en el producto final. Deben tenerse en cuenta todos los procesos relacionados con el empaquetamiento y almacenamiento de productos acabados.
• Distribución: es parte de la cadena de suministro relacionado con el transporte y entrega del producto a los clientes. Como es lógico, existe la posibilidad de que el producto no se entregue directamente al cliente final y existan intermediarios.
• Clientes: son el último eslabón de la cadena en productos de consumo son los consumidores finales. Aunque la empresa no les venda directamente a ellos, un estudio de la cadena de suministro no estará completo hasta que se contemplen todos los procesos que permiten que el producto llegue al usuario final.

Ilustración 1: Flujos simplificados en una cadena de suministro

2.- Componentes de un sistema de gestión de la cadena de suministro

Los componentes básicos de un sistema de gestión de la cadena de suministro suelen ser los siguientes:

• Planificación de la producción: existen multitud de algoritmos de optimización para la planificación de la producción de la empresa en función de sus características, del sector en el que opera y de la demanda esperada. El problema inherente a estos componentes es la necesidad de fijar de antemano la cantidad de producto a producir. Existen muchas empresas que pueden obtener de sus clientes la información sobre lo que van a comprar en el futuro, aunque no se lo dicen con anticipación suficiente para poder producir bajo demanda. Es muy beneficioso establecer una relación fluida con los clientes que permita el intercambio de información desde el mismo momento en que esta está disponible ya que esto conlleva enormes ahorros para  el proveedor y un mejor servicio para el cliente (ej. http://es.wikipedia.org/wiki/Dell). Para situaciones en las que es inevitable realizar previsiones, existen modelos estadísticos en el mercado que permiten realizar una estimación de la demanda en función de información histórica (ej. http://www-01.ibm.com/software/es/analytics/spss/)
• Relación con proveedores: un sistema SCM permite automatizar la relación con los proveedores: comunicación de pedidos, verificación de cantidades, situación de las mercancías, enlace con transportistas…
• Producción: permite el control del proceso productivo con actividades como el aseguramiento de la calidad, el empaquetamiento de los productos y la preparación para el transporte.
• Distribución o logística: controla el transporte, la red de almacenes, la entrega de los productos (ej. estantería de un detallista).
• Gestión de quejas y devoluciones: integrados con los sistemas CRM (que veremos en el próximo post), el SCM gestiona la devolución de pedidos defectuosos o en exceso.

3.- Beneficios de los sistemas de gestión de la cadena de suministro

De forma general, un sistema SCM correctamente implementado debería aportar los beneficios siguientes:

• Mejora del servicio al cliente: recibe los productos que desea en el momento en que los necesita
• Reducción de ventas perdidas
• Reducción de costes de mantenimiento y depreciación de inventario
• Mejora en el flujo de caja por entregar y facturar antes los pedidos
• Reducción del coste por tratamiento de pedidos urgentes
• Reducción de costes por obsolescencia
• Aumento de la eficiencia de las transacciones con los partners
• Disminución de la edad media del pedido servido.

4.- Factores críticos de éxito en la implantación de un sistema integrado

Al igual que sucedía en el caso de los ERP, la implantación de un SCM es un proceso de gran envergadura para cualquier organización. Los factores críticos comentados en el anterior post para la correcta implantación de un ERP son completamente aplicables para aquí.

¡Quedo a la espera de sus comentarios!

Gregorio Cortés

Profesor de Dirección de Sistemas y Tecnologías de la Información

Nota: Para aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información

* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.

¡Pronto grandes sorpresas en Facebook y Twitter!:

• Síguenos en Twitter: @iedge
• Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool