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.

PMBOK

La finalidad principal de la Guía del PMBOK®
es identificar el subconjunto de Fundamentos de la Dirección de Proyectos generalmente reconocido como buenas prácticas.  “Identificar” significa proporcionar una descripción general en contraposición  a  una descripción  exhaustiva. 
“Generalmente reconocido” significa  que los conocimientos y las prácticas descritos son
aplicables  a la mayoría de los proyectos, la mayor  parte del tiempo,  y que  existe un  amplio
consenso sobre su valor y utilidad. “Buenas prácticas” significa que existe un acuerdo general en 
que la correcta aplicación de estas habilidades, herramientas y técnicas puede  aumentar las 
posibilidades de éxito de  una amplia variedad  de proyectos diferentes. “Buenas prácticas” no 
quiere decir que los conocimientos descritos deban aplicarse siempre de forma uniforme en todos
los proyectos; el equipo de dirección del proyecto es responsable de determinar lo  que  es 
apropiado para cada proyecto determinado.

La  Guía del PMBOK®
también proporciona y promueve un  vocabulario  común para
analizar, escribir y aplicar la dirección de proyectos. Este vocabulario estándar es  un  elemento
esencial de cualquier profesión. 
El Project Management Institute usa este documento como referencia fundamental, pero no
única, de la dirección de proyectos para sus programas de desarrollo profesional, entre los que se 
incluyen: 
•  la certificación de Profesional de la Dirección de Proyectos (Project Management 
Professional, PMP®) 
•  la educación y formación en materia de dirección de proyectos, ofrecida por Proveedores
de Educación Registrados (Registered Education Providers, R.E.P.) de PMI  
•  la acreditación de programas de educación en dirección de proyectos.  

Programación en Pareja

La Programación en Pareja requiere que dos Ingenieros en Software participen en un esfuerzo combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otro no está haciendo actualmente: Mientras que uno codifica las pruebas de unidades el otro piensa en la clase que satisfará la prueba, por ejemplo.

La persona que está haciendo la codificación se le da el nombre de controlador mientras que a la persona que está dirigiendo se le llama el navegador. Se sugiere a menudo para que a los dos socios cambien de papeles por lo menos cada media hora o después de que se haga una prueba de unidad.

Ventajas

La programación en pareja se enfoca en las siguientes ventajas, ordenadas de mayor a menor.

• Más Disciplina. Emparejando correctamente es más probable que hagan "lo que se debe hacer" en lugar de tomar largos descansos.
• Mejor código. Emparejando similares es menos probable producir malos diseños ya que su inmersión tiende a diseñar con mayor calidad.
• Flujo de trabajo constante. El emparejamiento produce un flujo de trabajo distinto al trabajar solo. En pareja el flujo de trabajo se recupera más rápidamente: un programador pregunta al otro "¿por dónde quedamos?". Las parejas son más resistentes a las interrupciones ya que un desarrollador se ocupa de la interrupción mientras el otro continúa trabajando.
• Múltiples desarrolladores contribuyen al diseño. Si las parejas rotan con frecuencia en el proyecto significa que más personas están involucradas con una característica en particular. Esto ayuda a crear mejores soluciones, especialmente cuando una pareja no puede resolver un problema difícil.
• Moral mejorada. La programación en parejas es más agradable para algunos programadores, que programar solos.
• Propiedad colectiva del código. Cuando el proyecto se hace en parejas, y las parejas se rotan con frecuencia, todos tienen un conocimiento del código base.
• Enseñanza. Todos, hasta los novatos, poseen conocimientos que los otros no. La programación en pareja es una forma amena de compartir conocimientos.
• Cohesión de equipo. La gente se familiariza más rápidamente cuando programa en pareja. La programación en pareja puede animar el sentimiento de equipo.
• Pocas interrupciones. La gente es más renuente a interrumpir a una pareja que a una persona que trabaja sola.
• Menos estaciones de trabajo. Ya que dos personas van a trabajar en una estación de trabajo, se requieren menos estaciones de trabajo, y las estaciones extras pueden ser ocupadas para otros propósitos.

XP

La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

MANIFIESTO ÁGIL

En el Manifiesto Ágil, firmado por Kent Beck, expone que:

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

• A los individuos y su interacción, por encima de los procesos y las herramientas.

• El software que funciona, por encima de la documentación exhaustiva.

• La colaboración con el cliente, por encima de la negociación contractual.

• La respuesta al cambio, por encima del seguimiento de un plan.

El 17 de febrero de 2001 diecisiete críticos de los modelos de mejora del desarrollo de software basados en procesos, convocados por Kent Beck, quien había publicado un par de años antes Extreme Programming Explained, libro en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en Snowbird, Utah para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término “Métodos Ágiles” para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales (CMMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.