martes, 9 de octubre de 2012

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.

martes, 28 de agosto de 2012

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 confiabilidadescalabilidadportabilidad, 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 (CMMISPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.