TRABAJO 1

RESUMEN

ANÁLISIS Y DISEÑO DE SISTEMAS

REALIZADO POR: ARIS MATEO

Investigar la diferencia entre Análisis y Diseño Estructurado y Orientado a Objetos.

Definición.
Diferencia.
Caso Practico. Para ello ustedes deben presentar un ejemplo de cómo podemos utilizar esta metodología en nuestro sitio de trabajo, preferiblemente pensando de cómo podemos utilizar la metodología orientada a objetos en un proyecto web que le sirva a su empresa.
Infografia.

DEFINICION:

El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados." (Senn, 1992, p.11). Se puede dividir en dos: el análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable.

Autor:

Br. Soulberto Lorenzo Torres http://www.monografias.com/trabajos15/analista-sistem/analista-sistem.shtml#ANALISIS

Análisis de Sistemas

El Análisis de Sistemas trata básicamente de determinar los objetivos y límites del sistema objeto de análisis, caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar sus consecuencias. Dependiendo de los objetivos del análisis podemos encontrarnos ante dos problemáticas distintas:

· Análisis de un sistema ya existente para comprender, mejorar, ajustar yo predecir su comportamiento.

· Análisis como paso previo al diseño de un nuevo sistema-producto.

En cualquier caso, podemos agrupar más formalmente las tareas que constituyen el análisis en una serie de etapas que se suceden de forma iterativa hasta validar el proceso completo:

· Conceptualización
Consiste en obtener una visión de muy alto nivel del sistema, identificando sus elementos básicos y las relaciones de éstos entre sí y con el entorno.

· Análisis funcional
Describe las acciones o transformaciones que tienen lugar en el sistema. Dichas acciones o transformaciones se especifican en forma de procesos que reciben una entradas y producen unas salidas.

· Análisis de condiciones (o constricciones)
Debe reflejar todas aquellas limitaciones impuestas al sistema que restringen el margen de las soluciones posibles. Estas se derivan a veces de los propios objetivos del sistema:

· Operativas, como son las restricciones físicas, ambientales, de mantenimiento, de personal, de seguridad, etc.

· De calidad, como fiabilidad, mantenibilidad, seguridad, convivencialidad, generalidad, etc.

Sin embargo, en otras ocasiones las constricciones vienen impuestas por limitaciones en los diferentes recursos utilizables:

· Económicos, reflejados en un presupuesto.

· Temporales, que suponen unos plazos a cumplir.

· Humanos.

· Metodológicos, que conllevan la utilización de técnicas determinadas.

· Materiales, como espacio, herramientas disponibles, etc.

· Construcción de modelos
Una de las formas más habituales y convenientes de analizar un sistema consiste en construir un prototipo (un modelo en definitiva) del mismo.

· Validación del análisis
A fin de comprobar que el análisis efectuado es correcto y evitar en su caso la posible propagación de errores a la fase de diseño, es imprescindible proceder a la validación del mismo. Para ello hay que comprobar los extremos siguientes:

· El análisis debe ser consistente y completo.

· Si el análisis se plantea como un paso previo para realizar un diseño, habrá que comprobar además que los objetivos propuestos son correctos y realizables.

Una ventaja fundamental que presenta la construcción de prototipos desde el punto de vista de la validación radica en que estos modelos, una vez construidos, pueden ser evaluados directamente por los usuarios o expertos en el dominio del sistema para validar sobre ellos el análisis.

http://www.daedalus.es/AreasISAnalisis-E.php

Diseño de Sistemas

El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones). El proceso de diseño de un sistema complejo se suele realizar de forma descendente:

· Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos).

· Diseño e implementación de cada uno de los subsistemas:

· Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis.

· Desarrollo según la especificación.

· Prueba.

· Integración de todos los subsistemas.

· Validación del diseño.

Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las características del mismo. En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva y eficiente. De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento). Así, con respecto al diseño de herramientas software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de informaciones en pantalla, profundidad de menús, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo de errores, estructuras de datos, utilización de lenguaje natural, etc.

http://www.daedalus.es/AreasISDiseno-E.php

2. Análisis estructurado

Permite al analista conocer un sistema o proceso (actividad) en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente".
El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada.

Componentes:
- Símbolos gráficos: sirven para identificar y describir los componentes de un sistema y las relaciones entre estos.
- Diccionarios de datos: Descripciones de todos los datos utilizados en el sistema pueden ser manual o automatizado.
- Descripciones de procesos y procedimientos: emplean técnicas y lenguajes que permiten describir actividades del sistema.
- Reglas: Estándares par describir y docummentar el sistema en forma correcta y completa.

Análisis de flujo de datos:
Estudia el empleo de los datos en cada actividad, documenta los hallazgos con diagramas de flujo de datos.

Herramientas:
- Diagrama de flujo de datos: son la herramienta mas importante y la base en donde se desarrolla otros componentes
- Diccionario de datos: contienen las características lógicas de los lugares donde se almacenan los datos del sistema, incluyendo nombre, alias, descripción, contenido y organización.
- Diagrama de estructuras de datos: este es una descripción de la relación entre entidades (personas, lugares, eventos y objetos ) y el conjunto de información relacionado con la entidad.
- Gráfica de estructura: es la herramienta del diseño que muestra con símbolos la relación entre los módulos de procesamiento y el software de la comp.

Cecylia González http://www.monografias.com/trabajos10/andi/andi.shtml#an

Diseño estructurado

Definición: "Diseño estructurado es el proceso de decidir que componentes, y la interconexión entre los mismos, para solucionar un problema bien especificado".

El diseño es una actividad que comienza cuando el analista de sistemas ha producido un conjunto de requerimientos funcionales lógicos para un sistema, y finaliza cuando el diseñador ha especificado los componentes del sistema y las relaciones entre los mismos.

Frecuentemente analista y diseñador son la misma persona, sin embargo es necesario que se realice un cambio de enfoque mental al pasar de una etapa a la otra. Al abordar la etapa de diseño, la persona debe quitarse el sombrero de analista y colocarse el sombrero de diseñador.

Una vez que se han establecido los requisitos del software (en el análisis), el diseño del software es la primera de tres actividades técnicas: diseño, codificación, y prueba. Cada actividad transforma la información de forma que finalmente se obtiene un software para computadora válido.

Objetivos Del Diseño Estructurado

"El diseño estructurado, tiende a transformar el desarrollo de software de una práctica artesanal a una disciplina e ingeniería".

Eficiencia, Mantenibilidad, Modificabilidad, Flexibilidad, Generalidad, Utilidad

"Diseño" significa planear la forma y método de una solución. Es el proceso que determina las características principales del sistema final, establece los límites en performance y calidad que la mejor implementación puede alcanzar, y puede determinar a que costos se alcanzará.

El diseño se caracteriza usualmente por un gran número de decisiones técnicas individuales. En orden de transformar el desarrollo de software en una disciplina de ingeniería, se debe sistematizar tales decisiones, hacerlas más explícitas y técnicas, y menos implícitas y artesanales.

Un ingeniero no busca simplemente una solución, busca la mejor solución, dentro de las limitaciones reconocidas, y realizando compromisos requeridos en el trabajo del mundo real.

En orden de convertir el diseño de sistemas de computadoras en una disciplina de ingeniería, previo a todo, debemos definir objetivos técnicos claros para los programas de computadora como "sistemas". Es esencial además comprender las restricciones primarias que condicionan las soluciones posibles.

Para realizar decisiones concisas y deliberadas, debemos identificar los puntos de decisión .

Finalmente necesitamos una metodología que nos asista en la toma de decisiones.

Dadas estas cosas: objetivos, restricciones, decisiones reconocidas, y una metodología efectiva, podemos obtener soluciones de ingeniería, y no artesanales.

Diseño estructurado y calidad del software

Un concepto importate a clarificar es el de calidad. Desafortunadamente, muchos diseñadores se conforman con un sistema que "funcione" sin reparar en un buen sistema.

Una corriente de pensamiento estima que un programa es bueno si sus algoritmos son astutos y no obvios a otro programador; esto refleja la "inteligencia" del programador.

Otra escuela de pensamiento asocia calidad con incremento de la velocidad de ejecución y disminución de los requerimientos de memoria central. Estos son aspectos de un concepto más amplio: eficiencia. En general, se busca diseños que hagan un uso inteligente de los recursos. Estos recursos no incluyen solamente procesador y memoria, también incluyen almacenamiento secundario, tiempo de periféricos de entrada salida, tiempo de líneas de teleproceso, tiempo de personal, y más.

Otra medida de calidad es la confiabilidad. Es importante notar que si bien la confiabilidad del software puede ser vista como un problema de depuración de errores en los programas, es también un problema de diseño. La confiabilidad se expresa en como MTBF (mean time between fairules: tiempo medio entre fallas).

http://www.chaco.gov.ar/UTN/disenodesistemas/apuntes/de/Unidad_1.html

Análisis y diseño orientado al objeto

La habilidad más importante en el análisis y diseño orientado al objeto es asignar eficientemente las responsabilidades a los componentes de software.

En segundo lugar aparece la determinación de las clases de objetos.

Durante el análisis y diseño orientado a objetos, se procura identificar, describir y definir los objetos que finalmente serán implementados en un lenguaje de programación orientado a objetos.

Ejemplo: Un juego de dados.

Se tiene un juego de dados en que un jugador lanza dos dados. Si el total obtenido es siete, el jugador gana, de lo contrario pierde.

1. Definición de casos de uso

Los casos de uso son descripciones narrativas en lenguaje natural de los procesos del dominio en un formato estructurado de prosa. Los casos de uso no son propiamente un elemento del análisis y diseño orientado a objetos (pueden ser utilizados en análisis no orientados a objetos), pero constituyen un paso preeliminar muy útil porque describen las especificaciones de un sistema.

Caso de uso: Jugar un juego.

Participantes: Jugador.

Descripción: Este caso de uso comienza cuando el jugador recoge y tira los dados. Si los puntos suman siete, gana y pierde si suman cualquier otro número.

2. Definición de un modelo conceptual

Un modelo conceptual muestra gráficamente, a través de un grupo de diagramas, los conceptos (clases de objetos), los atributos y las asociaciones más importantes del dominio.

3. Definición de los diagramas de colaboración

Los diagramas de colaboración representan el flujo de mensajes entre las instancias y la invocación de métodos.

Notación: Clases de objetos e instancias de las clases (objetos).

4. Definición del diseño de clases

Para definir las clases de objetos se deben contestar dos preguntas: ¿cómo se conectan unos objetos a otros? y ¿cuáles son los métodos de cada clase?. Un diagrama de diseño de clases contesta estas preguntas. El siguiente es un ejemplo del diagrama de diseño de clases del juego de dados.

Luis Guerrero http://www.dcc.uchile.cl/~luguerre/cc51h/clase10.html

DIFERENCIA

Diferencia del análisis estructurado y el orientado a objetos

Estructurado	Orientado a objetos
Datos: Los datos se organizan en variables. Se utilizan tipos de datos propios del compilador y otros definidos por el usuario. Los datos se entregan de manera pasiva a los procedimientos. Es responsabilidad del programador que los datos vayan al sitio correcto y su procesamiento sea el adecuado.	Objetos, clases y subclases Elementos: Atributos. Operaciones o procedimientos de manejo de las estructuras de datos asociadas.
Relación entre módulos: La relación entre módulos: A través de las interfaces de los mismos. A través de variables globales.	Ocultamiento de Información: § Representación. § Operación. § Implementación. Tanto la representación como la implementación quedan ocultos para el resto de objetos
Ligadura estática: Ligadura entre datos y procedimientos void A(int x, int y) {// Cuerpo del procedimiento } int main(void) {A(a,b); }	Ligadura dinámica: La programación orientada a objetos ofrece la posibilidad de retrasar el casamiento de las referencias hasta la ejecución del programa. De esta el objeto al que se dirige un mensaje no se conoce hasta el momento en que se ejecuta dicha parte del código. Por ejemplo, podemos calcular el área de una figura geométrica, sin conocer de antemano si es un triángulo, un cuadrado, etc
Reusabilidad: La reusabilidad se entiende como la capacidad de utilizar un mismo módulo en contextos diferentes.	Herencia: Al definir una nueva clase normalmente nos basamos en una o varias clases ya definidas. De esta manera se crea una jerarquía de clases, donde: Una superclase es una clase definida con anterioridad y que no depende de ninguna otra clase y una subclase es una clase que se define a partir de otra(s).
Busca crear un diseño cerrado y concreto	Busca crear un diseño genérico y abierto
Utiliza técnicas fundamentales para el análisis, a saber: v Diagrama de flujos de datos(DFD) v Modelo de entidad-relación v Diccionario de datos v Especificaciones de procesos	De acuerdo al tipo de metodología a utilizar, entre lo mas común se halla: v Modelo de objeto v Modelo de estado u objeto
Diagrama estructurada de funciones: Esta técnica se utiliza para documentar el proceso de descomposición de funciones y organizar dichas funciones bajo una estructura jerárquica	Diagrama de caso de uso.
Diagrama estructurada de datos: Esta técnica se emplea para documentar los datos requeridos por un sistema y la manera en que éstos se interaccionan a través de modelos de datos conceptuales y lógicos.	Diagrama de clases.
Diagrama de procesos estructurados: Esta técnica se utiliza para documentar las especificaciones técnicas del sistema, donde se muestra la estructura jerárquica de los módulos de un programa y/o sistema y las comunicaciones de datos requeridas para que los módulos ejecuten sus funciones.	v Diagrama de caso de uso v Diagrama de transición de estados v Diagrama de objetos
No existe recursividad de procesos y los módulos generalmente son estáticos. Por ejemplo los DFD es el único que determina la dinámica de los sistemas.	Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica.
Esta orientado hacia funciones y se concentran en los procesos de transformación de los datos.	Se orientan hacia los datos o eventos, para crear a partir de ellos objetos.

http://www.oocities.org/es/eguevara1ve/ADS/t1ads.htm

Caso Practico. Para ello ustedes deben presentar un ejemplo de cómo podemos utilizar esta metodología en nuestro sitio de trabajo, preferiblemente pensando de cómo podemos utilizar la metodología orientada a objetos en un proyecto web que le sirva a su empresa.

Gestión del Presupuesto de la Gerencia de Automatización de PDVSA Maturín:

Representa la programación continua y detallada de las actividades necesarias a realizar durante un período determinado, expresadas en términos monetarios, para lograr las metas corporativas.

Fases:

• Formulación de Presupuesto

• Seguimiento y Control Presupuesto

El proyecto se basa en la crear de un sitio WEB, para la Gestión del Presupuesto de la Gerencia de Automatización de PDVSA Maturín. El sitio debe incluir dos módulos: Formulación de Presupuesto y Seguimiento y Control Presupuesto. En este “sitio” el usuario podrá acceder al presupuesto formulado para el año siguiente y demás hacerle seguimiento y control al presupuesto que se está ejecutando en el año en curso, de una forma amigable e incluso interactuar con el sistema principal de la empresa SAP.

DELIMITACION DEL SISTEMA