S9 MD D Metodología XP

S8 MD D Metodología XP

S7 MD D Ejemplo De Caso De Uso

S6 MD D Metodología y Filosofía RUP

METODOLOGÍA RUP

La metodología RUP , abreviatura de Rational Unified Process (o Proceso Unificado Racional), es un proceso propietario de la ingeniería de software creado por Rational Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es una abreviatura Rational Unified Process y lo que es una marca en el área de software, proporcionando técnicas que deben seguir los miembros del equipo de desarrollo de software con el fin de aumentar su productividad en el proceso de desarrollo.

FASES DE LA METODOLOGÍA RUP

FASE DE DISEÑO

La fase de diseño o de iniciación contiene los flujos de trabajo necesarios para el acuerdo de las partes interesadas – interesados – con los objetivos, la arquitectura y la planificación del proyecto. Si estos actores tienen un buen conocimiento, no será necesario analizar. De lo contrario, se requiere un análisis más elaborado.

En esta etapa, los requisitos esenciales del sistema se transforman en los casos de uso. El objetivo no es para cerrarlas en absoluto, sino sólo las que sean necesarias para dar forma a la opinión.    

El paso es generalmente corto y se utiliza para definir si es factible para continuar con el proyecto y definir los riesgos y el coste de la última. Un prototipo se puede hacer para que el cliente apruebe. Como cita el RUP, lo ideal es realizar iteraciones , las cuales deben estar bien definida en cuanto a su importe y objetivos.

FASE DE ELABORACIÓN

La preparación será para el diseño del sistema, como complemento de la encuesta y / o documentación de casos de uso, frente a la arquitectura del sistema, revisar el modelo de negocio para el proyecto e iniciar la versión del manual del usuario. Uno debe aceptar:

Descripción del producto (aumento + integración) es estable el plan del proyecto es fiable los costos son elegibles.

FASE DE CONSTRUCCIÓN

En la fase de construcción, el desarrollo físico del software se inicia, códigos de producción, pruebas alfa. Pruebas beta se llevaron a cabo al inicio de la fase de transición.

Se debe aceptar las pruebas, procesos estables y de prueba, y el código del sistema son línea de base.

FASE DE TRANSICIÓN

En esta fase es la entrega ( «despliegue») de software, que se lleva a cabo el plan de despliegue y entrega, el seguimiento y la calidad del software. Productos (lanzamientos, las versiones) se van a entregar, y coloque la satisfacción del cliente. Esta etapa también se lleva a cabo la formación de los usuarios.

                                                PRINCPIO DE DESARROLLO

LA FILOSOFÍA RUP

• ADAPTAR EL PROCESO:

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto, el tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.

•   EQUILIBRAR EL PROCESO

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados.

Debe poder encontrarse un equilibrio que satisfaga los deseos de todos .Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

•   DEMOSTRAR VALOR INTERATIVAMENTE

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.

• COLABORACIÓN ENTRE EQUIPOS

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

•  ENFOCARSE EN LA CALIDAD

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos dela producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente, también es una estrategia de desarrollo de software.

•   ELEVAR EL NIVEL DE ABTRACCIÓN

Este principio dominante motiva el uso de conceptos reutilizables tales como patrones de diseño del software, lenguajes 4GLo esquemas (frameworks) por nombrar algunos. Estos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.

S5 MD D- Proceso Unificado De Rational (RUP)

PROCESO UNIFICADO DE RATIONAL (RUP)

El Proceso Unificado de Rational o RUP (por sus siglas en inglés de Rational Unified Process) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM.1 Junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

PROCESO DIRIGIDO POR CASOS DE USOS

Los casos de uso no son sólo una herramienta para especificar los requisitos del sistema, sino que también guían su diseño, implementación y prueba. Los casos de uso constituyen un elemento integrador y una guía del trabajo.

Los casos de uso Inician el proceso de desarrollo y proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.

Basándose en los casos de uso, se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada caso de uso.

PROCESO CENTRADO EN LA ARQUITECTURA 

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

En el caso de RUP, además de utilizar los casos de uso para guiar el proceso, se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.

Existe una interacción entre los casos de uso y la arquitectura, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y en el futuro.

La arquitectura dentro de RUP se representa en varias vistas. Todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura. Según Kruchten Philippe (1998) “el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de casos de uso que es la que da cohesión a todas”.

Al final de la fase de elaboración se obtiene una “baseline” (base de referencia) de la arquitectura donde fueron seleccionados una serie de casos de uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más importantes para el usuario y aquellos que cubran las funcionalidades significativas).

                                            

PROCESO ITERATIVO E INCREMENTAL 

El equilibrio correcto entre los casos de uso y la arquitectura es muy parecido al equilibrio de la forma y la función en el desarrollo de un producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto.

Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando se termina. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones (que son una cantidad variable) según el proyecto, y en las que se hace un mayor o menor hincapié en los distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una “baseline” (base de referencia) de la arquitectura.

Para cada iteración se escogen algunos casos de uso, se refina su análisis y diseño, y se procede a su implementación y pruebas. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar, en cada fase participan todas las disciplinas, pero, dependiendo de la fase, es el esfuerzo dedicado a una disciplina.

                                          

S4 MD D Principales Metodologías Convencionales

Una Metodología de desarrollo de software, consiste principalmente en hacer uso de diversas herramientas, técnicas, métodos y modelos para el desarrollo. Regularmente este tipo de metodología, tienen la necesidad de venir documentadas, para que los programadores que estarán dentro de la planificación del proyecto, comprendan perfectamente la metodología y en algunos casos el ciclo de vida del software que se pretende seguir.

Principales Metodologías 

Algo que debes saber antes de dar paso a la descripción de cada una de las metodologías de la programación ágiles, es que aunque entre sus creadores crearon lo que fue el manifiesto ágil, la realidad es que cada una de las metodologías cuenta con su propia personalidad y características únicas, que la diferencian de las demás. Por eso a continuación, veremos cada una de las metodologías ágiles más populares, para que tengas un conocimiento más solido de lo que son y hacia donde van cada una de ellas.

Metodología Scrum

Desarrollo Incremental. Una metodología ágil sin desarrollo incremental, no puede ser considerada Scrum. Con incremental hago énfasis a olvidarnos de la planeación y de la ejecución de las lineas sin salirnos de lo pre establecido, pues con una metodología Scrum, el desarrollo se irá incrementando poco a poco, sin importar el orden en el cual se lleven a cabo los procesos.

Metodología Kanban

Siguiendo con las metodologías ágiles, nos encontramos con Kanban. Se trata de una metodología Japonesa, la cual consiste en ir etiquetando con tarjetas cada uno de los procesos que se deben llevar a cabo, también se le ha denominado como “Un sistema de producción de alta efectividad y productividad”. De hecho, empresas como la marca de autos Toyota, fueron una de las primeras en implementarla para acelerar los procesos de producción.

Metodología XP

Si hablamos de metodologías de la programación sin mencionar a la Metodología XP, es como no hablar de nada en absoluto. Esta metodología es posiblemente la mas destacada de las metodologías ágiles y esto se debe a su gran capacidad de adaptación ante cualquier tipo de imprevisto que surja. Pues la idea no es mantener ciertos requisitos desde que se está elaborando el proyecto, sino que durante el proceso, estos vayan cambiando o vayan evolucionando gradualmente sin complicaciones. Básicamente los creadores de esta metodología XP, consideran que es mejor adaptarte en el proceso a los requisitos que vayan apareciendo, que iniciar con requisitos y desarrollar un proyecto en base a eso.

S3 MD D- Técnicas y herramientas de desarrollo de Software

S2 MD D- Atributos de calidad de Software

ATRIBUTOS DE CALIDAD DE SOFTWARE

Son características no funcionales que se consideran deseables en un sistema de software .

1) SIMPLICIDAD

      Es la ausencia de complejidad o dificultades, en el desarrollo de software.

      a)  Complejidad Esencial: La que son propias o intrínsecas.

       b)  Complejidad Accidentales: Surgen por malas decisiones por diseño.

  2) CORRECTITUD

        Es la secuencia de errores.

1. Completud: capacidad del sistema para realizar.
2. Consistencia: operaciones que realiza el usuario.

 3) ROBUSTEZ

  Es un sistema que goza de buena salud y que brinda garantías.

4) FLEXIBILIDAD

 Es la capacidad para admitir cambios que pueden ser necesarios por un cambio de                                                    requerimientos como por la detención de un error que debe ser corregido.