lunes, 22 de mayo de 2017

INTRODUCCIÓN A LOS PROCESOS ÁGILES DE DESARROLLO

INTRODUCCIÓN A LOS PROCESOS ÁGILES DE DESARROLLO

                                                                                          

          El desarrollo ágil de software 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 ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración 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.


Uso de la herramienta Cake en el modelado Las herramientas Cake

Uso de la herramienta Cake en el modelado Las herramientas Cake (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas o programas informáticos destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.


domingo, 21 de mayo de 2017

Símbolos y Notaciones de los Diagramas

Diagramas, Símbolos y Notación
Un diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama está contenido dentro de un paquete.
La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas. La información está sobre todo en la topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en un gráfico en la forma analizada de la notación.
La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie bidimensional.
Hay cuatro clases de construcciones gráficas que se usan en la notación de UML : íconos, símbolos bidimensionales, rutas y cadenas.
Un icono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como símbolos independientes que puedan o no conectar con las rutas.
Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas.
Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular gráficamente. un segmento no debería existir separado de su ruta. Las rutas siempre van conectadas en ambos extremos.
Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información del modelo subyacente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en un diagrama.



Tipos de Diagrama de clases

Diagrama de clases

Ejemplo de diagrama de clases de una Universidad.
En ingeniería de software, un diagrama de clases enLenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.
Índice
  [ocultar] 
Miembros
UML proporciona mecanismos para representar los miembros de la clase, como atributos y métodos, así como información adicional sobre ellos.
Visibilidad
Para especificar la visibilidad de un miembro de la clase (es decir, cualquier atributo o método), se coloca uno de los siguientes signos delante de ese miembro:

+
Público
-
Privado
#
Protegido
/
Derivado (se puede combinar con otro)
~
Paquete

Ámbitos
UML especifica dos tipos de ámbitos para los miembros: instancias y clasificadores y estos últimos se representan connombres subrayados.
  • Los miembros clasificadores se denotan comúnmente como “estáticos” en muchos lenguajes de programación. Su ámbito es la propia clase.
    • Los valores de los atributos son los mismos en todas las instancias
    • La invocación de métodos no afecta al estado de las instancias
  • Los miembros instancias tienen como ámbito una instancia específica.
    • Los valores de los atributos pueden variar entre instancias
    • La invocación de métodos puede afectar al estado de las instancias(es decir, cambiar el valor de sus atributos)
Para indicar que un miembro posee un ámbito de clasificador, hay que subrayar su nombre. De lo contrario, se asume por defecto que tendrá ámbito de instancia.
Relaciones

Una relación es un término general que abarca los tipos específicos de conexiones lógicas que se pueden encontrar en los diagramas de clases y objetos. UML presenta las siguientes relaciones:
Relaciones a nivel de instancia

Enlace

Un enlace es la relación más básica entre objetos.
Asociación



Ejemplo de diagrama de clases con una asociación de dos clases (en inglés)
Una asociación representa a una familia de enlaces. Una asociación binaria (entre dos clases) normalmente se representa con una línea continua. Una misma asociación puede relacionar cualquier número de clases. Una asociación que relacione tres clases se llama asociación ternaria.
A una asociación se le puede asignar un nombre, y en sus extremos se puede hacer indicaciones, como el rol que desempeña la asociación, los nombres de las clases relacionadas, su multiplicidad, su visibilidad, y otras propiedades.
Hay cuatro tipos diferentes de asociación: bidireccional, unidireccional, agregación (en la que se incluye la composición) y reflexiva. Las asociaciones unidireccional y bidireccional son las más comunes.
Por ejemplo, una clase vuelo se asocia con una clase avión de forma bidireccional. La asociación representa la relación estática que comparten los objetos de ambas clases.
Agregación



Ejemplo de diagrama de clases con una agregación entre dos clases (en inglés)
La agregación es una variante de la relación de asociación “tiene un”: la agregación es más específica que la asociación. Se trata de una asociación que representa una relación de tipo parte-todo o parte-de.
Como se puede ver en la imagen del ejemplo (en inglés), un Profesor 'tiene una' clase a la que enseña.
Al ser un tipo de asociación, una agregación puede tener un nombre y las mismas indicaciones en los extremos de la línea. Sin embargo, una agregación no puede incluir más de dos clases; debe ser una asociación binaria.
Una agregación se puede dar cuando una clase es una colección o un contenedor de otras clases, pero a su vez, el tiempo de vida de las clases contenidas no tienen una dependencia fuerte del tiempo de vida de la clase contenedora (deel todo). Es decir, el contenido de la clase contenedora no se destruye automáticamente cuando desaparece dicha clase.
En UML, se representa gráficamente con un rombo hueco junto a la clase contenedora con una línea que lo conecta a la clase contenida. Todo este conjunto es, semánticamente, un objeto extendido que es tratado como una única unidad en muchas operaciones, aunque físicamente está hecho de varios objetos más pequeños.
Diagramas[editar]
  • El diagrama de clases puede tener como ejemplo: una clase que seria un objeto o persona misma en la cual se especifica cada acción y especificación.
  • Propiedades de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.
  • El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.
  • Presenta las clases del sistema con sus relaciones estructurales y de herencia.
  • El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.


Elementos para interpretar el modelado del software

El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el Object Management Group (OMG).
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, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.
Es importante remarcar 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.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado RacionalRational Unified Process o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
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, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML solo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.



PROCESO UNIFICADO DE DESARROLLO
Proceso Unificado de Desarrollo.

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar JacobsonGrady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

Fases de Desarrollo.

Fase de Inicio.
  • Es la fase más pequeña del proyecto e, idealmente, debe realizarse también en un periodo de tiempo pequeño (una única iteración). 
  • El hecho de llevar a cabo una fase de inicio muy larga indica que se esta realizando una especificación previa excesiva, lo que responde más a un modelo en cascada.
  • Objetivos:   
o   Establecer una justificación para el proyecto.  
o   Establecer el ámbito del proyecto. 
o   Esbozar los casos de uso y los requisitos clave que dirigirán  las decisiones de diseño.
o   Esbozar las arquitecturas candidatas. 
o   Identificar riesgos.
o   Preparar el plan del proyecto y la estimación de costes.
  • El hito de final de fase se conoce como Hito Objetivo del Ciclo de Vida.
Fase de Elaboración.
  • Durante esta fase se capturan la mayoría de los requisitos del sistema.
  • Los objetivos principales de esta fase serán la identificación de riesgos y establecer y validar la arquitectura del sistema.
  • Base de Arquitectura Ejecutable:
·  La arquitectura se valida a través de la implementación de una Base de   Arquitectura Ejecutable: se trata de una implementación parcial del sistema que incluye los componentes principales del mismo.
·   Al final de la fase de elaboración la base de arquitectura ejecutable debe demostrar que soporta los aspectos clave de la funcionalidad del sistema y que muestra la conducta adecuada en términos de rendimiento, escalabilidad  y coste.
 


  •   Al final de la fase se elabora un plan para la fase de construcción.
  •  El hito arquitectura del ciclo de vida marca el final de la fase.  

Fase de construcción.
  •  Es la fase más larga de proyecto.
  •  El sistema es construido en base a lo especificado en la fase de elaboración.
  •    Las características del sistema se implementan en una serie de iteraciones cortas y limitadas en el tiempo.  
  •    El resultado de cada iteración es una versión ejecutable de software.
  •  El hito de capacidad operativa inicial marca el final de la fase.
Fase de transición.
  • En esta fase el sistema es desplegado para los usuarios finales.
  • La retroalimentación recibida permite incorporar refinamientos al sistema en las sucesivas iteraciones.
  • Esta iteración también cubre el entrenamiento de los usuarios para la utilización del sistema.
  •  El hito de lanzamiento del producto marca el final de la fase.

Disciplinas. 

Modelado del negocio.
  • El objetivo es establecer un canal de comunicación entre los ingenieros del negocio y los ingenieros del software.
  • Los ingenieros del software deben conocer la estructura y dinámica de la organización objetivo (el cliente), los problemas actuales y sus posibles mejoras.
  • Se plasma en la identificación del modelo del dominio en el que se visualizan los aspectos básicos del dominio de aplicación.    

Requisitos.
  • El objetivo es describir que es lo que tiene que hacer el sistema y poner a los desarrolladores y al cliente de acuerdo en esta  descripción.
Análisis y diseño.
  • Describe como el software será realizado en la fase de implementación.
  • Se plasma en un modelo de diseño que consiste en una serie de clases (agrupadas en paquetes y subsistemas) con interfaces bien definidos.
  • También contiene descripciones de cómo los objetos colaboran para realizar las acciones incluidas en los casos de uso.
Implementación.
  • Se implementan las clases y objetos en términos de componentes (ficheros fuentes, binarios, ejecutables, entre otros).
Prueba.
  • Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integración entre objetos, la implementación de todos los requisitos, entre otros.
Despliegue.
  • Se crea la versión externa del producto, se empaqueta, se distribuye y se instala en el lugar de trabajo. También se da asistencia y ayuda a los usuarios.
Gestión de configuraciones y cambios.
  • Gestiona aspectos como los sistemas de control de versiones.
  •  Controla las peticiones de cambios clasificándolas según su estado (nueva, registrada, aprobada, asignada, completa, entre otros).
  • Los datos se almacenan en una base de datos y se pueden obtener informes periódicos.
  •  Herramientas  como Rational ClearQuest o Bugzilla. 
Gestión del proyecto.
  •   Encargada de definir los planes del proyecto global, los planes de fase y los planes de iteración.
Entorno.
  •   Se centra en las actividades necesarias para configurar el proceso de un proyecto.

  •    El objetivo es proveer a la organización de desarrollo software de un entorno de trabajo (que incluye procedimientos y herramientas) que soporten al equipo de desarrollo.                              






Metodología Empleada en el Proceso de Desarrollo del Software

Un proceso, se define como una serie de operaciones usadas en la creación de un producto. Un proceso de software se puede definir de las siguientes formas: Un proceso de software define el conjunto de tareas, que tienen que ser realizadas para producir un producto de software de alta calidad. En otras palabras, este es el enfoque que se toma para el desarrollo del software. Es el proceso que se sigue para construir el producto de software desde la concepción de una idea, hasta la entrega y el retiro final del sistema.