Sistemas heredados

 

Un sistema heredado (o sistema legacy) es un sistema informático (equipos informáticos o aplicaciones) que ha quedado anticuado pero continúa siendo utilizado por el usuario (típicamente una organización o empresa) y no se quiere o no se puede reemplazar o actualizar de forma sencilla.

Las compañías gastan mucho dinero en sistemas informáticos y, para obtener un beneficio de esa inversión, el software o el hardware debe utilizarse varios años. El tiempo de vida de los sistemas informáticos es muy variable, pero muchos sistemas grandes se pueden llegar a utilizar hasta más de 20 años. Muchos de estos sistemas antiguos aún son importantes para sus respectivos negocios, es decir, las empresas cuentan con los servicios suministrados por estos sistemas y cualquier fallo en estos servicios tendría un efecto serio en el funcionamiento de la organización. Estos sistemas antiguos reciben el nombre de sistemas heredados.

Lo habitual es que los sistemas heredados, los que ya suponen un problema para una empresa u organización por la dificultad para sustituirlos, no sean los mismos sistemas que originalmente se empezaron a utilizar en la empresa. Muchos factores externos e internos, como el estado de las economías nacional e internacional, los mercados cambiantes, los cambios en las leyes, los cambios de administración o la reorganización estructural, conducen a que los negocios experimenten cambios continuos. Estos cambios generan o modifican los requerimientos del sistema de información, por lo que éste va sufriendo cambios conforme cambian los negocios. Por esta razón, los sistemas heredados incorporan un gran número de actualizaciones hechas a lo largo de su vida útil. Muchas personas diferentes pueden haber estado involucradas en la realización de estas modificaciones a lo largo del tiempo, y es inusual para cualquier usuario o administrador del sistema tener un conocimiento completo del mismo, sobre todo cuando éste tiene una cierta envergadura.

Publicado en Uncategorized | Deja un comentario

Bases de datos transaccionales y relacionales

Bases de datos transaccionales

Son bases de datos cuyo único fin es el envío y recepción de datos a grandes velocidades, estas bases son muy poco comunes y están dirigidas por lo general al entorno de análisis de calidad, datos de producción e industrial, es importante entender que su fin único es recolectar y recuperar los datos a la mayor velocidad posible, por lo tanto la redundancia y duplicación de información no es un problema como con las demás bases de datos, por lo general para poderlas aprovechar al máximo permiten algún tipo de conectividad a bases de datos relacionales.

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

Base de Datos Relacional 

Es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para implementar bases de datos ya planificadas. Permiten establecer interconexiones (relaciones) entre los datos (que están guardados en tablas), y a través de dichas conexiones relacionar los datos de ambas tablas, de ahí proviene su nombre: “Modelo Relacional”.

Publicado en Uncategorized | Deja un comentario

Diferencias entre Arquitectura y Diseño

Diferencias entre Arquitectura y Diseño

Una vez que se reconoce la diferencia, que nunca debió ser menos que obvia, entre diseño e implementación, o entre vistas conceptuales y vistas tecnológicas ¿Es la AS solamente otra palabra para designar el diseño? Como suele suceder, no hay una sola respuesta, y las que hay no son taxativas. La comunidad de AS, en particular la de extracción académica, sostiene que ésta difiere sustancialmente del mero diseño. Pero Taylor y Medvidovic [TM00], por ejemplo, señalan que la literatura actual mantiene en un estado ambiguo la relación entre ambos campos, albergando diferentes interpretaciones y posturas:

1) Una postura afirma que arquitectura y diseño son lo mismo.
2) Otra, en cambio, alega que la arquitectura se encuentra en un nivel de abstracción por encima del diseño, o es simplemente otro paso (un artefacto) en el proceso de desarrollo de software.
3) Una tercera establece que la arquitectura es algo nuevo y en alguna medida diferente del diseño (pero de qué manera y en qué medida se dejan sin especificar). Taylor y Medvidovic estiman que la segunda interpretación es la que se encuentra más cerca de la verdad. En alguna medida, la arquitectura y el diseño sirven al mismo propósito. Sin embargo, el foco de la AS en la estructura del sistema y en las interconexiones la distingue del diseño de software tradicional, tales como el diseño orientado a objetos, que se concentra más en el modelado de abstracciones de más bajo nivel, tales como algoritmos y tipos de datos. A medida que la arquitectura de alto nivel se refina, sus conectores pueden perder prominencia, distribuyéndose a través de los elementos arquitectónicos de más bajo nivel, resultando en la transformación de la arquitectura en diseño.

Fuente:

Introducción a la Arquitectura de Software
Versión 1.0 – Marzo de 2004
Carlos Billy Reynoso
UNIVERSIDAD DE BUENOS AIRES
Publicado en Uncategorized | Deja un comentario

Patrones de arquitectura vs. Patrones de diseño

La RAE (Real academia española) cita: 

* Patrón: Modelo que sirve de muestra para sacar otra cosa igual.

Patrón de diseño:

Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software. En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios). 

Los patrones de diseño facilitan la reutilización de arquitecturas y diseños de software exitosos.

Patrón de arquitectura:

Son patrones de diseño de software que ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. Dan una descripción de los elementos y el tipo de relación que tienen junto con un conjunto de restricciones sobre cómo pueden ser usados. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. En comparación con los patrones de diseño, los patrones arquitectónicos tienen una nivel de abstracción mayor.

PATRONES DE ARQUITECTURA VS. PATRONES DE DISEÑO

Si queremos creer que realmente existe diferencia, entonces es fácil verla midiendo el impacto al aplicar el patrón: si este es relevante a la totalidad del sistema entonces hablamos de un patrón de arquitectura; en cambio, si este sólo concierne a un subcomponente, nos referimos a un patrón de diseño.

Tomen como caso el patrón de Layers , este es claramente un patrón arquitectónico, ya que concierne al diseño general de la aplicación. Mientras que el patrón Active Record , que lidia con los mecanismos de persistencia de datos es un patrón de diseño.

Pero, qué pasa cuando lo que era totalidad se vuelve un subcomponente?. Cambiarían entonces sus patrones de arquitectura a diseño?. Aquí es donde no es tan fácil la respuesta.

Hay otros patrones que solapan responsabilidades de todo-parte, por ejemplo el MVC . Según como se aplique puede ser un patrón de diseño o arquitectura.

Publicado en Uncategorized | Deja un comentario

Arquitectura de Software

 

La definición “oficial” de Arquitectura de Software se ha acordado que sea la que brinda el documento de IEEE Std 1471-2000, adoptada también  por Microsoft, que reza así:               La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.

Arquitectura y sus efectos en los Stakeholders:

€La arquitectura afecta a todos los relacionados con el proyecto, afecta a los clientes, al gerentes, al equipo de desarrollo, al equipo de pruebas, etc. Cada stakeholder se preocupa por partes especificas del sistema, y esto se ve reflejado en la arquitectura del sistema.           La arquitectura provee un lenguaje mediante el cual los stakeholders comprenden el sistema y se comunican para tomar decisiones importantes.

Publicado en Uncategorized | Deja un comentario

TDD

TDD (Test Driven Development , o Desarrollo Guiado por Pruebas )

Tradicionalmente primero se desarrolla y luego se prueba. Este proceso propone intercambiar el orden las cajitas de desarrollo y pruebas para que las pruebas guíen el desarrollo (incluso hay quien dice que deben guiar el diseño) :

  • Primero especificar y desarrollar pruebas que debe superar el producto.
  • Después se desarrolla. Este paso no se da por finalizado hasta que se superan todos los test. Esta es la razón por la que se dice que las pruebas guían el desarrollo.
  • Finalmente se refactoriza  (cambiar la estructura interna de un sistema sin afectar a sus funcionalidades) tanto las pruebas como el código para mejorar el diseño interno. Al igual que el paso anterior, esta tarea no se da por completada hasta que se superen todos los test.

Se consigue mejorar la comunicación entre equipos, aumentar la comprensión de lo que realmente se debe desarrollar y al automatizar las pruebas se reduce muy significativamente el tiempo dedicado a pruebas manuales (tanto por el equipo de desarrollo como por el cliente al validar los entregables) a la vez que se aumenta la confianza en el producto.

Publicado en Uncategorized | Etiquetado , , | Deja un comentario

¿Porqué fracasan los proyectos de desarrollo de software?

Recopilando y contrastando las opiniones de autores diferentes, sobre cuáles son las principales causas que hacen fracasar a los proyectos de software, he extraido las más repetidas: tomando de cada uno las 5 razones que considera más importantes, y finalmente del conjunto, las 5 que más se repiten.

Este es el resultado:

Fuentes:

1.- Standish Group, Chaos Report .
2.- Watts S. Humphrey: Winning with software
3.- Focused Perfomance
4.- Coley Consulting
5.- CrossTalk (L.J. May)
6.- Database Design Resource
7.- Ram Sharma
8.- Soraya J. NetoAlvarez

Y los Top 5 son:

  1. Requisitos incompletos /falta de una visión clara
  2. Implicación insuficiente de los usuarios
  3. Expectativas poco realistas
  4. Falta de soporte ejecutivo / estructura organizativa inapropiada
  5. Planificación mala o deficiente

Es curiosa la diferencia de criterio de los autores, según estén más identificados con el desarrollo basado en planificación predictiva y procesos, o en agilidad y rutinas de trabajo.

Para los primeros las principales razones siempre están en el ámbito de la gestión y de los procesos. Whatts S. Humphrey, diseñador y padre de los modelos CMM afirma en Winning with Software :

“Software projects rarely fail for technical reasons; invariably, the problem is poor management. Technical problems often exist, but they are rarely decisive”.

Otras opiniones como las de Steve McConell , afirman que el principal factor determinante para el éxito de un proyecto son las personas “Software development projects should be staffed with the best people”.

También en el análisis “post-mortem” de proyectos cerrados, los profesionales y sus consejos suelen estar más cerca de una de estas presunciones:

  • El software es el resultado de un trabajo intelectual y creativo.
  • El software es el resultado de un proceso de trabajo normalizado.
Publicado en Uncategorized | Deja un comentario