CARACTERÍSTICAS CASCADA

Se debe comprobar el Software después de unirlo y antes de operarlo.

Es el más utilizado

Deben desarrollarse todas las fases

Las fases continúan hasta que los objetivos se han cumplido

Las flechas de la iteración que unen los procesos juntos muestran cómo el desarrollo de un producto influye en el desarrollo de productos anteriores.

PROGRAMACION EXTREMA XP

HISTORIA La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado 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. INTRODUCCION Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. ¿QUÉ ES PROGRAMACIÓN EXTREMA O XP?

ü Metodología liviana de desarrollo de software ü Conjunto de practicas y reglas empleadas para desarrollar software ü Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes ü Originada en el proyecto C3 para Chrysler ü En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de

todo el proceso de desarrollo OBJETIVOS.

ü Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos. ü Mejorar la productividad de los proyectos. ü Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

CONTEXTO XP ü Cliente bien definido

ü Los requisitos pueden (y van a) cambiar ü Grupo pequeño y muy integrado (máximo 12 personas ü Equipo con formación elevada y capacidad de aprender

CARACTERÍSTICAS XP Metodología basada en prueba y error Fundamentada en Valores y Prácticas Expresada en forma de 12 Prácticas–Conjunto completo–Se soportan unas a otras–Son conocidas desde hace

tiempo. La novedad es juntarlas VALORES XP

ü Simplicidad XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo complicado y probablemente nunca usarlo mañana.

ü Comunicación Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algún momento. XP hace casi imposible la falta de comunicación.

ü Realimentación Retralimentación concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.

ü Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si funciona…mejóralo) EL ESTILO XP

ü Esta orientada hacia quien produce y usa el software ü Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema. ü Combina las que han demostrado ser las mejores practicas para desarrollar software, y las lleva al extremo.

PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA Para que todo esto funcione, la programación extrema se basa en doce "prácticas básicas" que deben seguirse al pie de la letra. Dichas prácticas están definidas (en perfecto inglés) en www.xprogramming.com/xpmag/whatisxp.htm. Aquí tienes un pequeño resumen de ellas.

ü Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.

ü Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.

ü Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.

ü Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.

ü Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.

Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).

Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.

ü Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.

ü El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.

ü Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.

ü Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.

ü Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.

MANEJO COLECTIVO DEL CÓDIGO VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING Ventajas:

ü Programación organizada. ü Menor taza de errores. ü Satisfacción del programador.

Desventajas: ü Es recomendable emplearlo solo en proyectos a corto plazo. ü Altas comisiones en caso de fallar.

Metodologías agiles

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término .ágil. aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas.

Tras esta reunión se creó The Agile Alliance3, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto Ágil, un documento que resume la filosofía .ágil..

El Manifiesto Ágil.

Según el Manifiesto se valora:

· Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.

· Desarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es .no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante.. Estos documentos deben ser cortos y centrarse en lo fundamental.

· La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

· Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son características que diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organización del mismo.

PRINCIPIOS:

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento

Lista de metodologías ágiles

En la actualidad se cuentan alrededor de 15 a20 metodologías agiles sin contar los métodos híbridos de desarrollo que integran en sus practicas como ejemplo a Xp con Scrum. A continuación el listado de metodologías agiles en desarrollo de software más representativas con el año de creación, acrónimo y autor.

Metodologías que se basan en procesos rápidos, pensados en ser funcionales, adaptables y además manejan similitudes entre ellos y pueden complementarse o formar métodos híbridos.

Metodologías ligeras vs métodos tradicionales

Aunque las metodologías ligeras se basan en las ideas de los procesos tradicionales estas usan lo mas importante para el buen desarrollo del proyecto con lógicay dejando atrás el manejo excesivo de artefactos y burocracia.

Diferencias entre métodos agiles y metodologías tradicionales.

Uso de métodos agiles

Desde el surgimiento de estas revolucionarias metodologías que no solo nacen para el desarrollo de sistemas software sino para el management o desarrollo de productos los incrementos en adeptos se presentan gradualmente con el tiempo y las tecnologías.

Y los que las usan, ¿Por qué razón o razones lo hacen?:

Para reducir el tiempo de desarrollo: 45% Para mejorar la calidad: 43% Para reducir costes: 23% Para alinear el desarrollo con los objetivos de negocio: 39% Otras razones: 12%.

¿Y cuál es el ranking de preferencias entre modelos ágiles? 1º.- Extreme Programming (28%) 2º.- FDD (26%) 3º.- Scrum (20%) 4º.- Crystal (6%) ágil 5º.- DSDM (4%) Fuente: Agile Journal [2], nº1, Marzo-2006.

METODOLOGIAS AGILES RUP INTRODUCCIÓN Se entiende como Desarrollo Ágil de Software a un paradigma de Desarrollo de Software basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados. Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada

funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto. Los métodos Agiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpenen inglés). La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica. HISTORIA La definición moderna de desarrollo ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra los métodos de “peso pesado”, muy estructurado y estricto, extraídos del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente. Los métodos de desarrollos ágiles e iterativos pueden ser vistos como un retroceso a las prácticas de desarrollo observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías formales). Inicialmente, los métodos ágiles fueron llamados métodos de "peso liviano". En el año 2001, miembros prominentes de la comunidad se reunieron en Sonwbird, Utah, y adoptaron el nombre de "Metodologías ágiles". Poco después, algunas de estas personas formaron la "alianza ágil", una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchos métodos similares al ágil fueron creados antes del 2000. Entre los más notables se encuentran: Scrum(1986), Crystal Clear (cristal transparente), programación extrema o XP (1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos(1995). Kent Beck creó el método de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del Sistema exhaustivo de compensaciones de Chrysler (C3). Mientras Chrysler cancelaba ese proyecto, el método fue refinado por Ron Jeffries. METODOLOGIA RUP Siempre que empezamos discutiendo métodos en la arena OO, inevitablemente salimos con el papel del Rational Unified Process. El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de la Rational como el proceso complementario al UML. El RUP es un armazón de proceso y como tal puede acomodar una gran variedad de procesos. De hecho ésta es mi crítica principal al RUP - como puede ser cualquier cosa acaba siendo nada. Yo prefiero un proceso que dice qué hacer en lugar de dar opciones infinitas. Como resultado de esta mentalidad de armazón de procesos, el RUP puede usarse en un estilo muy tradicional de cascada o de una manera ágil. Como resultado usted puede usar el RUP como un proceso ágil, o como un proceso pesado - todo depende de cómo lo adapte a su ambiente. Craig Larman es un fuerte defensor de usar el RUP de una manera ágil. Su excelente libro introductoriosobre desarrollo OO contiene un proceso que está muy basado en su pensamiento ligero del RUP. Su visión es que mucho del reciente empujón hacia los métodos ágiles no es nada más que aceptar desarrollo OO de la corriente principal que ha sido capturada como RUP. Una de las cosas que hace Craig es pasarse los primeros dos o tres días de una iteración mensual con todo el equipo usando el UML para perfilar el diseño del trabajo a hacerse durante la iteración. Esto no es un cianotipo del que no se pueda desviarse, sino un boceto que da una perspectiva sobre cómo pueden hacerse las cosas en la iteración. Otra tachuela en el RUP ágil es el proceso dX de Robert Martin. El proceso dx es una versión totalmente dócil del RUP que simplemente es idéntico a la XP(voltear dX al revés para ver la broma). El dX está diseñado para gente que tiene que usar el RUP pero quiere usar XP. Como tal es a la vez XP y RUP y por tanto un buen ejemplo del uso ágil del RUP. Para mí, una de las cosas clave que necesita el RUP es que los líderes del RUP en la industria enfaticen su acercamiento al desarrollo de software. Más de una vez he oído a la gente que usa el RUP que están usando un proceso de desarrollo estilo cascada. Gracias a mis contactos en la industria, sé que Philippe Kruchten y su equipo son firmes creyentes en el desarrollo iterativo. Clarificando estos principios y animando las versiones ágiles del RUP tales como los trabajos de Craig y de Robert tendrá un efecto importante. El proceso de ciclo de vida de RUP se divide en cuatro fases bien conocidas llamadas Incepción, Elaboración, Construcción y Transición. Esas fases se dividen en iteraciones, cada una de las cuales produce una pieza de software demostrable. La duración de cada iteración puede extenderse desde dos semanas hasta seis meses. Las fases son:

Incepción. Significa “comienzo”, pero la palabra original (de origen latino y casi en desuso como sustantivo) es sugestiva y por ello la traducimos así. Se especifican los objetivos del ciclo de vida del proyecto y las necesidades de cada participante. Esto entraña establecer el alcance y las condiciones de límite y los criterios de aceptabilidad. Se identifican los casos de uso que orientarán la funcionalidad.

Se diseñan las arquitecturas candidatas y se estima la agenda y el presupuesto de todo el proyecto, en particular para la siguiente fase de elaboración. Típicamente es una fase breve que puede durar unos pocos días o unas pocas semanas.

Elaboración. Se analiza el dominio del problema y se define el plan del proyecto. RUP presupone que la fase de elaboración brinda una arquitectura suficientemente sólida junto con requerimientos y planes bastante estables. Se describen en detalle la infraestructura y el ambiente de desarrollo, así como el soporte de herramientas de automatización. Al cabo de esta fase, debe estar identificada la mayoría de los casos de uso y los actores, debe quedar descripta la arquitectura de software y se debe crear un prototipo de ella. Al final de la fase se realiza un análisis para determinar los riesgos y se evalúan los gastos hechos contra los originalmente planeados.

Construcción. Se desarrollan, integran y verifican todos los componentes y rasgos de la aplicación. RUP considera que esta fase es un proceso de manufactura, en el que se debe poner énfasis en la administración de los recursos y el control de costos, agenda y calidad. Los resultados de esta fase (las versiones alfa, beta y otras versiones de prueba) se crean tan rápido como sea posible. Se debe compilar también una versión de entrega. Es la fase más prolongada de todas.

Transición. Comienza cuando el producto está suficientemente maduro para ser entregado. Secorrigen los últimos errores y se agregan los rasgos pospuestos. La fase consiste en prueba beta, piloto, entrenamiento a usuarios y despacho del producto a mercadeo, distribución y ventas. Se produce también la documentación. Se llama transición porque se transfiere a las manos del usuario, pasando del entorno de desarrollo al de producción.

A través de las fases se desarrollan en paralelo nueve workflows o disciplinas: Modelado de Negocios, Requerimientos, Análisis & Diseño, Implementación, Prueba, Gestión de Configuración & Cambio, Gestión del Proyecto y Entorno. Además de estos workflows, RUP define algunas prácticas comunes:

Desarrollo iterativo de software. Las iteraciones deben ser breves y proceder por incrementos pequeños. Esto permite identificar riesgos y problemas tempranamente y reaccionar frente a ellos en consecuencia.

Administración de requerimientos. Identifica requerimientos cambiantes y postula una estrategia disciplinada para administrarlos.

Uso de arquitecturas basadas en componentes. La reutilización de componentes permite asimismo ahorros sustanciales en tiempo, recursos y esfuerzo.

Modelado visual del software. Se deben construir modelos visuales, porque los sistemas complejos no podrían comprenderse de otra manera. Utilizando una herramienta como UML, la arquitectura y el diseño se pueden especificar sin ambigüedad y comunicar a todas las partes involucradas.

Prueba de calidad del software. RUP pone bastante énfasis en la calidad del producto entregado. Control de cambios y trazabilidad. La madurez del software se puede medir por la frecuencia y tipos de cambios

realizados. Aunque RUP es extremadamente locuaz en muchos respectos, no proporciona lineamientos claros de implementación que puedan compararse, por ejemplo, a los métodos Crystal, en los que se detalla la documentación requerida y los roles según diversas escalas de proyecto. En RUP esas importantes decisiones de dejan a criterio del usuario. Se asegura que RUP puede implementarse “sacándolo de la caja”, pero dado que el número de sus artefactos y herramientas es inmenso, siempre se dice que hay que recortarlo y adaptarlo a cada caso. El proceso de implementación mismo es complejo, dividiéndose en seis fases cíclicas. Existe una versión recortada de RUP, dX de Robert Martin, en la cual se han tomado en consideración experiencias de diversos MAs, reduciendo los artefactos de RUP a sus mínimos esenciales y (en un gesto heroico) usando tarjetas de fichado en lugar de UML. Es como si fuera RUP imitando los principios de XP; algunos piensan que dX es XP de cabo a rabo, sólo que con algunos nombres cambiados [ASR+02]. RUP se ha combinado con Evo, Scrum, MSF y cualquier metodología imaginable. Dado que RUP es suficientemente conocido y su estructura es más amplia y compleja que el de cualquier otro método ágil, su tratamiento en este texto concluye en este punto.

¿Qué es UML?El Lenguaje de Modelado Unificado

Introducción

Una exigencia de la gran mayoría de instituciones dentro  de su Plan Informático estratégico, es que los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguaje estándar y unificado.

Es decir, se requiere  que cada una de las partes que comprende el desarrollo de todo software de diseño orientado a objetos, se visualice, especifique y documente con lenguaje común.

Se necesitaba un lenguaje que fuese  gráfico, a fin de especificar y documentar un sistema de software, de un modo estándar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notación estándar y semánticas esenciales, para el modelado de un sistema orientado a objetos.

Así mismo, aquellos que deseen enmarcar conceptualmente

desde su génesis UML, recomiendo comprender los Fundamentos de los Lenguajes Estructurados.

El UML unido a un gestión de calidad, evita malos entendidos  y  entrega ciertas precauciones en la evolución y mantención de programas. Especialmente en lo referente a los requerimientos asociados al levantamiento y diseño funcional de un sistema. En efecto, por ejemplo con los Clientes Dilema, quienes no podrán hacer pensar que el cambio que están solicitando es pequeño, cuando detrás de la petición existe una enorme cantidad de tareas relacionadas al requerimiento.

Cabe preguntarse ¿Cuáles son las características que debe tener una herramienta UML?.

¿Qué es UML?

El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso.

El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999).

UML incrementa la capacidad de lo que se puede hacer con otros métodos de análisis y diseño orientados a objetos. Los autores de UML apuntaron también al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño.

El proceso indica los pasos que se deben seguir para llegar a un diseño.

La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

Ver RobotDocIRS y ¿Cuáles son las características que debe tener una herramienta UML?

Semántica y Notación

Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.

La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).

Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.

Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.

El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:

Modelamiento de Clases Casos de Uso Diagrama de Interacción

Los diagramas de clases de UML forman la vista lógica. Los diagramas de interacción de UML constituyen la vista de proceso. La vista de desarrollo captura el software en su entorno de desarrollo.  Los diagramas de despliegue integran la vista física . Los escenarios: el modelo de casos de uso.

(A continuación partes de un artículo de Patricio Salinas Caro y Nancy Hitschfeld Kahler de Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas,Departamento de Ciencias de la Computación )

Modelamiento de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser

private, protected o public).

Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

Balance

Puede realizar las operaciones de:

Depositar Girar y Balance

El diseño asociado es:

Atributos y Métodos:

Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

o public (+): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

o private (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).

o protected (#): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

Métodos:

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

o public (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

o private (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).

o protected (#): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

i. Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio atributos como Descapotable no son visibles por ser privados.

Agregación:

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio

no son afectados los objetos Cliente asociados. La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto refereniado. Cuando no existe este tipo de particularidad la flecha se elimina.

  Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.   Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicación):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

Casos Particulares:

Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.

  Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o

bien de alguna estructura predefinida (especialización a través de clases).

En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependerán exclusivamente de la implementación que se le quiera dar.

Ejemplo:

Supongamos que tenemos tenemos un el caso del Diccionario implementado mediante un árbol binario, en donde cada nodo posee:

key: Variable por la cual se realiza la búsqueda, puede ser genérica. item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también puede ser genérico.

Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como item, solo se mostrarán las relaciones para la implementación del Diccionario:

Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso . Relaciones de Uso, Herencia y Comunicación .

Elementos

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones:

o Asociación

o Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

o Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

o Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Ejemplo:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el número de ítemes ingresados. Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositadob. El valor de cada itemc. Total

El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente:

a. Cuantos ítemes han sido retornados en el día.b. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.

El operador debe además poder cambiar:a. Información asociada a ítemes.b. Dar una alarma en el caso de que:

i. Item se atora.

ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

Diagrama de Interacción

Introducción

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).

Los componentes de un diágrama de interacción son:

Un Objeto o Actor . Mensaje de un objeto a otro objeto . Mensaje de un objeto a si mismo .

Elementos

Objeto/Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.

Mensaje a Otro Objeto:

 Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

Ejemplo

En el presente ejemplo, tenemos el diagrama de interacción proveniente del siguiente modelo estatico:

Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su vez posee internamente un botón.

Entonces el diagrama de interacción para dicho modelo es:

En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la llamada a Paint() por el objeto Botón.

Bibliografía:

http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html

Autores: Diana Palliotto; Gabriel Romano Universidad Nacional de Santiago del Estero – Facultad de Ciencias Exactas y Tecnologías Dirección: Departamento de Informática - Av. Belgrano (S) 1912, (4200) Santiago del Estero, Argentina.- E-Mail:

UML ToolsBy Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy

Los beneficios del Modelador Bizagi

MODELO DE PROTOTIPOS Y MODELO EN ESPIRAL, CARACTERISTICAS Y DIFERENCIAS, Y SU PAPEL EN EL CICLO DE VIDA CLASICO

MODELO DE PROTOTIPO:

Es un modelo del ciclo de vida del software el  cual se utiliza para dar al usuario una vista preliminar de cómo se encuentra  el software. Este modelo es básicamente prueba y error ya que si al usuario no le gusta una parte del prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que el usuario quede satisfecho.

CARACERISTICAS

<!--[if !supportLists]-->Ø  <!--[endif]-->Describe las fases principales de desarrollo de software.

<!--[if !supportLists]-->Ø  <!--[endif]-->Define las fases primarias esperadas de ser ejecutadas durante esas fases.

<!--[if !supportLists]-->Ø  <!--[endif]-->Ayuda a administrar el progreso del desarrollo del software

<!--[if !supportLists]-->Ø  <!--[endif]-->Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

VENTAJAS

<!--[if !supportLists]-->Ø  <!--[endif]-->Ser fácilmente modificable.

<!--[if !supportLists]-->Ø  <!--[endif]-->Reducir los costos de rediseño si los problemas se detectan pronto y cuando son fáciles de localizar.

<!--[if !supportLists]-->Ø  <!--[endif]-->Este modelo es útil cuando el cliente conoce los objetivos generales para el software.

DESVENTAJAS

<!--[if !supportLists]-->Ø  <!--[endif]-->Hacer pensar a los usuarios que el producto final está prácticamente terminado.

<!--[if !supportLists]-->Ø  <!--[endif]-->Llevar a un número de cambios excesivo.

MODELO EN ESPIRAL:

Es un modelo de proceso de software evolutivo el cual es a base de una serie de ciclos los cuales se repiten en forma de espiral, esta orientados a evitar riesgos de trabajo. Cada vez que se avanza un ciclo se va alcanzando un nivel superior hasta concluir el proyecto.

CARACTERISTICAS

<!--[if !supportLists]-->Ø  <!--[endif]-->Es un modelo que puede combinarse con otros modelos de procesos de desarrollo (cascada y evolutivo).

<!--[if !supportLists]-->Ø  <!--[endif]-->Es el mejor modelo que se utiliza para desarrollar grandes sistemas.

<!--[if !supportLists]-->Ø  <!--[endif]-->El análisis de riesgo requiere la participación de personal con experiencia.

VENTAJAS

<!--[if !supportLists]-->Ø  <!--[endif]-->Modelo de proceso adaptable.

<!--[if !supportLists]-->Ø  <!--[endif]-->El modelo de espiral puede aplicarse a lo largo de la vida del software.

<!--[if !supportLists]-->Ø  <!--[endif]-->Es apropiado para desarrollar Sistemas Operativos.

DESVENTAJAS

<!--[if !supportLists]-->Ø  <!--[endif]-->No se ha utilizado mucho ya que es un modelo nuevo.

<!--[if !supportLists]-->Ø  <!--[endif]-->Debido a la complejidad no se recomienda utilizarlo en sistemas pequeños.

<!--[if !supportLists]-->Ø  <!--[endif]-->Es un modelo costoso.

COMPARACION ENTRE MODELOS PROTOTIPO Y ESPIRAL

CRITERIO PROTOTIPADO ESPIRAL

Disponibilidad de recursos Algunos Algunos

Complejidad del proyecto Media Alta

Entendimiento de requerimientos Vago Vago

Tecnología del producto Vago Vago

Manejo de la perspectiva de riesgo Si Si

Conocimiento del dominio de problemas

Regular Pobre

UWE - UML-based WEB Engineering

UME es un método, de ingeniería WEB orientada a objetos basada en UML, que puede ser utilizado para la especificación de aplicaciones WEB.La aproximación propuesta por UWE provee:

1. una notación específica de dominio2. un proceso de desarrollo basado en el modelo, y3. una herramienta de soporte para la ingeniería de aplicaciones WEB.

La principal caracteristica de UWE es el hecho de ser una aproximación basada en estándares, la cual no se límita al uso de UML, además integra:

1. XMI como modelo de intercambio de formatos,2. MOF para los metamodelos3. los principios de la aproximación MDA (dirigida por el modelo),4. el modelo de transformación del lenguaje QVT y5. XML

La razón principal para extender UML en lugar de crear una técnica de modelamiento propietaria, es la aceptación de UML en el proceso de desarrollo de software, la flexibilidad para la definición de un lenguaje de modelamiento específico en el dominio WEB, también llamado perfil UML, y un gran soporte del modelo de visualización con las herramientas existentes de UML CASE.

UWE hace uso de notacion UML pura y los tipos de diagramas UML en donde sea posible para el análisis y diseño de aplicaciones WEB. Para las características de aplicaciones WEB específicas, como nodos y vínculos de la estructura de hyper-texto, el perfil UWE incluye:

estereotipos, valores marcados y limitaciones definidas para los elementos de modelamiento.

La extensión de UWE cubre la navegación, presentación, lógica del negocio y aspectos de adaptación. La notación UWE se define como una extensión "ligera" de UML.

La aproximación de diseño UWE para los procesos del negocio consiste en introducir clases específicas del proceso, que son parte de un modelo de proceso separado con una interfaz definida para el modelo de navegación.

El modelamiento de las características adaptativas de las aplicaciones WEB se hace de manera no invasiva, es decir, UWE usa técnicas de modelamiento orientadas por aspectos (AOM), siguiendo el principio separación de preocupaciones UWE propone construir un modelo adaptativo para sistemas personalizados o dependientes del contexto y después entrelazar los modelos.

5 beneficios de aplicar metodologías ágiles en el desarrollo de software

El desarrollo ágil de software refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, estas metodologías son imprescindibles en un mundo en el que nos exponemos a cambios recurrentemente. Siempre hay que tener en cuenta como programadores que lo que es la última tendencia hoy puede que no exista mañana y por esto existe la metodología ágil donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios.

Métodos y Procesos en la Metodología Ágil

 De entre todos los métodos de desarrollo ágil, estos son los 3 que actualmente dominan el panorama:

1. SCRUM

 

El Scrum es un proceso de la Metodología Ágil que se usa para   minimizar los riesgos durante la realización de un proyecto, pero de manera colaborativa.

Entre las ventajas se encuentran la productividad, calidad y que se realiza un seguimiento diario de los avances del proyecto, logrando que los integrantes estén unidos, comunicados y que el cliente vaya viendo los avances. La profundidad de las tareas que se asignan en SCRUM tiende a ser incremental, caso que coincide exactamente con el devenir normal de un desarrollo.

Es perfecto para empresas de desarrollo de software orientadas a varios clientes. Esta por otro lado es la metodología que se utiliza en I2B.

2. XP o Extreme Programming

La “programación extrema” es un proceso de la Metodología Ágil que se aplica en equipos con muy pocos programadores quienes llevan muy pocos procesos en paralelo. Consiste entonces en diseñar, implementar y programar lo más rápido posible, hasta en casos se recomienda saltar la documentación y los procedimientos tradicionales. Se fundamenta en la capacidad del equipo para comunicarse entre sí y las ganas de aprender de los errores propios inherentes en un programador.

La gran ventaja de XP es su increíble capacidad de respuesta ante imprevistos, aunque por diseño es una metodología que no construye para el largo plazo y para la cual es difícil documentar.

XP es un método estupendo para equipos extremadamente pequeños que se centran en un solo cliente.

3. Desarrollo Ligero o “Lean”

También conocido como “Lean Programming”, este es un conjunto de técnicas que engloban un proceso de la Metodología Ágil en desarrollo de software orientado a conseguir exactamente lo que necesita el cliente. Es una evolución del Método Toyota de Producción aplicado al desarrollo y que está muy de moda entre los equipos de desarrollo en startups.

Principalmente se identifica por hacer uso de ciclos de evolución de software incrementales en los que se alejan las decisiones lo más posible hasta no tener retroalimentación por parte del cliente y con esto reaccionar de modo más flexible posible contra sus posibles necesidades. Por esto mismo de provenir de una metodología Japonesa

de trabajo se fundamenta en tener un equipo muy capaz y comprometido al principio del aprendizaje continuo.

El Desarrollo Lean una metodología fantástica para empresas que están desarrollando un software B2C orientado a tener éxito en el mercado.

Beneficios de aplicar la Metodología Ágil

1. RSI superiorCuando se lidia con proyectos múltiples y no se aplican metodologías ágil, lo normal es esperar a que se complete un proceso antes de arrancar con el segundo. Para poder lidiar con este tipo de operación de proyectos se estila buscar el cómo finalizar entregas lo más pronto posibles lo cual significa un inmenso riesgo de recorte de funcionalidades o calidad.El desarrollo con metodología ágil refuerza las entregas múltiples lo cual contra el cliente es un indicador operante y de cierto modo representaría un capital en trabajo. Como tal se refuerza más bien la lista de funcionalidades del acuerdo de entrega y en el promedio implica un enfoque en desarrollar la funcionalidad que se considere más vital para el proyecto desde el simple inicio.

2. El desarrollo ágil aumenta la productividadLa producción de software que trabaja alrededor de las necesidades de negocio implica ingresar conocimiento multidisciplinario en etapas simultáneas. La metodología ágil sirve para enfocar la atención de los partidos por disciplina en el espacio que se les necesita e inmediatamente liberar el talento para que puedan moverse entre zonas de trabajo.Aplicar un sistema de tarea discretas contra las personas que las ejecutan simplifican la distribución de entrega de información y consecuentemente del mismo sentido de capacidad de control del mismo empleado lo cual resulta en un deseo inherente de procesar las tareas lo más simple y rápidamente posible.

3. Simplifica el manejo de la sobrecarga de procesosLos equipos que trabajan sobre normas y regulaciones han de validar su trabajo constantemente lo cual representa un doble sentido de trabajo. Las metodologías por iteración simplifican el proceso de entrega versus validación lo cual además permite adoptar cambios sobre la marcha del alcance del proyecto.

4. Mejor perfil de productividadLos equipos ágiles son más productivos que aquellos que utilizan métodos tradicionales a lo largo de todo el ciclo de desarrollo. Si no se aplica un sistema ágil se presenta  un patrón de desarrollo tipo “palo de hockey” donde la mayoría del trabajo sucede en las primeras etapas y ya que anden los equipos se van haciendo ajustes sobre el trabajo anterior. La realidad es que casi nunca suele suceder que las piezas en equipo terminan trabajando juntos de manera coherente.Los equipos ágiles que mantienen un nivel de revisión por unidades discretas de entrega de trabajo con cada iteración permiten realizar pruebas de rendimiento y sistemas desde el principio. De este modo, defectos críticos como problemas de integración se descubren antes, la calidad general del producto es mayor y el equipo funciona de manera más productiva durante todo el ciclo de desarrollo.

5. Una mejor gestión del riesgoNo siempre se logra cumplir con las metas de lanzamiento cuando se trabaja con software, mientras más lejanas sean las entregas contra cliente o equipo más se maximiza el riesgo de potencial desviación de la entrega contra la definición del proyecto inicial. Las metodologías ágil permiten repasar en ciclos continuos progreso in media res de entregables y productos semi-cerrados. Cuando fallan las entregas la metodología ágil permite ajustar el ciclo de trabajo para enfocar el talento en zonas de mayor o menor riesgo a justificación de defender un proyecto en su totalidad.

Modelo Incremental

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:

Método de las comparaciones limitadas sucesivas.

Ciencia de salir del paso.

Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.

En una visión genérica, el proceso se divide en 4 partes:

Análisis

Diseño

Código

Prueba

Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminará siendo la solución completa requerida por el cliente, pero éstas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos más importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión.

De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de requisitos funcionales y será el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregará. La asignación de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Características:

Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.

El usuario se involucra mas.

Dificil de evaluar el costo total.

Dificil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.

Requiere gestores experimentados.

Los errores en los requisitos se detectan tarde.

El resultado puede ser positivo.

Ventajas:

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.

El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

Desventajas:

El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos.

Requiere de mucha planeación, tanto administrativa como técnica.

Requiere de metas claras para conocer el estado del proyecto.

Léxico Extendido del Lenguaje (LEL)

Número Símbolo Tipo

1 Análisis Verbo

2 Analista Sujeto

3 Codificación Verbo

4 Desarrollador Sujeto

5 Diseñador Sujeto

6 Diseño Verbo

7 Entregar el incremento Verbo

8 Especificación de requisitos Objeto

9 Incremento Objeto

10 Incremento rechazado Estado

11 Incremento validado Estado

12 Modelo de arquitectura de software Objeto

13 Modelo de diseño Objeto

14 Núcleo Objeto

15 Plan de incremento Objeto

16 Producto Objeto

17 Producto completo Estado

18 Producto incompleto Estado

19 Prueba Verbo

20 Prueba de aceptación Verbo

21 Prueba de integración Verbo

22 Prueba unitaria Verbo

23 Tester Sujeto

Definición de Símbolos

Símbolo Nº: 1

Tipo: Verbo

Nombre/s Análisis

Noción Es la actividad en la que se obtienen e interpretan los requisitos de un incremento.

Es llevada a cabo por el analista.

Impacto Se elicitan los requisitos del incremento con el cliente.

Se interpretan los requisitos obtenidos.

Se realiza el documento de especificación de requisitos.

Se validan los requisitos elicitados con cliente.

Símbolo Nº: 2

Tipo: Sujeto

Nombre/s Analista

Noción Es el encargado de realizar el análisis de los requisitos que corresponden a un incremento.

Impacto Define cuales son las necesidades del cliente.

Se encarga de elicitar requisitos con el cliente.

Realiza el análisis de los requisitos de cada incremento.

Se encarga de realizar el documento de especificación de requisitos.

Símbolo Nº: 3

Tipo: Verbo

Nombre/s Codificación

Noción Es la actividad en la que se elabora la funcionalidad de un incremento.

Es realizada por el desarrollador.

Sucede luego de la actividad de análisis.

Impacto Se desarrolla en base a los requisitos registrados en el documento de especificación de requisitos que corresponden a un incremento.

Agrega funcionalidad al producto.

Símbolo Nº: 4

Tipo: Sujeto

Nombre/s Desarrollador

Noción Es el encargado de realizar la codificación que corresponde a un incremento.

Impacto Toma los requisitos del documento de especificación de requisitos que corresponden al incremento que se está elaborando.

Revisa el documento de especificación de requisitos.

Revisa el documento de modelo de diseño.

Realiza la codificación correspondiente a los requisitos de un incremento teniendo en cuenta el modelo de diseño detallado.

Símbolo Nº: 5

Tipo: Sujeto

Nombre/s Diseñador

Noción Es el encargado de realizar el modelo de diseño.

Es el encargado de realizar el modelo de arquitectura de software.

Impacto Define el modelo de diseño en base al documento de especificación de requisitos.

Define el modelo de arquitectura del software en base al documento de especificación de requisitos.

Toma los requisitos que corresponden al incremento que se está elaborando.

Revisa el documento de especificación de requisitos.

Se encarga de llevar a cabo la actividad de diseño.

Símbolo Nº: 6

Tipo: Verbo

Nombre/s Diseño

Noción Es la actividad que permite llevar a cabo el modelo de diseño de un incremento.

Es la actividad que permite llevar a cabo el modelo de arquitectura de software de un incremento.

Es realizada por el diseñador.

Sucede luego de la actividad de análisis.

Impacto Se revisan los requisitos del incremento que se encuentran en el documento de especificación de requisitos.

Se determina la estructura requerida para el incremento, la cual es realizada con el modelo de arquitectura de software.

Se detallan los componentes que se van utilizar para el incremento, los cuales se realizan con el modelo de arquitectura de software.

Se definen los diagramas a utilizar para el modelo de diseño del incremento.

Símbolo Nº: 7

Tipo: Verbo

Nombre/s Entregar el incremento

Noción Es la actividad que corresponde a la entrega del producto al cliente de la funcionalidad solicitada.

Impacto Se realiza la instalación del incremento en el cliente.

Se realiza la prueba de aceptación con el cliente.

Se verifica que los requisitos del documento de especificación de requisitos coincidan con el incremento entregado.

El incremento es utilizado por el cliente.

Símbolo Nº: 8

Tipo: Objeto

Nombre/s Especificación de requisitos

Noción Es un documento que se confecciona durante la actividad de análisis.

Es toda la información necesaria para comprender la necesidad del cliente.

Impacto Es confeccionado por el analista.

Contiene los requisitos del sistema que surgen en cada incremento.

El primer documento generado da origen al núcleo.

Es utilizado por el desarrollador para la codificación.

Es utilizado por el diseñador para realizar el modelo de diseño.

Es utilizado por el diseñador para realizar el modelo de arquitectura de software.

Símbolo Nº: 9

Tipo: Objeto

Nombre/s Incremento

Noción Es una porción del software que cumple con un conjunto de funcionalidades requeridas por el cliente.

Toda la documentación relevante del incremento y que es proporcionada por el cliente se vuelca en el plan de incremento.

Impacto Cada incremento pasa por las siguientes actividades: análisis, diseño, codificación y prueba.

Es aceptado o rechazado en base a los resultados de la prueba de aceptación.

Cumple con un conjunto de requisitos solicitados por el cliente y que se encuentran documentados en la especificación de requisitos.

Símbolo Nº: 10

Tipo: Estado

Nombre/s Incremento rechazado

Noción Indica que un incremento no representa lo esperado por el cliente.

Se determina luego de realizar las pruebas de aceptación con el cliente.

Impacto Se deben redefinir los requisitos que no fueron bien interpretados hasta que el incremento pase a ser un incremento validado.

Se vuelven a realizar las actividades de análisis y codificación.

Símbolo Nº:11

Tipo: Estado

Nombre/s Incremento validado

Noción Indica que un incremento representa lo esperado por el cliente.

Se determina luego de realizar las pruebas de aceptación con el cliente.

Impacto Se puede proceder a la elaboración del siguiente incremento.

Si luego surgen nuevos requisitos los mismos se tendrán en cuenta en futuros incrementos y se deberá armar un nuevo plan de incremento.

Símbolo Nº: 12

Tipo: Objeto

Nombre/s Modelo de arquitectura del software

Noción Es un documento donde se indica la estructura e interacción entre las partes que componen el producto software.

Impacto Es realizada por el diseñador.

Se realiza durante la actividad de diseño.

Se utiliza para elaborar la estructura general de la implementación del producto.

Define la relación entre los elementos estructurales del producto software.

Es utilizado para la actividad de codificación.

Símbolo Nº: 13

Tipo: Objeto

Nombre/s Modelo de diseño

Noción Es la representación de la solución en el desarrollo del producto.

Impacto Es creado por el diseñador.

Se realiza durante la actividad de diseño.

Define las funcionalidades, los componentes y las interfaces que forman parte del producto.

Es utilizado para la actividad de codificación.

Símbolo Nº: 14

Tipo: Objeto

Nombre/s Núcleo

Noción Es el primer incremento entregado.

Es la base para futuros incrementos.

Contiene las principales funcionalidades del sistema.

Impacto Genera una versión estable del producto.

Genera un producto completo.

Es determinado por el cliente luego de que éste haya seleccionado cuales requisitos de la especificación de requisitos formarán parte del primer incremento.

Símbolo Nº: 15 Tipo: Objeto

Nombre/s Plan de incremento

Noción Documento que contiene toda la información del incremento a elaborar.

Contiene las funcionalidades, fechas y responsables a incluir en el incremento.

Impacto Se utiliza para organizar el próximo incremento a elaborar.

Lo lleva a cabo el analista.

Se elabora en conjunto con el cliente.

Símbolo Nº:16

Tipo: Objeto

Nombre/s Producto

Noción Es el software construido por el desarrollador.

Es la documentación que acompaña al software.

Son los datos que configuran el software.

Es lo que se entrega al finalizar un incremento.

Impacto Se lo puede modificar en cualquiera de las fases del proceso de software.

Su creación comienza desde la actividad de análisis.

Si las pruebas de aceptación con el cliente son exitosas se lo considera producto completo.

Si las pruebas de aceptación con el cliente no son exitosas se lo considera producto incompleto.

Símbolo Nº:17

Tipo: Estado

Nombre/s Producto completo

Noción Sucede luego de que el producto cumple con los requisitos establecidos por el cliente.

Impacto El producto puede ser entregado al cliente.

El producto es utilizado por el cliente.

Símbolo Nº:18

Tipo: Estado

Nombre/s Producto incompleto

Noción Sucede luego de que el producto no cumple con los requisitos establecidos por el cliente.

Indica que el producto no se encuentra apto para ser entregado.

Impacto El producto no puede ser entregado al cliente.

El producto se debe corregir para poder concluir el incremento.

Una vez corregido, probado y aceptado por el cliente mediante las pruebas de aceptación, pasa a ser un producto completo y el incremento pasa a ser un incremento validado.

Símbolo Nº:19 Tipo: Verbo

Nombre/s Prueba

Noción Es la actividad que permite evaluar el funcionamiento del producto.

Sucede luego de la actividad de codificación.

Es realizada por el desarrollador.

Es realizada por el tester.

Es realizada por el cliente.

Impacto El desarrollador puede llevar a cabo una prueba unitaria del producto.

El tester puede llevar a cabo una prueba de integración del producto.

El cliente puede llevar a cabo una prueba de aceptación del producto.

Símbolo Nº:20

Tipo: Verbo

Nombre/s Prueba de aceptación

Noción Sucede al momento de hacer la entrega del incremento al cliente.

Permite validar si el producto cumple con el funcionamiento esperado por el cliente.

Es realizada por el cliente.

Impacto Identificar errores en el producto.

Utiliza diversos juegos de datos para llevar a cabo el ensayo.

Si el producto cumple con todos los requisitos esperados por el cliente, entonces el incremento pasa a ser un incremento validado.

Si el producto no cumple con todos los requisitos esperados por el cliente, entonces el incremento pasa a ser un incremento rechazado.

Símbolo Nº:21

Tipo: Verbo

Nombre/s Prueba de integración

Noción Sucede durante la actividad de codificación.

Se lleva a cabo sobre el producto a entregar teniendo en cuenta que la nueva funcionalidad se integre con lo que actualmente se encuentra funcionando.

Es realizada por el tester.

Impacto Identificar errores en el producto.

Utiliza diversos juegos de datos para llevar a cabo el ensayo.

Los errores detectados son reportados al desarrollador para su corrección.

Símbolo Nº:22 Tipo: Verbo

Nombre/s Prueba unitaria

Noción Sucede durante la actividad de codificación.

Se lleva a cabo sobre el producto a entregar teniendo en cuenta solamente la funcionalidad que se agrega.

Es la actividad realizada por el desarrollador.

Impacto Identifica errores en el producto.

Utiliza diversos juegos de datos para llevar a cabo el ensayo.

El desarrollador se encarga de corregir los errores detectados.

Símbolo Nº:23 Tipo: Sujeto

Nombre/s Tester

Noción Es el encargado de realizar las pruebas de integración del producto.

Impacto Asegura que la funcionalidad que está probando se integre correctamente con el resto del producto.

Realiza la documentación de las pruebas de integración.

Informa los errores detectados para luego ser corregidos por el desarrollador.

Verifica las correcciones realizadas al producto por el desarrollador.

UML DIAGRAMAS CUANDO SE APLICA EN LINK JAJAJAJ

https://msdn.microsoft.com/es-MX/library/dd409432.aspx