.- ¿Qué son los requerimientos de sistemas? R= son sistemas de información por computadora normalmente están integrados por muchos componentes.

2.- ¿Qué esta identificación de requerimientos? R= son el proceso y las técnicas que un analista de sistemas usa para identificar, analizar, y entender los requerimientos de sistema

3.- ¿Qué significa la recolección de datos? R= se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información.

4.- ¿Cómo se especifica los requerimientos de sistema? R= se especifican lo que el sistema de información debe hacer, o que propiedad o cualidad debe tener el sistema.

5.- ¿Cuáles son los instrumentos y herramientas de información? R= son la entrevista, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos.

6.- ¿Qué es la entrevista? R= son los que utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. También son los que utilizan para recabar información en forma verbal, a través de preguntas que propone el analista.

7.- ¿Qué es el cuestionario? R= son los que proporcionan una alternativa muy útil para la entrevista; si embargo, existen ciertas características que pueden ser apropiada en algunas situaciones e inapropiadas en otra.

8.- ¿Qué es el diagrama de flujo? R= son los que pueden aplicar a cualquier aspecto del proceso desde el flujo de materiales hasta los pasos para hacer la venta u ofrecer un producto.

9.- ¿Qué es el diccionario de datos? R= son el segundo componente del análisis del flujo de datos. En sí mismos los diagramas de flujo de datos no describen por completo el objeto de la investigación.

10.- ¿Cuales son los beneficios que puede aprender un analista, por usar las herramientas de exploración de sistema? R=

* Aprenda de documentos, formas, informes y archivos existentes.

* Si es apropiado, observe el sistema en actividad.

* Dados todos los hechos ya recabados, diseñe y distribuya cuestionarios para aclarar las cosas que no son completamente comprendidas.

* Conduzca entrevistas como la mayor parte de los hechos pertinentes ya ha sido recolectada por los métodos de contacto de usuario bajo.

* Haga un seguimiento. Use técnicas de exploración apropiadas para verificar hechos.

11.- ¿Cuáles son las actividades que consta en el proceso de requerimientos? R=

* El análisis e identificación del problema

* La identificación de requerimientos

* La documentación y el análisis de los requerimientos

* La administración de los requerimiento

12.- ¿Qué es el diagrama de Ishikawa? R= Se trata de un diagrama que por su estructura ha venido a llamarse también: diagrama de espina de pescado, que consiste en una representación gráfica sencilla en la que puede verse de manera relacional una especie de espina central, que es una línea en el plano horizontal, representando el problema a analizar, que se escribe a su derecha.

13.- ¿Qué es la planeación conjunta de requerimientos (JRP)? R= Es la que conduce reuniones de grupo altamente estructuradas con el objeto de identificar y analizar problemas y definir requerimientos del sistema.

14.- ¿Para que se usa el JRP? R= es útil y se usa en las reuniones de grupo altamente estructuradas con el propósito de analizar problemas.

15.- ¿Cuale son los beneficios del JRP por ser un hecho popular? R=

-El JRP involucra activamente a los usuarios en el proyecto de desarrollo.

-El JRP vislumbran los beneficios de la elaboración de prototipos.

-El JRP reduce el tiempo requerido para desarrollar sistemas.

16.- ¿De que esta compuesto el diagrama de Ishikawa? R= Sujeto, Causa (Subcausa, causa principal) y Efecto (problema).

17.- ¿Qué es la elaboración del prototipo de identificación? R= Es el proceso mediante el cual se conducen reuniones de grupo altamente estructuradas con el propósito de analizar problemas.

18.- ¿Qué es la proxemia? R= Relación entre las personas y el espacio a su alrededor.

19.- ¿Qué es la lluvia de ideas? R= Técnica para generar ideas al alentar a los participantes para que ofrezcan tanta ideas como sea posible en un corto tiempo.

ANÁLISIS Y DISEÑO DE SISTEMAS I

INTRODUCCIÓN El diseño orientado a objetos (DOO) crea una representación del campo del problema del mundo real y la hace corresponder con el ámbito de la solución que es el Software, además produce un diseño que intercambia objeto de datos y operaciones de procesamiento en una forma que modulariza la información y el procesamiento en lugar de dejar aparte el procesamiento. El DOO se caracteriza por mantener a la hora del diseño: • • • La abstracción La modularidad El ocultamiento de la información

Todos los métodos de diseño tratan de mantener estas tres características presentes pero el DOO consigue las tres características sin complejidad. Algunos especialista en la materia dicen acerca de la Metodología: "Ya no es necesario esforzarse en resolver un determinado problema mediante la aplicación de la estructura de datos usando las normas de los lenguajes de programación, deseando lograr mantener los principios de diseño, pues hacerlo mediante ese método nos dificultaría el trabajo, ya que en DOO muy fácil lograrlo sin tanta complejidad manteniendo las normas necesaria para el diseño". El análisis, el diseño y la programación orientado a los objetos comprenden la INGENIERÍA DEL SOFTWARE para la construcción de un sistema orientado a los objetos. Orígenes del diseño orientado a los objetos En los primeros días de la informática, los lenguajes ensambladores permitían a los programadores utilizar instrucciones Máquina, para manipular elementos de datos, pero el nivel de abstracción era muy bajo. Al parecer algunos lenguajes de programación de alto nivel (Fortran, cobol) lo

lograron con la presencia de estructura de datos y de control logrando detallarlo mediante procedimiento, fue entonces cuando evolucionaron los conceptos de refinamiento de funciones y modularidad. Después en los años setenta aparecen los conceptos de abstracción y el ocultamiento de la información aunque los diseñaron se centraban todavía en los procesos y sus representaciones, pero al mismo tiempo los lenguajes se enriquecieron con sus estructuras y tipos de datos (PASCAL). Entonces los lenguajes convencionales surgidos de la tradición fueron evolucionando (Fortran, Algol), los investigadores trabajaban en una nueva clase de lenguaje de simulación y de creación de prototipos (SIMULA, SMALLTALK) el énfasis estaba en la abstracción de datos y se representaba por un conjunto de objeto de datos y un conjunto correspondiente de operaciones los cuales se usaban distintamente a los lenguajes convencionales. Los primeros trabajos de la abstracción en los últimos 20 años sentaron las bases al establecer la importancia de la abstracción, del ocultamiento de la información y de la modularidad para la calidad del software. Seguidamente en los años ochenta la rápida evolución del Fortran, Ada, seguida de un crecimiento explosivo de los dialectos de C como C++, produjeron un interés inusitado en el DOO

ANÁLISIS Y DISEÑO DE SISTEMAS I

I. INVESTIGACIÓN PRELIMINAR • • • Identificar el Problema Entrevista para conocer la empresa Nivel Directivo

En esta fase el objetivo fundamental es tratar de obtener la información del nivel directivo para conocer en forma breve los posibles problemas o necesidades que tiene la empresa. La persona o personas que cumplirán con la misión de elaborar y mantener la entrevista deberán estar en la capacidad de obtener la mayor cantidad de información por parte de los entrevistados. Se hace necesario entonces elaborar los instrumentos que posibiliten realizar la entrevista. Luego de este primer acercamiento se elaborará un informe con las posibles causas o requerimientos de la empresa.

II. ESTUDIO DE FACTIBILIDAD Determinación de la Factibilidad y Manejo de las Actividades del Análisis y el Diseño ¿Cómo se debe determinar la factibilidad de un proceso? En el campo informático la definición de factibilidad va mucho más allá del uso común del término; dentro de los proyectos informáticos, la factibilidad es valorada en tres formas principales: Operacionales, Técnica y Económicamente. Un proyecto debe ser factible en las tres formas para merecer un desarrollo posterior. El estudio de factibilidad no es un estudio del sistema completo, únicamente es una fase en la cual se recopilan los datos burdos para la administración para que a su vez este nivel operativo luego pueda tomar la decisión de continuar o no con el proyecto. Datos para el Estudio de Factibilidad Pueden ser recolectados por medio de entrevistas, cuestionarios o la técnica que se crea más conveniente; estas entrevistas serán aplicadas directamente a las personas que se encuentran siendo parte del proceso que se cree es el problema; normalmente la persona que recopila esta información deberá estar encaminada a desarrollar

este proceso a los administradores o jefes departamentales del nivel operativo. Las fases que deben ser tomadas en cuenta para el estudio de factibilidad son: 1. 2. 3. 4. 5. Fundamento del Proyecto Definición de Objetivos Determinación de recursos Evaluación de la Factibilidad Estimación del Tiempo Requerido lquier problema existente que se analice con el objetivo de encontrar soluciones, deberá incluir en el análisis de alternativas posibles de solución, un estudio de la relación COSTO / BENEFICIO. Esta relación permitirá no solamente fijar prioridades entre diferentes problemas a resolver sino también definir cual alternativa de solución de un problema específico se debe implementar.

En el proceso descrito en el diagrama que se muestra (Proceso para el análisis de problemas) podemos observar que para estimar la importancia del problema uno de los aspectos más importantes es evaluar el valor de la solución (V), que consiste en estimar la ganancia que se obtendrá si el problema se elimina o se mejora. En oras palabras, cuanto del costo del problema puede salvarse si este se resuelve o se reduce. El valor V se puede estimar calculando los beneficios que tendrían los potenciales usuarios de la empresa si se implementa el sistema para el ejemplo del sistema administrativo financiero. En el mismo procedimiento cuando se tienen alternativas de solución para cada una debe estimarse el costo de la solución (C). Es simplemente la cantidad requerida para resolver o reducir el problema (En el ejemplo sería establecer el costo del sistema Administrativo Financiero). La rentabilidad entonces es igual a beneficio/ costo, lo cual nos podrá dar resultado para verificar si el proyecto es o no viable.

ANÁLISIS DE COSTO (C) De acuerdo con el concepto mencionado anteriormente el costo corresponde a la estimación en valores que se da a la solución propuesta en el caso de un proyecto, es el costo de implementación del proyecto (construcción), más el costo de operación del sistema instalado. Los costos típicamente asociados con un proyecto incluyen, por ejemplo , costo del terreno, edificios, mano de obra, equipos, materiales, intereses de los préstamos obtenidos y depreciación cargado a los equipos adquiridos por el proyecto. Tomando en cuenta los principios de planificación e implementación de proyectos en la parte de preparación del documento del proyecto se recomienda realizar la estimación de los siguientes presupuestos: a) El presupuesto que abarca las contribuciones de la entidad, en dólares ( no en moneda local), este presupuesto hace referencia a como la entidad o empresa va a financiar el proyecto con sus propios recursos. b) El presupuesto que abarca los préstamos realizados a entidades financieras.

ANÁLISIS DE BENEFICIO (Valor de la Solución) Como beneficio puede considerarse cualquier bien o servicio que es producido por el proyecto. O bien, el beneficio puede representar los costos recuperados (ganancia adicional) que el proyecto le produce a la empresa. Tangibles Beneficio Intangibles

Rentabilidad: La comparación entre el beneficio o valor de la solución con el costo de la solución es lo que se conoce como rentabilidad (R = V / C). Es evidente que tanto el factor de beneficio como el de costo deben calcularse hasta el final de la vida útil de las instalaciones o construcciones realizadas, y si

esto es para proyectos grandes y de larga duración debe tomarse en cuenta factores de corrección utilizados, en el mundo de la economía tales como la inflación, depreciación, valor presente del dinero, etc.

PRIORIDADES O ESCOGER LA MEJOR SOLUCIÓN Debemos tomar en cuenta para este análisis dos criterios fundamentales: Beneficio Neto: Se da de la relación Beneficio menos Costo, esto por ejemplo nos permite saber que si se gasta una cierta cantidad (C) en instalar o construir la solución propuesta, esa instalación le dará a la empresa una cantidad que antes no recibía (V), la cual significa que la compañía tiene un beneficio neto que es lo que recibía menos lo que gastó en los medios que le permitieron recibir. Evidentemente este rubro deberá ser una cantidad positiva. BN = V – C BN = 20000 – 7000 BN = 13000 Rentabilidad: Este criterio hace referencia a la relación entre lo que se “gasta o Invierte” en las instalaciones o implementación del proyecto y lo que la empresa recibe gracias a esa implementación. Evidentemente la rentabilidad debe ser mayor que 1. Con un valor igual a 1 significa que mi problema me cuesta X cantidad de dinero y para resolverlo tengo que invertir X. Mi decisión entonces será si vivo con el problema o lo resuelvo. Por eso entre las alternativas de solución o un mismo problema el valor de rentabilidad más alta es el que determina que debe dársele a la solución desde el punto de vista económico. III. DISEÑO DE LA BASE DE DATOS Una vez que se ha establecido la aceptación por parte de la empresa a las que hemos ofertado el sistema, se procede a generar el modelo (lógico) para obtener luego el modelo físico de la base de datos, recuerde que deberemos NORMALIZAR las tablas que forman parte de la Base de Datos. Para tal propósito podemos hacer uso de herramientas de diseño de bases de datos tales como el Erwin, Power De signer, etc.

IV. ANÁLISIS Y DISEÑO DEL SISTEMA PROTOTIPO Para la elaboración del Sistema prototipo, se debe partir de la elaboración del Diagrama de Flujo de Datos, con el objetivo de conocer exactamente “el como se da el proceso”, y como producto final se obtendrá la interfaz que se presentará al usuario final del sistema. El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el Software. El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación

Diagrama de Flujo de Datos (DFD) Es una representación pictórica de los pasos de un proceso. Útil para determinar como funciona realmente el proceso para producir un resultado. El resultado puede ser un producto, un servicio, información o una combinación de las tres; al examinar como los diferentes pasos en un proceso se relacionan, se puede describir con frecuencia las fuentes de los problemas potenciales. Los D. F. D. Se pueden aplicar a cualquier aspecto del proceso desde el flujo de materiales hasta los pasos para hacer la venta u ofrecer

un producto. Con frecuencia este nivel de detalle no es necesario, pero cuando se necesita, el equipo completo de trabajo debe agregar una mayor cantidad de niveles para que sea satisfecho el proyecto. ¿CUÁNDO SE UTILIZA EL DFD? Se utiliza cuando un equipo de desarrollo necesita observar como funciona “realmente” un proceso completo. Este esfuerzo con frecuencia revela problemas potenciales tales como cuellos de botella en el sistema, pasos innecesarios y círculos de duplicación de trabajo. Algunas aplicaciones comunes son: 1. Definición de Proyectos a. Identificar oportunidades de cambios en el proceso. b. Desarrollar estimados de costos de mala calidad c. Identificar organizaciones que deben estar representadas en el equipo d. Desarrollar una Base común de conocimientos para los nuevos miembros del equipo e. Involucrar a los empleados en los esfuerzos de resolución de problemas para reducir las resistencias futuras al cambio. 2. Identificación de las Causas Principales. a. Desarrollar planes para reunir datos b. Generar teoría sobre las causas principales c. Discutir las formas de estratificar los datos para el análisis, para identificar las causas principales. d. Examinar el tiempo requerido para las diferentes vías del proceso 3. Diseño de Soluciones a. Describir los cambios potenciales en el proceso y sus efectos potenciales b. Identificar las estructuras organizacionales que serán efectuadas por los cambios propuestos 4. Aplicaciones de Soluciones a. Explicar el proceso actual y la solución propuesta a los jefes departamentales. b. Superar la resistencia al cambio demostrando como los cambios propuestos simplificarán el proceso. 5. Control a. Revisar y establecer controles y monitorea al proceso. b. Auditar el proceso periódicamente para asegurar que se están siguiendo los nuevos procedimientos. c. Entrenar a los empleados para que conozcan los nuevos procedimientos dentro del proceso y de esta manera faciliten que el proceso se cumpla. La metodología para preparar un diagrama de flujo de datos es: 1. Propósito: Analizar como se pretende utilizar el DFD que se está elaborando para llegar a una solución propuesta. Exhibir ésta hoja en la pared y consultarla en cualquier momento para verificar que el DFD es2. Determinar el nivel de detalle requerido: Se tomará en cuenta que para la explotación del DFD general a uno más específico definimos los niveles jerárquicos que según nuestros análisis hemos detectado. 3. Definir los límites del proceso: derecho del diagrama. Enumerar los resultados y los actores en el extremo

4. Utilizar símbolos apropiados para representar las respuestas (resultados) a los ingresos de información. 5. Hacer Preguntas para cada entrada tales como: a. ¿Quién recibe la entrada? b. ¿Qué es lo primero que se hace con esa entrada? 6. Documentar cada paso en la secuencia determinada por su DFD haciendo preguntas tales como ¿quién produce este proceso?, ¿Quién recibe este resultado?, ¿Qué para luego con el resultado? 7. Completar la construcción del DFD tratando de que para casa entrada por lo menos exista una salida. 8. Revisión: Para establecer la revisión debemos hacer preguntas tales como: a. ¿Todos los flujos de información encajan en las entradas y salidas del proceso? b. ¿El diagrama capta en forma exacta lo que realmente ocurre en el proceso? 9. Determinar oportunidades (soluciones frente al proceso identificado como problema)

Ejemplo de DFD para una Compra de un vehículo:

Solicita información de modelos de autos

WEB ? no 1.2 FISICO

si

1.1 WEB

Información de modelos de autosión modelos de autos

Información de modelos de autos

1.1.2 Consulta Financiamiento Web

Solicita información de formas de pago

1.1.3 Conta do? SI 1.1.2 NO

Cliente

Información forma de pago

Emitir información de valor crédito

Emitir información de valor contado

14

ANÁLISIS Y DISEÑO DE SISTEMAS I1.1.4 Obtención de Solicitud

1.1.4 Pedir solicitud

Emitir solicitudInformaci ón solicitud Solicitudes

Cliente

Solicitud impresa

Pedir solicitud

1.2 Comprar un auto de manera física

Consulta modelos y precios

Catálogo de autos

Solicita información para seleccionar un modelo de auto

1.2.1

Datos de modelos

Proveer información de catálogos

Cliente

Información de modelos de autos

1.2.2 Verificar Stock

15

ANÁLISIS Y DISEÑO DE SISTEMAS IConsulta existencia

Inventario autos

Solicita información de existencia del modelo seleccionado Vehículo si existe

1.2.2

Datos de existenci a

Verificar existencia

Datos existencia

Cliente

No existe en stock y tiempo demora en producción

Existe en stock? SI

NO

1.2.3 Verificar Solicitud

Envía solicitud de compra del modelo seleccionado

1.2.3

Datos verificados

Solicitud Rechazada

Verificar solicitud

Datos correctos ? NO

SI

Solicitud Aprobada

16

ANÁLISIS Y DISEÑO DE SISTEMAS I1.2.4 Consulta de Financiamiento

Crédito

Define la forma de pago

1.2.5 Conta do? SI 1.2.4 NO

Aprobar crédito

Cliente

Valor contado

Consultar valor contado

1.2.5

Elaboración de Contrato

1.2.6 Solicita elaboración de contrato

Elaborar Contrato

Contrato

Cliente