sábado, 28 de abril de 2012

Ciclo de vida RUP.



RUP es un marco de desarrollo, te indica una forma de enfocar un proyecto de desarrollo de software y después en función de la naturaleza del mismo haces las adaptaciones oportunas (sin salirte de las fronteras que te marca la metodología porque de lo contrario estaríamos hablando de algo que no sería RUP).
RUP sigue principios de ingeniería del software para la obtención de sistemas de información de calidad y de esta forma proporcionar una alternativa que permita evitar que los productos que se obtengan caigan en los aspectos que caracterizan a la crisis del software (todavía muy presente en nuestros días).
RUP sigue una estrategia de ciclo de vida iterativo e incremental, pero de una forma un tanto peculiar, como vamos a ver a continuación.
El ciclo de vida RUP se divide en 4 fases: Iniciación, Elaboración, Construcción y Transición.
En cada fase se realizan una o más iteraciones (con el objeto de ir perfeccionando los objetivos, mediante el feedback del usuario) y hasta que no finaliza una fase no se comienza con la siguiente. Por regla general, la fase en la que se realizan más iteraciones es la Contrucción.
En cada fase se refinan los objetivos de las fases anteriores en el proceso de conseguir el objetivo o objetivos de la fase, por ejemplo, en la fase de construcción se pueden modificar, añadir o eliminar requisitos, casos de uso, etc… lo que tiene un impacto en lo obtenido en fases anteriores, acercándonos cada vez más a un sistema que satisfaga las necesidades de los usuarios.
En cada fase y en cada iteración se realiza un ciclo de vida en cascada con las siguientes etapas: Análisis, Diseño, Construcción (las tareas de programación que se realizan, sobre todo las fases de Construcción y Transición son perfectamente compatibles con la utilización de técnicas de integración continua y análisis estático de códigos), Pruebas/Integración/Implantación. El alcance del ciclo de vida depende en la fase en la que nos encontremos, es decir, aunque se realice un ciclo de vida en cascada en la fase de Iniciación, lo más probable es que no se llegue a construir nada o se llegue a algún a hacer algún prototipo de muy alto nivel.
Los objetivos que se persiguen en cada fase son los siguientes:
- Iniciación: Obtención de los objetivos, catálogo de requisitos, identificación de casos de uso.
- Elaboración: Refinamiento de los objetivos de la fase anterior, casos de uso, análisis, diseño, definición y establecimiento de la arquitectura base del sistema.
- Construcción: Refinamiento de los objetivos de las fases anteriores y construcción del sistema de información.
- Transición: Refinamiento de los objetivos de las fases anteriores e implementacion de sistemas de información (preparación del producto para su entrega y pasos a producción de versiones no finales (porque hay que hacer ajustes) y de la versión final prevista).
Por tanto, como se comentó anteriormente, en cada etapa y en cada iteración se perfeccionan los productos previos que hayan requerido algún cambio, todo eso mientras se intentan conseguir los objetivos concretos de la fase. De esta forma el ciclo de vida RUP sigue un modelo adaptativo de desarrollo de software.
de esta forma el reparto de esfuerzo entre actividades  varían de una fase a otra.

Una característica importante del RUP es que todo el proceso está guiado por los casos de uso, algo que resulta lógico cuando hablamos de modelos incrementales, ya que están orientados al usuario y como tal es importante tener siempre presente el esquema de interacción usuarios/sistema, los cuales vienen definidos por los casos de uso y sus escenarios.
RUP pretende la obtención de productos de muy alta calidad (extendiéndose esta no solo al cumplimiento de las expectativas del usuario, sino a la obtención de productos con una deuda  técnica  aceptable), si bien sus características: varias fases, múltiples iteraciones por fases, pueden provocar que el proceso de desarrollo sea costoso y que no se adapte a proyectos de pequeña escala, aunque el hecho de que siga un esquema incremental permitiría dar flexibilidad en el caso de que fuera necesario.


Aqui veremos un ejemplo del diagrama de caso de uso.






Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.
Actores
Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.
Casos de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema
Relaciones entre Casos de Uso
Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura 16 se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

En este veremos un diagrama de clase UML.

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


  • 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 de diagrama de secuencia


Tipos de mensajes
Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas:
De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

jueves, 26 de abril de 2012


Ciclo de vida SCRUM.
SCRUM es un proceso de desarrollo de software iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Scrum se promueve como complemento de otras metodologías, incluyendo XP, MSF o RUP
Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, implementacion y demás técnicas. Se define como un proceso de magnitud y control que implementa técnicas de control de procesos.
Scrum se basa en los siguientes principios ágiles:
· Colaboración estrecha con el cliente
· Predisposición y respuesta al cambio
· Personas sobre procesos
· Desarrollo incremental con entregas funcionales frecuentes
· Comunicación verbal directa entre los implicados en el proyecto
· Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y                       compromiso
· Simplicidad: Supresión de artefactos innecesarios en la gestión del proyecto
Este gráfico esquematiza perfectamente los roles, artefactos y el pro.

Ciclo de vida.

El Sprint es el período de tiempo durante el que se desarrolla un incremento de funcionalidad:
· Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeñas carreras.
· La duración máxima de un sprint es de 30 días.
· Durante el sprint no se puede modificar el trabajo que se ha acordado en el Sprint Backlog.
· Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el SCRUM   Master si decide que no es viable por algunas de las razones siguientes:
 La tecnología acordada no funciona
 Las circunstancias del negocio han cambiado
 El equipo ha tenido interferencias
Product Backlog:
 Listado con los requerimientos del sistema. Contiene: característica, requerimientos de desarrollo (no funcionales), tareas investigativas, bugs.
 Es responsabilidad del Propietario del producto:
 Es una combinación de funcionalidades y tareas
 Es un documento dinámico que incorpora constantemente las necesidades del sistema. Se mantiene durante todo el ciclo de vida (hasta el retiro del sistema).
Sprint Backlog
Tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de funcionalidad.
Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo
En Scrum se debe ir registrando los tiempos día a día para poder armar el gráfico de avance del proyecto
El equipo agrega tareas cuando lo crea necesario, pudiendo eliminar las que considere innecesarias, y ajusta estimaciones a medida se avanza




sábado, 21 de abril de 2012


de este lenguaje UML se desprenden:
diagrama de caso de uso
diagrama de clase
diagrama de secuencia
diagrama de actividades
entre otros.
-diagrama de caso de uso: un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.


-diagrama de clase:es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.


-diagrama de secuencia: Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.


-diagrama de actividades: representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
UML.

el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad, Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.