DIAGRAMA DE COMPONENTES

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.

Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

DIAGRAMA DE DESPLIEGUE

Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entre los nodos y por ejemplo con una base de datos.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

ESTILO ARQUITECTONICO

Es la clasificación arquitectónica en los términos de forma, técnicas, materiales, período, región, etc. Surgen del estudio de la evolución y la historia de la arquitectura. En la historia arquitectónica, por ejemplo, el estudio de la arquitectura gótica, se incluyen todos los aspectos del contexto cultural en que entró el diseño y la construcción de estas estructuras. El estilo arquitectónico es una manera de clasificar la arquitectura que da énfasis a las características del diseño, dando lugar a una terminología como el “estilo gótico”.

Base de datos relacional

Fue propuesto en 1970 por Codd, este es un modelo
simple potente y formal para representar la realidad, también ofrece una base firme
para enfocar y analizar formalmente muchos problemas relacionados con la gestión
de  bases  de  datos,  como  el  diseño,  la  redundancia,  la  distribución  etc.  El
formalismo  y  una  base  matemática,  son  las  piedras  angulares  del  modelo
relacional , el elemento básico del modelo es la relación y un esquema de bases de
datos relacional es una colección de definiciones de relaciones. En este modelo, el
lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia
de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja
de que es más fácil de entender y de utilizar para un usuario esporádico de la base
de  datos.  La  información  puede  ser  recuperada  o  almacenada  mediante
"consultas"  que  ofrecen  una  amplia  flexibilidad  y  poder  para  administrar  la
información.

Bases de datos transaccionales

Son bases de datos cuyo único fin es el envió 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óne 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.

MODELO-VISTA-CONTROLADOR

El objetivo de este tipo de modelos es de intentar repetirse lo menos posible y de tenerlo todo organizado o sea hacer una distinción entre la lógica de toda la aplicación y presentación.

Los Fundamentos básicos del MVC son los siguientes:

• Modelo: Esta sirve como representación específica de toda la información con la cual el sistema va a trabajar. La lógica de datos nos puede llegar a asegurar la integridad de ellos y nos permitirá derivar nuevos datos. ¿Como lo hace?  Pues , no permitiendonos comprar un número de unidades negativas, y también calculando si hoy puede ser el cumpleaños del usuario/a o también los totales, impuestos o importes en un sistema de venta.

• Vista: Presenta el modelo con el que va a interactuar el usuario, más conocida como interfaz.

• Controlador: El controlador responde más bien a eventos, normalmente son acciones que el usuario invoca, implica cambios en el modelo y también en la vista (interfaz).

Es un modelo de distribución de software donde el software y los datos que maneja se alojan en servidores de la compañía de tecnologías de información y comunicación (TIC) y se accede con un navegador web o un cliente ligero especializado, a través de Internet  La empresa TIC provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. Regularmente el software puede ser consultado en cualquier computador, esté presente en la empresa o no. Se deduce que la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software están hospedados en la compañía de TIC.

ASP

La tecnología ASP está estrechamente relacionada con el modelo tecnológico y de negocio de su fabricante. Intenta ser solución para un modelo de programación rápida ya que "programar en ASP es como programar en Visual Basic y C#", por supuesto con muchas limitaciones y algunas ventajas específicas en entornos web.

Lo interesante de este modelo tecnológico es poder utilizar diversos componentes ya desarrollados como algunos controles ActiveX así como componentes del lado del servidor, tales como CDONTS, por ejemplo, que permite la interacción de los scripts con el servidor SMTP que integra IIS.

Se facilita la programación de sitios web mediante varios objetos integrados, como por ejemplo un objeto de sesión basada en cookies, que mantiene las variables mientras se pasa de página a página.

Está limitada (la tecnología ASP) a funcionar solo en Microsoft Windows, pues requiere el servidor IIS; aunque en las versiones "9x" de Microsoft Windows era posible instalarMicrosoft Personal Web Server (PWS) y de esa manera usar asp. También puede instalarse software de terceros como por ejemplo Baby Web Server.

Por lo que su uso es cuestionado por la mayoría de los programadores web, quienes prefieren otros lenguajes de programación del lado del servidor como por ejemplo PHP, Perl,Java etc.

Cliente liviano o cliente ligero

Un cliente liviano o cliente ligero (thin client o slim client en inglés) es una computadora cliente o un software de cliente en una arquitectura de red cliente-servidor que depende primariamente del servidor central para las tareas de procesamiento, y principalmente se enfoca en transportar la entrada y la salida entre el usuario y el servidor remoto. En contraste, un cliente pesado realiza tanto procesamiento como sea posible y trasmite solamente los datos para las comunicaciones y el almacenamiento al servidor.

Muchos dispositivos de cliente liviano ejecutaban solamente navegadores web o programas de escritorio remoto, lo que significaba que todo el procesamiento significativo ocurría en el servidor. Sin embargo, dispositivos recientes vendidos como clientes livianos pueden correr sistemas operativos completos tales como GNU/Linux Debian, calificándolos comonodos sin disco o clientes híbridos. Algunos clientes livianos también son llamados "terminales de acceso".

Por consecuencia, el término "cliente liviano", en términos de hardware, ha venido abarcar cualquier dispositivo comercializado o usado como un cliente liviano en la definición original, incluso si sus capacidades reales son mucho mayores. El término también es a veces usado en un sentido incluso más amplio que incluye nodos sin disco.

CLIENTE PESADO

El término "cliente pesado", a diferencia de un cliente liviano, se utiliza para una aplicación gráfica de cliente que se ejecuta en el sistema operativo del usuario. Un cliente pesado suele tener una mayor capacidad de procesamiento y es posible que tenga una interfaz gráfica sofisticada. Sin embargo, esto conlleva un desarrollo adicional y suele ser una mezcla de la lógica de presentación (interfaz gráfica) con la lógica de la aplicación (potencia de procesamiento).

Este tipo de aplicación suele instalarse en el sistema operativo del usuario y se debe instalar una nueva versión cuando se realiza una actualización. Para solucionar esto, los programadores de aplicaciones pesadas, por lo general, incorporan una funcionalidad que se ejecuta al iniciar la aplicación y verifica un servidor remoto para saber si está disponible alguna versión más nueva. De ser así, le indica al usuario que descargue e instale la actualización. 

Arquitectura orientada a servicios de cliente SOA

SOA es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los datos y la lógica de negocio de sus sistemas separados.

Desarrollada a finales de los ´90, SOA establece un marco de trabajo para servicios de red – o tareas comunes de negocios – para identificar el uno al otro y comunicarlo.

La necesidad de tal marco se deriva de la evolución del software de negocio. En los comienzos, los desarrollos de aplicaciones de negocio se concentraban en necesidades específicas: contabilidad, compras, nómina de sueldos, transporte. Cada aplicación fue desarrollada sin consideración de otros sistemas en la empresa y como comunicarse con ellos. Porque las aplicaciones eran auto suficientes, la información común a toda la empresa (como por ejemplo: la dirección del cliente) y funciones específicas de negocios (como por ejemplo: buscar un nombre) aparecían en todas partes y requerían un código complejo para, todos o muchos de los sistemas independientes.

PATRONES DE ARQUITECTURA

Los patrones arquitectónicos, o patrones 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.

Aunque un patrón arquitectónico comunica una imagen de un sistema, no es una arquitectura como tal. Un patrón arquitectónico es más un concepto que captura elementos esenciales de una arquitectura de software. Muchas arquitecturas diferentes pueden implementar el mismo patrón y por lo tanto compartir las mismas características. Además, los patrones son a menudo definidos como una cosa "estrictamente descrita y comúnmente disponible". Por ejemplo, la arquitectura en capas es un estilo de llamamiento-y-regreso, cuando define uno un estilo general para interaccionar. Cuando esto es descrito estrictamente y comúnmente disponible, es un patrón.

Uno de los aspectos más importantes de los patrones arquitectónicos es que encarnan diferentes atributos de calidad. Por ejemplo, algunos patrones representan soluciones a problemas de rendimiento y otros pueden ser utilizados con éxito en sistemas de alta disponibilidad. A primeros de la fase de diseño, un arquitecto de software escoge qué patrones arquitectónicos mejor ofrecen las calidades deseadas para el sistema.

Ejemplos de patrones arquitectónicos incluyen los siguientes:

• Programación por capas
• Tres niveles
• Pipeline
• Invocación implícita
• Arquitectura en pizarra
• Arquitectura dirigida por eventos, Presentación-abstracción-control
• Peer-to-peer
• Arquitectura orientada a servicios
• Objetas desnudos
• Modelo Vista Controlador

PATRONES DE DISEÑO

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado suefectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Los patrones de diseño pretenden:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

• Imponer ciertas alternativas de diseño frente a otras.
• Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

PATRÓN

Los patrones son soluciones generales a problemas comunes y se dividen en:

• Patrones de arquitectura
• Patrones de diseño

REFACTORIZACIÓN

En ingeniería del software, el término refactorización se usa a menudo para describir la modificación del código fuente sin cambiar su comportamiento, lo que se conoce informalmente por limpiar el código. La refactorización se realiza a menudo como parte del proceso de desarrollo del software: los desarrolladores alternan la inserción de nuevas funcionalidades y casos de prueba con la refactorización del código para mejorar su consistencia interna y su claridad. Los tests aseguran que la refactorización no cambia el comportamiento del código.

La refactorización es la parte del mantenimiento del código que no arregla errores ni añade funcionalidad. El objetivo, por el contrario, es mejorar la facilidad de comprensión del código o cambiar su estructura y diseño y eliminar código muerto, para facilitar el mantenimiento en el futuro. Añadir nuevo comportamiento a un programa puede ser difícil con la estructura dada del programa, así que un desarrollador puede refactorizarlo primero para facilitar esta tarea y luego añadir el nuevo comportamiento.

La refactorización debe ser realizada como un paso separado, para poder comprobar con mayor facilidad que no se han introducido errores al llevarla a cabo. Al final de la refactorización, cualquier cambio en el comportamiento es claramente un bug y puede ser arreglado de manera separada a la depuración de la nueva funcionalidad.

Un ejemplo de una refactorización trivial es cambiar el nombre de una variable para que sea más significativo, como una sola letra 't' a 'tiempo'. Una refactorización más compleja es transformar el trozo dentro de un bloque en una subrutina. Una refactorización todavía más compleja es remplazar una sentencia condicional if por polimorfismo.

Aunque la limpieza de código se lleva realizando desde hace décadas, el factor clave de la refactorización es realizar de manera intencionada la limpieza separándola de la adición de funcionalidad nueva, usando un catálogo conocido de métodos útiles de refactorización, para después comprobar el código ejecutando las pruebas unitarias, sabiendo que cualquier cambio en el comportamiento significa que se ha introducido un error.

ARQUITECTURA DEL SOFTWARE

En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".

• La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.

• Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco
• Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

• La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.

La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.

CHAOS REPORT

“Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único, con restricciones de plazo y de costo”

Sobre la base de los resultados de la dirección de proyectos en compañías de informática se realizo el estudio “The Chaos Report” (Standish Group) que observa de todos los proyectos estudiados, qué cantidad fueron finalizados exitosamente y cuántos no llegaron a cumplir con algunos o todos los objetivos. Y lo más interesante es que hace un análisis de los motivos que originaron esos “fracasos”, permitiéndonos poner foco en ellos al dirigir nuevos proyectos.

Según este estudio del total de proyectos evaluados:
El 16% son completados con el alcance esperado, en el tiempo planificado y dentro del presupuesto asignado.
El 53% de los proyectos son completados con menor alcance, y/o sobrecosto y/o fuera de término.
El 31% de los proyectos son cancelados antes de terminar.

Del total de proyectos que se completan:
El 70% de los proyectos terminan fuera de plazo.
El 54% de los proyectos sufren sobrecostos.
El 66% de los proyectos no son considerados exitosos.
El 30% de los proyectos son cancelados antes de terminar

Principales factores de éxito:
1 – Involucramiento del usuario 15.9 %
2 – Apoyo de la Gerencia 13.0 %
3 – Enunciado claro de los requerimientos 9.6 %
4 – Planeamiento adecuado 8.2 %
5 – Expectativas realistas 7.7 %
6 – Hitos intermedios 7.7 %
7 – RRHH competentes 7.2 %

Principales factores de fracaso:
1 – Requerimientos incompletos 13.1 %
2 – Falta de involucramiento del usuario 12.4 %
3 – Falta de recursos 10.6 %
4 – Expectativas no realistas 9.9 %
5 – Expectativas realistas 9.3 %
6 – Falta de apoyo de la Gerencia 8.7 %
7 – Requerimientos cambiantes 8.1 %

CRISIS DEL SOFTWARE

Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.

Además, no existen todavía herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará un proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecución.

Englobó a una serie de sucesos que se venían observando en los proyectos de desarrollo de software:

• Los proyectos no terminaban en plazo.
• Los proyectos no se ajustaban al presupuesto inicial.
• Baja calidad del software generado.
• Software que no cumplía las especificaciones.
• Código inmantenible que dificultaba la gestión y evolución del proyecto.

Aunque se han propuesto diversas metodologías para intentar subsanar los problemas mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar de manera fiable el coste y duración de un proyecto antes de su comienzo.

PRINCE2

PRINCE2 significa en español proyectos en entornos controlados, es un método de gestión de proyectos que cubre la administración, control y organización de un proyecto .PRINCE2 es una marca registrada de la OGC del Reino Unido.

PRINCE2 fue originalmente desarrollado por la CCTA que actualmente forma parte de la OGC. Desde 1989 se viene usando como un estándar para la gestión de proyectos sobre todo en el Reino Unido. Este método fue inicialmente desarrollado únicamente para proyectos TIC, la última versión, PRINCE2, es compatible con la gestión de todo tipo de proyectos.

La revisión más reciente se publicó el 16 de junio de 2009 por la OGC siendo denominada esta versión como PRINCE2: 2009 Refresh.

SWEBOK

SWEBOK es un documento creado por la Software Engineering Coordinating Committee, promovido por la IEEE Computer Society, que se define como una guía al conocimiento presente en el área de la Ingeniería del Software. Supone un paso esencial hacia el desarrollo de la profesión porque representa un amplio consenso respecto a los contenidos de la disciplina.

Sus objetivos son:

• Caracterizar los contenidos de la Ingeniería del Software.
• Proveer acceso a través de las temáticas al conjunto de conocimientos de la Ingeniería del Software.
• Promover una visión consistente de la Ingeniería del Software en todo el mundo.
• Clarificar la posición de la Ingeniería del Software respecto a otras disciplinas, como las Ciencias de la Computación o las Matemáticas.
• Proveer una base para su desarrollo currícular y la creación de materiales de certificación.