miércoles, 30 de abril de 2008

Modelado con UML

Las notaciones nos permiten formular ideas complejas en forma resumida y precisa.

Para que una notación permita la comunicación precisa debe tener una semántica bien definida, debe ser muy adecuada para la representación de un aspecto dado de un sistema y debe ser bien comprendida por los participantes del proyecto. En esto ultimo se encuentra la fortaleza de los estándares y las convenciones.

Seleccionamos el UML (Lenguaje de Modelado Unificado) como notación estándar, ya que tiene una semántica bien definida, proporciona un espectro de notaciones para la representación de diferentes aspectos de un sistema y ha sido aceptado como una notación estándar en la industria.

UML es una notación que se produjo como resultado de la unificación de la técnica de modelado de objetos. El UML ha sido diseñado para resolver un amplio rango de aplicaciones.

El desarrollo de sistemas se enfoca en tres modelos diferentes del sistema:

Modelo funcional: representado en UML con diagramas de caso de uso, describe la funcionalidad del sistema desde el punto de vista del usuario.

Modelo de objetos: representado en UML con diagramas del clase, describe la estructura de un sistema desde el punto de vista de objetos, atributos, asociaciones y operaciones.

Modelo dinámico: representado en UML con diagramas de secuencia, diagramas de gráfica de estado y diagramas de actividad, describe el comportamiento interno del sistema.


Panorámica del UML.

Se presentan 5 notaciones UML:

Diagramas de caso de uso.
Diagrama de clase.
Diagrama de secuencia.
Diagrama de estado. (*)
Diagrama de actividad (*)



Diagrama de caso de uso.

Los casos de uso se utilizan durante la obtención de requerimientos y el análisis para representar la funcionalidad del sistema. Los casos de uso se enfocan en el comportamiento del sistema desde un punto de vista externo y que proporciona un resultado visible para un actor.

Un actor puede ser cualquier entidad que interactúa con el sistema ya sea un usuario u otro sistema. La identificación de los actores y los casos de uso da como resultado la definición de la frontera del sistema, esto es la diferencia entre las tareas realizadas por el sistema y las realizadas por su ambiente.


El actor UsuarioReloj puede consultar la hora con el caso de uso LeerHora, o ajustar la hora con el caso de uso AjustarHora. Sin embargo, solo el actor PersonaReparadoraRelojes puede cambiar la batería del reloj con el caso de uso CambiarBateria


Diagrama de clase

Se utilizan diagramas de clase para describir la estructura del sistema. Las clases son abstracciones que especifican la estructura y el comportamiento común de un conjunto de objetos. Los objetos son instancias de las clases que se crean, modifican y se destruyen durante la ejecución del sistema.

Los diagramas de clase describen el sistema desde el punto de vista de objetos, clases, atributos, operaciones y sus asociaciones.


El diagrama de clase describe todos los elementos de todos los relojes de la clase RelojSimple.Todos estos objetos de reloj tienen una asociación con un objeto de la clase BotonImprimible, un objeto de la clase pantalla, un objeto de la clase hora.


Diagrama de secuencia

Los diagramas de secuencia se usan para formalizar el comportamiento del sistema y para visualizar la comunicación entre objetos. Son útiles para la identificación de objetos adicionales que participan en los casos de uso. A los objetos involucrados en un caso de uso les llamamos objetos participantes. Un diagrama de secuencia representa las interacciones que suceden entre esos objetos.



La imagen corresponde al diagrama de secuencia para el caso de uso AjustarHora de nuestro RelojSimple, la primera columna representa al actor UsuarioReloj que inicia el caso de uso. Las demás columnas representan la linea de tiempo de los objetos que participan en este caso de uso.

Este articulo es solo una introducción al modelado con uml, existen otra serie de diagramas que ire agregando o escribiendo otros articulos para profundizar en este tema

Saludos y suerte !!

miércoles, 23 de abril de 2008

Requerimientos

Toma de Requerimientos

Podemos definir un requerimiento como una condicion o capacidad que debe estar presente
en un sistema o componentes de este para satisfacer un contrato, estandar, especificación u otro documento formal (Std 610.12-1900, IEEE:62)

Otra definicion adoptada es que un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar un sistema.

Los requerimientos son una pieza fundamental en proyectos de Software, en base a esto se puede determinar y hacer estimaciones de tiempo, costos, definir recursos necesarios, elaborar cronogramas y cartas gantt, etc.
Permite verificar y comprobar si se obtuvieron los objetivos establecidos para el proyecto.

Muchas veces los proyectos que fracasan por que la toma de requerimientos es incompleta o por el mal manejo de los cambios en los requerimientos durante la vida de desarrollo del Software.

Clasificación de Requerimientos
La clasificación de requerimientos es importante, de esta manera podemos definir y abstraer con mayor detalle los tipos de requerimientos a los que nos enfrentamos, los requerimientos se pueden clasificar en:
  • Requerimientos Funcionales.
  • Requerimientos no Funcionales.
  • Requerimientos de Implementación.
Requerimientos Funcionales: Describen las interacciones entre el sistema y su entorno, usuarios u otros sistemas

Requerimientos No Funcionales: Describen aspectos visibles del sistema por el usuario, y que no se relacionan directamente con el comportamiento funcional del sistema.

Requerimientos de Implementación: Corresponden a las necesidades del cliente que restringen la implementación, como la plataforma tecnológica, de hardware, redes, etc.

Características en la Toma de Requerimientos
Las características mas importantes y fundamentales para una toma de requerimientos deben contener los siguientes puntos:
  • Un requerimientos debe estar especificado siempre por escrito.
  • Un requerimiento debe ser posible de probar y verificar.
  • Un requerimiento debe ser conciso.
  • Un requerimiento debe ser completo.
  • Un requerimiento debe ser consistente.
  • Un requerimiento no debe ser ambiguo.

Ingeniería de Requerimientos
La Ingeniería de requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajaran, incluye el conjunto de tareas que conducen a comprender cual sera el impacto del software sobre el negocio, que es lo que el cliente quiere y como interactuaran los usuarios finales con el software.

También la ingeniería de requerimientos comprende el proceso de desarrollar una especificación del software, estas pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema

Importancia de la Ingeniería de Requerimientos:
  • Permite gestionar las necesidades del proyecto de manera documental y estructurada.
  • Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados.
  • Disminuyen los costos y retrasos del proyecto.
  • Mejora la calidad del Software.
  • Mejora la comunicación entre equipos.
  • Evita rechazos de usuarios finales.

Actividades de la IR
  • Estudio de la viabilidad
  • Obtención y análisis de requerimientos.
  • Validación de requerimientos.
  • Administración de requerimientos.

Estudio de la viabilidad
Un estudio de la viabilidad es a corto plazo, y orientado a resolver si el sistema:
Contribuye a los objetivos de la organización?
Se puede implementar con tecnología actual dentro de costo y tiempo?
Puede integrarse a otros existentes en la organización?

Obtención y análisis de requerimientos
  • Descubrimiento de requerimientos,
  • Puntos de vista: toma en cuenta la existencia de varias perspectivas y provee de una marco de trabajo para descubrir conflictos.
  • Entrevistas.
  • Escenario: son descripciones de ejemplos de las sesiones de interacción del sistema, se inicio con un bosquejo y durante la obtención se agregan detalles.
  • Casos de Uso (UML)
  • Clasificación y organización de requerimientos
  • Orden por prioridades y negociación
  • Documentación

Validación de requerimientos
  • Similar al análisis pero comprende un bosquejo completo del documento.
  • Importante, ya que los errores en los requerimientos pueden conducir a costos excesivos si se descubren durante el desarrollo o después en la implantación.

Técnicas de validación.
  • Revisiones de requerimientos y su documentación.
  • Construcción de prototipos.
  • Generación de casos de prueba.
  • Análisis de consistencia automático con herramientas de software.

Administración de requerimientos.
Los requerimientos de sistemas grandes o complejos son siempre cambiantes.
Los sistemas grandes usualmente se desarrollan para mejorar el status quo.
Surgirán nuevos requerimientos debido a:
  • Comunidad diversa de usuarios, los requerimientos finales son comúnmente un termino medio.
  • Quien paga es raramente quien usa el sistema.
  • Entorno del negocio cambiante.

Se debe generar un proceso formal para que todos los cambios propuestos sean tratados de forma consistente.

Etapas:
  • Análisis del problema y especificación del cambio
  • Análisis del cambio y costos
  • Implementación del cambio
Siempre existe la tentación de hacer un cambio de manera urgente al sistema, y en retrospectiva
modificar el documento de requerimientos. Esto conduce a un desface e inconsistencia

Requerimientos en Normas de calidad
MPS-BR: Norma estándar basada en conceptos similares a los tratados, siguiere la utilización de
UML(casos de uso, secuencia, actividades, estados, etc.) con formato de documentos definidos y
adoptados por la industria como estándar para el modelado y diseño de sistemas con UML.
Propuesta: Utilización de diagramas UML y Procesos, con un modelo de entrega por etapas con
verificación y administración de requerimientos basado en documentación de la norma estándar IEEE-STD-803-1998

Casos de Uso (UML)
UML, de sus siglas en ingles (Unified Modeling Language) se relaciona directamente con el desarrollo de software orientado a objetos y en este nos encontramos con los casos de uso, los cuales nos apoyan al análisis de los requerimientos como una técnica de adquisición de estos, una definición es que los Casos de Uso no son parte del diseño, sino parte del análisis. De forma que al ser parte del análisis nos ayudan a describir qué es lo que el sistema debe hacer. Los Casos de Uso son lo qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.


Notación de casos de uso:



Lo importante de los casos de uso no es el dibujo que acostumbramos a ver, entonces ¿que es lo importante?, Lo realmente útil de los casos de uso es el documento que describe el caso de uso, en este documento se explica la forma de interactuar entre el sistema y el usuario.
Este podría ser el caso de uso de escribir un mensaje en un foro.



Herramientas de apoyo
Es importante para la buena gestión y administración de tareas, las cuales nacen muchas veces de un requerimiento del cliente, contar con una herramienta tecnológica o aplicación que nos apoye en esta gestión, una aplicación de tipo Workflow que nos permita hacer seguimiento de estas tareas que se pueden asignar a los participantes del proyecto.

Mejores Prácticas
¿Que son las mejores prácticas?
Un conjunto organizado y documentado de principios, métodos y procesos que incrementan la calidad y la productividad en del desarrollo de software.

Mejores practicas orientadas hacia:

El recurso humano.
  • Gestión por Roles
  • Administración del Tiempo
  • Gestión del Conocimiento
  • Capacitación basada en competencias

El proceso.
  • Desarrollo Iterativo
  • Administración de requisitos
  • Uso de arquitectura basada en componentes
  • Modelado visual
  • Aseguramiento continuo de la calidad
  • Administración de cambios

El Producto
  • La Arquitectura
  • El Diseño
  • Las Base de datos
  • Las Pruebas
  • La Operación

Saludos y Suerte !!