Los Ciclos de Vida del Software (I)

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

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

Ciclo de vida en CASCADA ("Waterfall")

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


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

Ciclo de vida INCREMENTAL

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


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

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

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

¡Facebook quiere comprar Twitter!

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

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

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

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

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

Open Social

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

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

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

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

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

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

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

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

Recomendaciones para el Diseño

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

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

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

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

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

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

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

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

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

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

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

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

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

Beneficios de tener un CRM:

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

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

Patrones de Diseño UML (II)

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

Descripción de los patrones

Patrones de creación

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

Patrones estructurales

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

Patrones de comportamiento

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

Un ejemplo de uso

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

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

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

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

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

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

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

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

¿Cómo lo hacéis vosotros?