lunes, 9 de julio de 2012

Planificar un Proceso Unificado de Desarrollo de Software (PUDS)

El proceso unificado de desarrollo de software (PUDS) abarca un conjunto de actividades que nos va llevando paso a paso por cada etapa del desarrollo guiando y coordinando la intervanción de los distintos roles involucrados.
Este proceso se apoya en tres pilares  durante toda la metodología, los cuales son:
  • Casos de Uso
  • Arquitectura
  • Concepto iterativo e incremental
Con más precisión, se dice que el proceso es dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.

Se presenta a continuación  una guía de pasos para ayudar a la planificación del PUDS.

Alcance

Se citan actividades y modelos básicos para un proceso de desrrollo de sistemas orientados a objetos, con un enfoque iterativo e incremental de los casos de uso.

Pasos Macro   

  • Planeación y elaboración: definir los requerimientos
  • Construcción: creación del sistema
  • Aplicación o puesta en marcha: transición de la implementación al uso

Ciclos iterativos de desarrollo   

Basado en el perfecionamiento secuencial de un sistema a través de multiples ciclos de desarrollo de análisis, diseño, implementación y pruebas.
Tras una fase preliminar de planeación y especificación, el desarrollo pasa a la fase de construcción a través de una serie de ciclos de desarrollo

Duración de un ciclo de desarrollo(Time boxing)   

Variable, de 2 semanas a 2 meses dependiendo de la complejidad.

Esquema de Pasos

1_Planeación y elaboración

Etapas




Definir el plan preliminar Referencias:


Elaborar informe preliminar de investigación (a) constante


Definir los requerimientos (b) opcional


Registrar los términos en el glosario (a) (c) aplazable


Imlplementar el prototipo (b, d) (d) orden variable


Definir los casos de uso (de alto nivel y esenciales)


Definir el modelo conceptual preliminar (c)


Definir la arquitectura preliminar del sistema (a, c, d)


Perfeccionar el plan

Artefactos generados


Plan: programa, recursos, presupuesto


Informe preliminar de investigación: motivos, alternativas, necesidades de la empresa


Especificación de los requerimientos


Glosario: diccionario e información afín(restricciones, reglas)


Prototipo


Casos de uso


Diagrama de casos de uso


Bosquejo de modelo conceptual

2_Construcción



Ciclo de Desarrollo 1


Perfeccionamiento del plan


Sincronización de artefactos con etapas anteriores


Análisis
Referencias:



Definir los casos esenciales de uso (a) (a) si todavia no se realiza



Perfeccionar los diagramas de casos de uso (b) constante



Perfeccionar el modelo conceptual (c) opcional



Perfeccionar el glosario (b)



Definir los diagramas de secuencia de los sistemas



Definir los contratos de operaciones



Definir los diagramas de estado (c)


Diseño
Referencias:



Definir los casos reales de uso (a) en paralelo con los diagramas de interacción



Definir los reportes, la interfaz de usuario y la secuencia de pantallas (b) orden variable



Perfeccionar la arquitectura del sistema (b)



Definir los diagramas de interacción



Definir los diagramas de diseño de clases (a)



Definir el esquema de la base de datos

Se deja para un próximo post, las etapas de Construcción y Prueba del Ciclo de desarrollo 1.

Fuente: Craig Larman - UML y Patrones

Generación de Casos de Uso

En este post, se dan algunos lineamientos para la generación de casos de uso.

DEFINICIÓN

El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar en proceso.
Los casos de uso son historias o casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluyen tácitamente los requerimientos de las historias que narran.
Los casos de uso pueden ser de 2 formatos, alto nivel y expandiso.

El caso de uso de alto nivel  describe un proceso muy brevemente, en dos o tres enunciados. Utilizarlo en el examen inicial de los requerimientos del proyecto.
El caso de uso expandido, describe un proceso más a fondo. Contiene un seccion de curso normal de los eventos, que los describe paso a paso.

CASO DE USO DE ALTO NIVEL
            Caso de uso:  Nombre del caso de uso
            Actores:           Lista de actores (agentes externos) , debe indicarse quien inicia el caso.
            Tipo:                 1. Primario, secundario u opcional.
                                      2. Esencial o real.
            Descripción:    Narrativa del caso.

 EJEMPLO CASO DE USO DE ALTO NIVEL
            Caso de uso:   Comprar Productos
            Actores:            Cliente, Cajero
            Tipo:                  1. Primario
            Descripción:     Un cliente llega a la caja con los artículos que comprará. El cajero registra los artículos y cobra el importe. Al terminar la operación, el cliente se marcha con los productos.

CASO DE USO EXPANDIDO
            Caso de uso:  Nombre del caso de uso
            Actores:           Lista de actores (agentes externos) , debe indocarse quien inicia el caso.
            Propósito:       Intención del caso de uso.
            Resumen:       Repetición del caso de uso de alto nivel o alguna síntesis similar.
            Tipo:                1. Primario, secundario u opcional.
                                     2. Esencial o real.
            Referencias    Casos de uso y funciones del sistema relacionados.
            Cruzadas

La sección intermedia curso normal de los eventos, describe los detalles de la comunicación interactiva entre los actores y el sistema. Un aspecto esencial de la sección es que explica la secuencia más común de eventos, la historia normal de las actividades y la terminación exitosa de un proceso. No incluye situaciones alternas.
           
Curso normal de los eventos
Acción del actor
Respuesta del sistema
Acciones numeradas de los actores
Descripciones numeradas de las respuestas del sistema
La última sección curso alterno de los eventos, describe las opciones o excepciones que pueden presentarse en relación con el curso normal. Se indica el número de línea y se describen las excepciones.

EJEMPLO CASO DE USO EXPANDIDO
            Caso de uso:  Comprar Productos en efectivo
            Actores:           Cliente (iniciador), Cajero
            Resumen:        Un cliente llega a la caja con los artículos que comprará. El cajero registra los artículos y cobra el importe en efectivo. Al terminar la operación, el cliente se marcha con los productos comprados.
            Tipo:                1. Primario
                                   2. Esencial
            Referencias      Funciones: R1.1, R1.2, R3.1
            Cruzadas
Curso normal de los eventos
Acción del actor
Respuesta del sistema
1. Comienza el caso cuando el cliente llega al punto de venta.

2. El cajero registra el indicador de cada producto. Si hay varios productos de la misma categoría, el cajero ingresa también su cantidad
3. determina el precio del producto e incorpora a la transacción actual la información correspondiente.
4. Al terminar de introducir el producto el cajero indica al punto de venta que concluyó
5. Calcula y presenta el total de la venta
6. El cajero le indica el total al cliente

7. El cliente efectua un pago en efectivo

8. El cajero registra la cantidad de efectivo recibida
9. Muestra al cliente la diferencia. Genera un recibo.
10. El cajero deposita el efectivo y extrae el cambio del pago.
El cajero da al cliente el cambio y el recibo impreso.
11. Registra la venta concluida
12. El cliente se marcha con los artículos comprados


Cursos alternos
·         Línea 2: Introducción de identificador no válido. Indocir error.
·         Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta.

TIPOS DE CASOS DE USO 1_ (PRIMARIOS, SECUNDARIOS, OPCIONALES)
  • Casos primarios de uso: representan los procesos comunes más importantes.
  • Casos secundarios de uso: representan procesos menores o raros.
  • Casos opcionales de uso: representan procesos que pueden no abordarse

TIPOS DE CASOS DE USO 2_ (ESENCIALES, REALES)
  • Casos esenciales de uso: son casos expandidos que se expresan en forma teórica y que contiene poca tecnología y pocos detalles de implementación. Las decisiones de diseño se posponen y se abstraen de la realidad.
Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción.
  • Casos reales de uso: describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías específicas de entrada, salida, etc.
 
ERROR  COMÚN EN CASOS DE USO
Un error común es representar, los pasos, operaciones o transacciones individuales como casos. Un caso es la descripción de un proceso de principio a fin, relativamente amplia. Suele abarcar muchos pasos o transacciones; normalmente no es un paso ni una actividad individual del proceso.

IDENTIFICACIÓN DE CASOS DE USO
Se sugieren dos posibles métodos para la identificación de los casos de uso.
  • Basado en los actores
    1. Se identifican los actores relacionados con el sistema
    2. En cada actor se identifican los procesos que inician o en que participan.
  • Basado en eventos
    1. Se identifican los eventos externos a los que el sistema debe responder
    2. Se relacionan los eventos con los actores y con los casos de uso.
FRONTERAS
Un caso de uso describe la interacción con un sistema. Las fronteras ordinarias de un sistema son:
  • La frontera hardware/software de un dispositivo o sistema de cómputo
  • El departamento de una organización
  • La organización entera.
DIAGRAMAS DE CASOS DE USO
Explica gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre estos y los casos de uso. Estos últimos se muestran en óvalos y los actores son figuras estilizadas. Hay líneas de comunicaciones entre los casos y los actores. Las flechas indican el flujo de información o el estímulo.
El diagrama tiene por objeto ofrecer una clase de diagrama contextual que permite conocer rápidamente los actores externos de un sistema y las formas básicas en que lo utilizan.


CLASIFICACION DE LOS CASOS DE USO
Es necesario clasificar los casos de uso, y los casos de alto rango han de tratarse al inicio de los ciclos de desarrollo. La estrategia general consiste en escoger primero los casos que más influyen  en la arquitectura básica.
Las cualidades que aumenta la clasificación son:
a.     Tener una fuerte repercusión en el diseño arquitectónico; por ejemplo incorporar muchas clases a la capa de dominio o requerir servicios de persistencia.
b.    Con relativamente poco esfuerzo, obtener información o ideas importantes sobre el diseño.
c.     Incluir funciones riesgosas, urgentes o complejas.
d.    Requerir una investigación a fondo o tecnología nueva y riesgosa.
e.     Representar procesos primarios de la línea de negocios.

·         Podría realizarse un esquema de categorías, para brindar una clasificación simple y poco rigorosa.
·         De otra manera, se podrían aplicar puntuaciones, basándose en las cualidades que influyen en la clasificación:

Caso de Uso
a
b
c
d
e
Suma
Caso 1 …….
9
2
3
5
4
23
Caso 2 …….







ASIGNACION DE LOS CASOS DE USO
Siempre que se asigne un caso de uso, es necesario estimar si es posible resolverlo íntegramente en el lapso determinado de un ciclo, o si el trabajo tiene que ser distribuido en varios ciclos. En este último caso, el caso de uso se redefine a partir de varias versiones de él, que van abarcando requerimientos cada vez más exhaustivos. Cada versión se limita a incluir lo que se estima como una cantidad razonable de trabajo dentro del límite de duración fija del ciclo.
Las versiones se distribuyen luego a lo largo de una serie de ciclos de desarrollo, junto con otros casos de uso.

Fuente: Craig Larman - UML y Patrones

domingo, 8 de julio de 2012

Arquitectura de aplicaciones Microsoft

La última versión de la guía de arquitectura de aplicaciones Microsoft, sólo en ingles. Para visualizar desde el sitio y en formato descargable .pdf.
La guía está diseñada para ayudar a los desarrolladores y arquitectos de diseño de la solución a crear aplicaciones eficaces y de alta calidad que utilizan la plataforma de Microsoft y el NET Framework con mayor rapidez y con menos riesgo. Proporciona una guía para el uso de los principios de la arquitectura, los principios de diseño y patrones que son probados y confiables. La guía se presenta en secciones que corresponden a la arquitectura mayor y puntos de enfoque de diseño. Se ha diseñado para ser utilizado como un recurso de referencia o para ser leída de principio a fin.

Esta guía reemplaza a estas dos guías anteriores.

1.     Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios

En esta guía se proporcionan las instrucciones a nivel de diseño para la arquitectura y el diseño de aplicaciones y servicios de .NET Framework, basados en Windows 2000 y en la versión 1.0 de .NET Framework. Se enfoca en la partición de la funcionalidad de las aplicaciones en componentes, y se describen sus principales características de diseño, cómo se aplica la seguridad, administración y comunicación a cada capa; asimismo, se proporciona información sobre el modo de implementación de los componentes..

2.     Diseño de componentes de niveles y traspaso de datos a través de éstos


Al diseñar una aplicación distribuida, tiene que decidir la forma de acceder y representar los datos de negocio asociados a su aplicación. Este documento proporciona una guía para ayudarle a elegir la forma más adecuada de  exposición, persistencia y transmisión de los datos a través de los niveles de una aplicación..

Entradas populares