jueves, 29 de marzo de 2012


Técnicas y métodos de modelado de sistema

un sistema se considera como un conjunto integrado de elementos que realizan una misión u objetivo especifico. Por consiguiente lo que caracteriza a un sistema es la alta integración de sus elementos constructivos, que pueden ser elementos físicos o lógicos, y la consecución de un objetivo único o misión para la que el sistema a sido desarrollado. Este modelo representa distintos aspectos de un sistema y resumidamente son:





·      Propósito/ objetivos. Esta vista representa las necesidades del cliente y usuarios del sistema.
·         Estructura, también llamada de forma, representa los elementos o partes de un sistema y su organización. Parte fundamental de la descripción de los elementos de un sistema es la definición de las interfaces de estos.
·         Comportamiento, también llamada vista funcional,describe lo que hace el sistema, a diferencia de la vista estructural que describe como es el sistema.
·         Datos. esta vista es importante en aquellos sistemas donde la información a gestionar es elevada. La vista de datos describe los datos y relaciones entre estos de importancia para el sistema.
·         Dirección. Esta vista representa ls aspectos de dirección de proyecto del sistema, su planificación, programación y presupuesto.


Modelado de caso de uso
El modelado de caso de uso es un método orientado a los usuarios para identificar necesidades funcionales de un nuevo sistema de información. El modelado de casos de uso es una técnica que permite modelar las funciones de un sistema en términos de eventos, de quien inicia los eventos y de cómo responde el sistema a estos eventos. 


algunos de ellos se enumeran a continuación:







·         Proporciona una herramienta para capturar necesidades funcionales.
·         Ayuda a descomponer el sistema en partes más pequeñas y manejables.
·         Proporciona un lenguaje común entre los usuarios de sistemas y el analista y el diseñador de sistemas. El problema en la identificación de las necesidades de un nuevo sistema de información a sido consecuencia de una mala comunicación entre usuarios y el analista de sistemas.
·         Proporciona un medio para identificar, asignar, rastrear, controlar y gestionar las actividades para el desarrollo de sistemas.
·         Proporciona una ayuda en la estimación del alcance, el esfuerzo y el calendario.
·          
·         Proporciona una base para comprobar el sistema en términos de definir planes de prueba y casos de prueba.
·         Proporciona una base para el desarrollo de manuales y sistemas de ayuda para los usuarios. Asi como documentación sobre el desarrollo del sistema.
·         Proporciona una herramienta para hacer un seguimiento de las necesidades.
·         Proporciona un punto de inicio para la identificación de las entidades en el  modelo de datos.
·         Proporciona especificaciones funcionales para el diseño de las interfaces entre el sistema y los ususarios.
·         Proporciona un medio para definir necesidades de acceso a las bases de datos en términos de añadir, cambiar, eliminar y leer.
·         Proporciona un marco  de trabajo para el  desarrollo de un nuevo sistema de i información.

Prototipos y técnicas de análisis
Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar y analizar una aplicación que representa el sistema que sería implementado (McCracken y Jackson, 1982). Dicha aplicación, llamada prototipo, está compuesta por los componentes que se desean evaluar (i.e. las funciones principales). Las etapas del modelo son:
- Investigación preliminar.
- Colecta y refinamiento de los requerimientos y proyecto rápido:

-          Análisis y especificación del prototipo.
-          Diseño y construcción del prototipo.
-          Evaluación del prototipo por el cliente.
-          Renacimiento del prototipo.

Diseño técnico.
- Programación y test.
-         - Operación y mantenimiento.

Para construir un prototipo del software se aplican los siguientes pasos:


  • Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo.
Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es esencial que: 1) el cliente participe en la evaluación y refinamiento del prototipo, y 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo.


  • Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos.
Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos.


  • Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo.
El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado.


  •  El software del prototipo se crea, prueba y refina
Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen.
Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre-maquina usando una serie de hojas de historia.


  • Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicación y sugiere modificaciones.
Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.


  •  Los pasos 4 y 5 se repiten iterativa mente hasta que todos los requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción.
El paradigma de construcción del prototipo puede ser conducido con uno o dos objetivos en mente: 1) el propósito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de programación, o 2) el propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus meritos y ambos crean problemas.




MODELADO DEL NEGOCIO
Con esta disciplina se pretende llegar a un mejor entendimiento de la organización donde se va a implantar el sistema de software. Los principales motivos para ejecutar esta disciplina son los siguientes: asegurarse de que el producto será algo útil y no un obstáculo; conseguir que se ajuste de la mejor forma posible en la organización donde se va a implantar; y tener un marco común para el equipo de proyecto, los clientes y los usuarios finales. Esta disciplina no será siempre necesaria. Si sólo se añaden funcionalidades que no verán los usuarios directamente, no hará falta.
Los objetivos específicos del modelado de negocio son:
  1. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.
  2. Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo en su mejora.
  3. Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
  4. Entender la estructura y la dinámica de la organización para la cual el sistema va a ser desarrollado (organización objetivo).
Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definición de los requerimientos del sistema.
La importancia de esta disciplina radica en que sin el panorama completo del alcance del negocio y sin el entendimiento de sus procesos no podrán identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informáticos, que son el producto final del desarrollo.


USO DE LOS DIAGRAMAS DE ACTIVIDADES PARA EL MODELADO DEL NEGOCIO





















Por regla general cuando nos encargan diseñar un sistema deinformación estamos adaptando unos flujos de trabajo y comportamientos a un sistema informático. Poder representar correctamente estos flujos y entenderlos nos será de gran ayuda a la hora de diseñar nuestro sistema. 
Dentro de UMLdisponemos del diagrama de actividades, este diagrama nos servirápara definir los procesos de negocio, que ha de contemplar nuestrosistema de información. Los diagramas de actividades forman parte del modelado del negocio. Al realizar el diagrama de actividades podemos ver de una forma claratodas actividades y su flujo lógico, incluyendo los procesos que seejecutan en paralelo, (Y no solamente el flujo secuencial), flujo deactividades y no de datos, esta es una de las diferencias principales entre el diagrama de actividades y otro tipo de diagramas de flujo, y esasí como debemos de pensar cuando diseñamos un diagrama deactividades.
Este tipo de diagrama no es solamente utilizado en la ingeniería del software, sino en otras áreas donde se ha de definir procesos de trabajo, ya que con ellos podemos representar la secuencia lógica de un proceso de negocio, desglosando este en diferentes actividades, esta es una de las grandes virtudes de este tipo de diagrama. Los diagramas de actividades aparecieron en la notación UML 1.3, y es uno de los utilizados para el modelado de los aspectos dinámicos del sistema. Y estos están basados en los diagramas de eventos de Jim Odelly otras técnicas de modelado como SDL y redes de Petri.