jueves, 22 de marzo de 2012

TECNICAS Y METODOS DE MODELADO DE SISTEMAS.

TECNICAS Y METODOS DE MODELADO DE SISTEMAS.

A) DESARROLLO CONVENCIONAL.

Los resultados finales son impredecible.

No hay forma de controlar lo que está sucediendo en el Proyecto.

Los cambios organizativos afectan negativamente al proceso de desarrollo.

EJEMPLO:

CLS 20A=10

INPUT B

IF B=A THEN GOTO 50

ELSE GOTO 70

PRINT “A Y B SON IGUALES”

GOTO 100

IF A>B THEN GOTO 80 ELSE GOTO 90

B= B + 1; GOTO 40

B= B -1; GOTO 40

END

B) DESARROLLO ESTRUCTURADO.

  • Programación estructurado.
  • Diseño estructurado.
  • Análisis estructurado.

Especificaciones funcionales:

  • Gráficas
  • Particionadas
  • Mínimamente redundantes

EJEMPLO:

PROGRAM NUMEROSIGUALES

BEGIN

CLEARSCREEN;

A :=10 ;

INPUT B;

REPEAT

IF B=A THEN PRINT “A Y B SON IGUALES”

ELSE REDUCEDIFERENCIA(A,B);

UNTIL B=A;

END;

PROCEDURE REDUCEDIFENCIA(A,B);

BEGIN

IF A>B THEN B:= B+1

ELSE B:= B -1

END

C) DESARROLLO ORIENTADO A OBJETOS.

La esencia del desarrollo orientado a objetos es la identificación y organización de conceptos del dominio de la aplicación y no tanto de su representación final en un lenguaje de programación. Sus principales características son:

1. Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto.

2. Aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables.

3. Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica.

CLASIFICACION DE LOS METODOS DE MODELADO DE SISTEMAS.

1.- Estructuradas.

a) Orientadas a Procesos.

b) Orientadas a datos.

i) Jerárquicas.

ii) No Jerárquicas.

c) Mixtas.

2.- Orientadas a Objetos.

3.- Para Sistemas de Tiempo Real.

METODOLOGIAS ORIENTADAS A PROCESOS.

Especificación estructurada:

a) Diagramas de Flujo de Datos.

b) Diccionario de Datos.

c) Especificaciones de proceso.

METODOLOGIAS ORIENTADAS A PROCESOS.

Metodología de Yourdon/Constantine.

a) Realizar los DFD del sistema.

b) Realizar el diagrama de estructuras.

c) Evaluar el diseño.

d) Preparar el diseño para la implantación.

METODOLOGIAS ORIENTADAS A DATOS JERARQUICOS.

a) La estructura de control del programa debe ser jerárquica y se debe derivar de la estructura de datos del programa.

b) El proceso de diseño consiste en definir primero las estructuras de los datos de entrada y salida, mezclarlas todas en una estructura jerárquica de programa y después ordenar detalladamente la lógica procedimental para que se ajuste a esta estructura.

c) El diseño lógico debe preceder y estar separado del diseño físico.

METODOLOGIAS ORIENTADAS A DATOS NO JERARQUICOS.

a) Metodología Ingeniería de la Información Planificación: construir una arquitectura de la Información y una estrategia que soporte los objetivos de la organización.

b) Análisis: comprender las áreas del negocio y determinar los requisitos del sistema.

c) Diseño: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnología.

d) Construcción: construir sistemas que cumplan los tres niveles anteriores.

METODOLOGIAS PARA SISTEMAS DE TIEMPO REAL.

a) Manejo de interrupciones.

b) Comunicación y sincronización entre tareas.

c) Gestión de procesos concurrentes.

d) Respuesta oportuna ante eventos externos.

e) Datos continuos o discretos.

f) Se está produciendo una evolución de las metodologías orientadas a objetos para desarrollos de sistemas de tiempo real.

Metodología de DeMarco:

1. Estudio del entorno físico actual: modelo del sistema actual con sus procedimientos. A través de un conjunto de DFD

2. Derivación del correspondiente modelo lógico actual: modelo derivado del anterior sin connotación física.

3. Derivación del nuevo modelo lógico: tomar en cuenta las nuevas necesidades. Formado por un DFD, diccionario de datos y especificaciones de proceso del sistema.

Metodología de Gane-Sarson.

Es el resultado de varios años de práctica en consultoría de análisis y diseño estructurado.

Creado por la empresa MCAUTO/IST bajo el nombre de STRADIS SDM.

Es parecido al de DEMARCO, la principal diferencia es que hay una etapa en la que se define los contenidos de los almacenes de datos que aparecen en DFD en 3FN.

METODOLOGIA MERISE.

Merise es un método integrado de análisis, concepción y gestión de proyectos, desarrollado en Francia. El mismo provee un marco metodológico y un lenguaje común riguroso para los desarrollos informáticos.

Fases de la Metodología:

a) Estudio Preliminar.

b) Estudio Detallado.

c) Implementación.

d) Realización y puesta en marcha.

METODOLOGIA SSADM. (Structured System Analysis Design Method ).

A iniciativa del Gobierno Británico a principios de los 80 se plantea estandarizar proyectos de tecnología de información

Surge el SSADM: structured Systems Analysis and desing method.

Énfasis en los usuarios: sus requisitos y participación.

• Definición del proceso de producción: qué hacer, cuándo y cómo.

• Tres puntos de vista: datos, eventos, procesos.

• Máxima flexibilidad en herramientas y técnicas de implementación.

SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y diseño, pero no cubre aspectos como la planificación estratégica ni entra en la construcción del código.

METODOLOGIA METRICA.

METRICA es una metodología que rije el desarrollo de aplicaciones informáticas para la Administración Pública de España. Todos los proyectos que se presenten a concurso para la creación de software para las Adminstraciones públicas tienen que realizarse o elaborarse conforme a esta metodología, que ha sido diseñada por el Consejo Superior de Informática del Ministerio de Administraciones Públicas, tomando en cuenta los estándares más actuales en cuanto a ingeniería del software. Sus fases son:

a) FASE 0: Plan de Sistemas de Información.

b) FASE 1: Análisis de Sistemas.

c) FASE 2: Diseño de Sistemas.

d) FASE 3: Construcción de Sistemas.

e) FASE 4: Implantación de Sistemas.

METODOLOGÍA DE YOURDON-CONSTANTINE.

Todo inicia identificado el problema, posteriormente se procede a modelar el aspecto dinámico o el aspecto estático del sistema. El aspecto dinámico está definido por el aspecto ambiental y el aspecto de comportamiento. El aspecto estático está definido por el aspecto de información.

Aspecto ambiental.- Define las entradas y salidas del sistema con su entorno. Para representar este aspecto se utiliza un diagrama de contexto (DC) donde el sistema se representa por una burbuja y los agentes que proporcionan o reciben información por rectángulos. El flujo de información entre el sistema y el agente se dibuja con una línea curva.

Aspecto de comportamiento.- Define el comportamiento interno del sistema para procesar las entradas en salidas. Para representar este aspecto se ocupa el diagrama de flujo de datos (DFD)y el diagrama de transición de estados (DTE). En el DFD Se ocupan los mismos símbolos que en el DC pero se hace uso de los almacenes que se representar por dos líneas paralelas, estos almacenes son los encargados de tener los datos que requieren las burbujas (procesos) que requieren para trabajar.

Aspecto de Información.- Define la persistencia de los datos que se serán utilizados por los proceso. Para representar este aspecto se ocupa el diagrama de entidad-relación (DER).

EL PROCESO UNIFICADO.

Es importante primero analizar el proceso para poder ver como funciona un desarrollo OO.

Se mostrara una primera visión general del Proceso para tener una idea de cómo llevar a cabo un proyecto

Este es un procesó de desarrollo iterativo y gradual, el softw. No se elabora de un solo golpe, sino se libera por partes.

La Etapa de construcción: consta de muchas iteraciones en cada una se construye softw.., de calidad, probada e integrado que cumple un subconjunto de requisitos.

Cada etapa contiene todas la etapas del ciclo de vida: Análisis, Diseño, Implementacion, experimentación.

MODELADO ORIENTADO A CASOS DE USO

Modelado de Casos de Uso.

La idea de especificar los requisitos de un sistema es simple: indicar lo que el sistema debe hacer. Sin embargo, dado que los sistemas modernos son altamente interactivos; tanto por su relación con múltiples operadores como por su integración con otros sistemas – los llamados actores; hoy por hoy es necesario dar un giro en esa ideal inicial. Hoy es necesario especificar lo que el sistema hace para cada actor.

La organización de un cuerpo de requisitos modernos es pues, una presentación de las responsabilidades del sistema desde el punto de vista de cada uno de los actores que requieren los servicios del sistema. A esta forma de documentar los requisitos le llamamos Caso de Uso.

En su forma más simple, un caso de uso es un párrafo de texto que describe un escenario de interacción entre el actor -o actores- y el sistema. Dicho párrafo contiene la especificación de la funcionalidad requerida y puede ser considerada la unidad fundamental de un modelo de requisitos.

En adición a esta descripción de la interacción, es usual encontrar detalles adicionales. La principal de estas adiciones es el llamado flujo de eventos, que pone en limpio la interacción entre el actor y el sistema por medio de su presentación en pasos, indicando tanto la información que viaja de un lado al otro, y el cálculo o proceso que se requiere que el sistema realice con la información.

Usual también, es encontrar las desviaciones al flujo de eventos típico presentadas como flujos alternativos. Manejando de esta forma las condiciones de error que se requieren sean cubiertas por el sistema.

Sin embargo, con mucho la más popular de las extensiones o adiciones que se hacen a los casos de uso es la de presentarlos en forma gráfica con ayuda del lenguaje de modelado UML. Sin embargo, es importante dejar en claro que la representación gráfica no es donde el requisito es capturado. Este papel es cubierto por las descripciones textuales del escenario y en gran parte también, por los flujos de eventos principales y alternativos.

Un ejemplo rápido de diagrama de caso de uso, quizás parte de un modelo mucho más grande y complejo es el siguiente:














PROTOTIPO.

Los prototipos son una visión preliminar del sistema futuro que se implantara. La elaboración de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de información especifica a cerca de los requerimientos de información de los usuarios.

Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinación de requerimientos.

En esta forma el analista esta buscando las reacciones iniciales de los usuarios y de la administración hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza del sistema para el que construye un prototipo, posibles innovaciones y planes de revisión que detallan que parte del sistema necesita realizarse primero.

Tipos de Información que busca el Analista durante la Elaboración de Prototipos.

  • Reacciones del usuario.
  • Innovaciones.
  • Sugerencias del usuario.
  • Plan de revisión.

Reacciones: Son recopiladas por medio de observaciones, entrevista y formas de retroalimentación, diseñadas para recoger la opinión de cada persona acerca del prototipo cuando interactua con él.

Por medio de estas reacciones el analista descubre muchas perspectivas en el prototipo incluyendo el agrado que tenga el usuario al sistema.

Sugerencias: El analista también esta interesado en las sugerencia de los usuarios y la administración acerca como refinar o cambiar el prototipo presentado. Las sugerencias son recolectadas de aquellos que experimenta con el prototipo, mediante un periodo de tiempo especifico.

El tiempo que pasan los usuarios con el prototipo depende por lo general de su dedicación e interés en el proyecto de sistemas. Las sugerencias son el producto de la interacción de los usuarios con el prototipo. Estas sugerencias deben apuntar ala analista hacia formas de refinación, cambio o limpieza del prototipo para que se ajuste mejor a las necesidades de los usuarios.

Innovaciones: Son parte de las informaciones buscada por el equipo de análisis de sistema. Son capacidades nuevas del sistema que no habían sido pensadas antes de la interacción con el prototipo. Van más allá de las características prototipicas actuales añadiendo algo nuevo e innovador.

Plan de Revisión: Ayuda a identificar prioridades para lo que se debe construir un prototipo a continuación. En situaciones donde están involucradas muchas ramas de la organización, los planes de revisión ayuda a determinar para cuáles hay que construir un prototipo a continuación.

La información recolectada en la fase de hechedura del prototipo permite al analista asignar prioridades y redirigir los planes sin realizar gastos con un mínimo de ruptura. La elaboración de prototipo y la planeación van mano a mano.

TIPOS DE PROTOTIPO.

Prototipo Parchado: Es un sistema que tiene todas las características propuesta pero es realmente un modelo básico que eventualmente será mejorado. Este tipo de prototipo trabaja pero no es eficiente ni elegante.

Prototipo no Operacional: La segunda concepción de un prototipo es la de un modelo o escala no funcional para objeto de probar determinados aspectos del diseño. Este puede ser hecha cuando la codificación requeridas por las aplicaciones es muy amplia para hacerce el prototipo y, sin embargo se puede obtener una idea útil del sistema por medio de la elaboración de prototipos de la entrada y salida solamente.

Puede buscar las opiniones de los usuarios sobre la interfaces (entrada y salida). Debido al costo y tiempo excesivo podría no ser realizado, sin embargo se puede tomar algunas de las utilidades del sistema con base en la entrada y salida ya en el prototipo.

Prototipo Primero de una Serie: Una tercera concepción de la elaboración de prototipos involucrados la creación de un primer modelo o escala completa de un sistema, llamado también piloto.

Este tipo de prototipo es útil cuando se tiene planeadas muchas instalaciones del mismo sistema. El modelo funcional o escala completa permite la interacción realista con el nuevo sistema, pero minimiza el costo de superar cualquier problema que presente.

Prototipo de Características Seleccionadas: Un prototipo de características seleccionada permite que el sistema sea puesto en su lugar mientras otras características pueden ser añadidas en fecha posterior.

Se refiere a la construcción de un modelo operacional que incluye algunas, pero no todas, de las características que tendrá el sistema final.

Cuando se construye este tipo de prototipo, el sistema se va construyendo por módulos, de modo que si las características reciben una evaluación satisfactoria, éstas puedan incorporarse en el sistema final, mucho más grande sin tener que hacer un trabajo inmenso en interfaces. Los prototipos hechos en esta forma son parte del sistema actual, no son simplemente una maqueta.

TECNICAS DE ANÁLISIS.

Diagrama de flujo - Flow Chart: Los diagramas de flujo, que datan de los años 60 (Schriber, 1969), se definen como una representación gráfica de una secuencia lógica de procesos de trabajo (Lankin et al., 1996). Mediante la utilización de diferente simbología, representa operaciones, datos, direcciones de flujo y recursos; para la definición, análisis o solución de un problema. Este formalismo es muy flexible, el estándar ofrece la nomenclatura, pero será quien diseñe el proceso, quien estructure los diferentes bloques del diagrama según el conocimiento que posea de éste. Se caracteriza por su gran facilidad de uso y aporta gran cantidad de información ya que muestra la totalidad del sistema, aunque presenta la problemática de su extensión, lo que dificulta la visión global de todo el sistema así como que los límites del proceso no suelen estar muy claros (Aguilar-Savén, 2004).

Diagramas de flujo de datos- Data Flow Diagram (DFD): Los DFD, son representaciones de información a través de entidades externas, pasos internos de procesado y elementos de almacenamiento de datos de un proceso de negocio (Kettinger et al., 1995). Estos diagramas permiten ver cómo fluyen los datos a través de la organización, los procesos así como las transformaciones que sufren dichos datos y los diferentes tipos de salidas, aunque no modela representaciones de flujos de materiales, recursos humanos, y otros elementos relacionados con los procesos de negocio (Yourdon, 1989).

Diagrama entidad-relación - Entity-Relationship (ER) Diagram: El diagrama ER es un modelo de red, que describe con un alto nivel de abstracción, la distribución de datos almacenados en un sistema. Los diagramas ER se centran en los datos y en sus interrelaciones y por ello, no representan la estructura para el modelado de otros elementos del proceso. Dichos diagramas son representaciones completamente estáticas y no proporcionan la información en el tiempo para poder analizarla y medirla (Giaglis, 2001).

Diagrama estado-transición - State Transition (ST) Diagram: Los diagramas ST, se originan para la descripción de la perspectiva dinámica de sistemas dependientes en el tiempo y consiste en círculos que representan los estados, definidos como el modo perceptible de comportamiento de un sistema, y flechas, que representan las transiciones entre estados. Son muy útiles ya que proporcionan información explícita acerca de la secuencia de tiempo relacionado con los diferentes eventos dentro del sistema. Las limitaciones las presenta en la descripción de la colaboración entre los objetos que causan dichas transiciones.

IDEF - Integrated Definition for Function Modelling: IDEF es una familia de técnicas de modelado, que ofrecen una perspectiva integrada para representar y modelar procesos y estructuras de datos. Sus inicios se remontan a la necesidad de las Fuerzas Armadas Estadounidenses por mejorar sus operaciones de producción, iniciándose así el programa ICAM (Integrated Computer-Aided Manufacturing). La familia IDEF, consiste en un gran número de técnicas, entre las cuales se destaca IDEF0 e IDEF3, que son aquellas relacionadas con los procesos de negocio, aunque existen otras versiones como IDEF1, IDEF1X, IDEF2, IDEF4 e IDEF5.

La técnica IDEF0, está diseñada para modelar las decisiones, acciones y actividades de una organización u otro sistema, y representa la perspectiva funcional de modelado, es decir, el qué (Mayer et al., 1995). Es considerada una técnica sencilla pero poderosa, ampliamente usada en la industria durante la etapa de análisis en la reingeniería de procesos. Permite identificar apropiadamente los procesos y sus interfases así como elaborar los documentos que permitan su control en cualquiera de sus etapas de desarrollo. IDEF0 utiliza solo un tipo de anotación en sus representaciones gráficas conocido como ICOM (Input-Control-Output-Mechanism). La representación estática de sus diagramas no permite visualizar las perspectivas de modelado de comportamiento o informacional. Para vencer dichas limitaciones, se desarrolló IDEF3 (Process Description Capture), que describe a los procesos como secuencias ordenadas de hechos o actividades, representando el cómo, y mostrando la visión dinámica o de comportamiento.

Diagramas de actividad de roles - Role Activity Diagram (RAD): Los RAD son utilizados para esquematizar las actividades bajo la responsabilidad de cada rol así como la interacción entre ellos y con sucesos externos, entendiendo por rol, el comportamiento deseado de los individuos dentro de la organización (Huckvale y Ould, 1995). Los diagramas RAD centran su atención en el concepto de rol, por ello su idoneidad en aquellos contextos en los que la perspectiva organizacional, es un factor clave que debe ser modelado.

Diagrama de interacción de roles - Role Interaction Diagram (RID): Los RID, son gráficos que representan los roles de los procesos de negocio. Las actividades están conectadas a los roles en una matriz. Aunque dichos diagramas son más complejos que los de flujo, son muy intuitivos y aportan facilidad en su lectura, a pesar que tienden al desorden debido a la gran cantidad de flechas relacionando diferentes puntos. Los RID, no son tan flexibles como los de flujo, aunque lo son más que muchas otras técnicas. Su mejor uso se centra en el diseño del flujo de trabajo y suelen ser utilizados para procesos que implican la coordinación de actividades interrelacionadas (Aguilar-Savén, 2004).

Redes Petri - Petri Nets (PN): Las PN fueron creadas por el alemán Carl Adam Petri en 1962. En su tesis doctoral "kommunikation mit automaten" (Comunicación con autómatas), establece los fundamentos para el desarrollo teórico de los conceptos básicos de las PN que representan una alternativa para modelar el comportamiento y la estructura de un sistema (Adam, 1962). La manipulación de los datos, tiene que ser representada directamente en la estructura de la red y esto le confiere un tamaño excesivamente grande. Además, no tiene en cuenta la estructura jerárquica, y no permite construir un modelo global mediante la separación de submodelos con interrelaciones bien definidas.

Técnica Orientada a Objetos - Object-Oriented (OO) Technique: La técnica OO, se utiliza para modelar y programar procesos caracterizados como objetos, que son desarrollados y transformados por actividades. Utiliza los objetos como bloque esencial de construcción y combina la estructura de datos (atributos) y funciones (operaciones) en una sola entidad. Existen diversidad de técnicas basadas en la programación orientada a objetos, pero de todas ellas, la más importante es UML (Unified Modelling Language), lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML ofrece una forma de modelar entes conceptuales como son los procesos de negocio y funciones de sistema, además de entes concretos como son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables. UML consiste en nueve diagramas diferentes, cada uno de los cuales muestra el aspecto estático o dinámico del sistema: diagrama de clases, de objetos, de estados, de actividad, de secuencia, de colaboración, de casos de uso, de componentes y de despliegue.

Metodologías Genéricas

Normalmente cuando se realiza una búsqueda sobre las técnicas de modelado, se obtienen resultados que representan a más de una técnica. Dichos resultados son metodologías generales con facultades para el modelado de procesos. Desafortunadamente, existe una gran confusión de conceptos, ya que las metodologías son utilizadas tanto para indicar la propia metodología como las técnicas asociadas a la misma.

Análisis y diseño estructurado - Structured Systems Analysis and Design Method (SSADM): Metodología que engloba un sistema de procedimientos, técnicas y documentación de estándares para el análisis y diseño de las diferentes fases del desarrollo de sistemas. Se caracteriza por una estructura en cascada, donde cada fase precedente tiene que estar terminada para poder iniciar la siguiente. Su estructura consiste en cinco módulos principales, los cuales se dividen en fases, pasos y tareas: estudio de fiabilidad, análisis de requerimientos, especificación de las necesidades, especificación del sistema lógico y diseño físico. SSADM utiliza tres técnicas clave para el estudio de sistemas, denominadas modelado lógico de datos, diagramas de flujos de datos y modelado entidad/evento (Hutchings, 1996).

Metodología de los sistemas blandos - Soft Systems Methodology (SSM): La metodología trata con situaciones problemáticas en las cuales existe un alto componente social, político y humano. El enfoque sistémico atiende al estudio de las relaciones que conforman numerosos factores de un sistema, tomando muy en cuenta la intensidad con que dichos elementos se comunican, al integrar una estructura organizacional determinada. Dicha metodología plantea una visión inter, multi y transdisciplinaria que ayuda a analizar la empresa de manera integral. Se divide en las siguientes etapas; reconocer y expresar la situación problemática, producir "definiciones básicas" de sistemas relevantes, desarrollar modelos conceptuales de los sistemas relevantes, comparar modelos conceptuales con la situación percibida, identificar cambios deseables y factibles, y tomar acción para mejorar la situación. Presenta problemas en el análisis estructurado o para informar sobre una descripción (Checkland y Scholes, 1999).

Metodología GRAI - Graph with Results and Activities Interrelated: La metodología GRAI fue desarrollada como análisis del sistema decisional de la empresa. El modelo GRAI consiste en un macro-modelo de referencia conceptual para los sistemas de fabricación y un micro-modelo conceptual para los centros de decisión, que son representados mediante la Rejilla y la Red GRAI respectivamente. La Rejilla GRAI permite modelar el sistema de decisión, mientras que las Redes permiten modelar las actividades de decisión de cada centro de decisión identificado en la Rejilla (Doumeingts, 1984). Utiliza cuatro vistas: funcional, física, decisional e informacional, para proveer al analista de una descripción genérica de los procesos de fabricación. Estas vistas permiten generar modelos parciales de la empresa.