ACI491: Ingeniería de Software

Presentación del tema: "ACI491: Ingeniería de Software"— Transcripción de la presentación:

1 ACI491: Ingeniería de Software
Unidad 2: Organizaciones y Sistemas de Información

2 Contenidos Análisis y diseño de sistemas: el trabajo de un analista.
Sistemas de Información Organizacionales: los procesos. Categorías de Sistemas: cómo y dónde nacen los sistemas. Plantación de Sistemas: Sistemas y la Organización.

3 Objetivos Interiorizar al alumno en el funcionamiento de las organizaciones. Identificar los tipos de organizaciones y los procesos relacionados con estas.

4 Introducción En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones. Las empresas consideran con mucho cuidado las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia. Cualquiera que sea la necesidad de información de una organización, siempre se debe fundamentar en una solicitud (por escrito y firmada) por parte de alguna parte involucrada en el mismo, sea este un usuario, analista, gerente, encargado de proyectos, etc.

5 Aspectos a considerar En la propuesta de un sistema se deben establecer muy claramente los siguientes puntos: ¿Cuál es el problema? Detalles del problema Importancia del problema ¿Cuál cree el solicitante que puede ser la solución al mismo? ¿En qué forma ayuda un sistema de información? Breve resumen de los reportes usados y funciones que se realizan ¿Qué otras personas tienen conocimiento del problema y que se pueden contactar? Esta propuesta debe ser analizada por un comité (o su equivalente), que determina lo urgente de poner a andar los medios necesarios para tratar resolver la situación.

6 Análisis y Diseño de Sistemas: El trabajo de un analista

7 ¿Qué es el Análisis y Diseño de Sistemas?
Dentro de las organizaciones, 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 mejorarla con métodos y procedimientos mas adecuados. Panorama del análisis y diseño de sistemas. El desarrollo de sistemas puede considerarse, en general, formado por dos grandes componentes: el análisis de sistemas y el diseño de sistemas. 

8 Análisis y Diseño de Sistemas
 Análisis de sistemas Es el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y empleo de información para recomendar mejoras al sistema. Diseño de sistemas Es el proceso de planificar, reemplazar o complementar un sistema organizacional existente. Pero antes de llevar a cabo esta planificación es necesario comprender, en su totalidad, el viejo sistema y determinar la mejor forma en que se pueden, si es posible, utilizar las computadoras para hacer la operación más eficiente.

9 El trabajo de un analista
Un analista se ocupa de llevar a cabo el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y empleo de información para recomendar mejoras a un sistema. Un analista de sistemas estudia las necesidades y problemas de una empresa para determinar cómo pueden combinarse recursos humanos, procesos, datos y tecnologías de la información para obtener mejoras en la empresa o para planificar expansiones. Identificar Necesidades Buscar información Detallar 9

10 El Analista de Sistema El Analista de Sistema nace de la necesidad de recopilar, desglosar, catalogar y analizar información necesaria de una empresa para poder proponer nuevos métodos, mejores o modificar los actuales para que así aumente el desempeño de los departamentos dentro de la organización. En toda organización un analista se vale de la información de entrada, los procesos modificadores y la información de salida, para así definir los procesos intermedios y poder entender con claridad a la organización. Todos estos flujos y procesos son estudiados sistemáticamente para poder determinar si son los adecuados, si se deben mejorar o si deben ser reemplazados por otros más idóneos. En resumen: Un analista de sistema identifica necesidades, busca información y la detalla.

11 Habilidades necesarias
El trabajo de un analista, según Whitten, Bentley y Dittman, demanda: Conocimientos generales de la empresa. Capacidad de resolver problemas. Técnicas de comunicación interpersonal. Flexibilidad y capacidad de adaptación. Carácter y ética. Mejorar los conocimientos en tecnología y sistemas de información. Experiencia y dominio de la programación informática. Identificar Necesidades Buscar información Detallar 11

12 Hacia una definición Según Senn (cita)
"…Los analistas hacen mucho más que resolver problemas. Con frecuencia se solicita su ayuda para planificar la expansión de la organización…", Es decir: El papel de los analistas sobrepasa los limites impuestos por la definición inicial, también cumplen el papel de asesores, ya sea en sistemas manuales o informatizados, o cualquier otro sistema donde la empresa tenga que invertir en información. Después de todo, esa es la razón de ser del analista.

13 Identificación de Necesidades “Análisis de Requisitos”
Primer paso del análisis del sistema. En este proceso el “Analista” se reúne con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación temporal y presupuestal y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto informático. Se divide en cinco partes: Reconocimiento del problema. Evaluación y Síntesis. Modelado. Especificación. Revisión. (Ver notas de esta transparencia) El Analista de Sistemas El Analista de Sistema nace de la necesidad de recopilar, desglosar, catalogar y analizar información necesaria de una empresa para poder proponer nuevos métodos, mejores o modificar los actuales para que así aumente el desempeño de los departamentos dentro de la organización. En toda organización un analista se vale de la información de entrada, los procesos modificadores y la información de salida, para así definir los procesos intermedios y poder entender con claridad a la organización. Todos estos flujos y procesos son estudiados sistemáticamente para poder determinar si son los adecuados, si se deben mejorar o si deben ser reemplazados por otros más idóneos. Santos (1980, p.12) define las funciones del analista de sistemas para la década de los ochenta como sigue; "…el analista de problemas en computación deberá conocer procedimientos para indagar sobre lo existente y para saber proponer un verdadero sistema racionalizado, pero también deberá conocer sobre modernos sistemas de información, base del diseño, sobre todo en computación… Estos últimos factores son los que justifican tal especialidad, porque realmente debieron existir los analistas de sistemas, aunque no hubiera computadores, toda vez que siempre hubo sistemas para organizar, que posiblemente no se difundieron porque no existieron en importancia esos dos factores que hoy prevalecen: el computador y la información." La definición de analista de sistemas de Senn (1992, p. 12), agrega: "…Los analistas hacen mucho más que resolver problemas. Con frecuencia se solicita su ayuda para planificar la expansión de la organización…", es decir, el papel de los analistas sobrepasa los limites impuestos por la definición inicial, también cumplen el papel de asesores, ya sea en sistemas manuales o informatizados, o cualquier otro sistema donde la empresa tenga que invertir en información, después de todo esa es la razón de ser del analista. Comparando las dos definiciones anteriores podemos notar que en veinte años no ha cambiado la descripción de analista de sistemas, más bien se le han atribuido nuevas características que lo definen como un ente de cambio, necesario en cualquier organización con tendencia a crecer. Según Senn, dependiendo de las funciones de un analista de sistemas se puede clasificar en: Analista de sistemas, Analista y diseñador de sistemas y analista diseñador y programador de sistemas, en donde cada uno se puede identificar y diferenciar de los demás por las actividades que definen sus denominaciones. También podemos clasificar a los analista de sistema como Consultor, Experto de soporte y Agente de cambio, clasificación según Kendall (1997, p.6). Vale la pena explicar un poco la clasificación de éste último autor debido a que no se basa en las actividades propias del analista, sino los papeles que cumple en las fases impuestas en el paradigma Ciclo de Vida de Desarrollo de Sistemas (CVDS). Cuando se comienza el CVDS el analista cumple en papel de consultor, asesorando a la empresa sobre los mejores métodos y sistemas que se pueden emplean para la óptima gestión de información, recomendando sistemas ya sean de tipo manual o de tipo informático, predominando claro, los sistemas informáticos que le dan la vida a ésta profesión. El experto en soporte se identifica con los últimos pasos del CVDS donde el analista se desempeña en el asesoramiento de hardware y software, basado en el conocimiento y especialmente en la experiencia. Sirviendo el analista muchas veces de escalón para hacer que el sistema desarrollado (no liderizado por él) tenga éxito. Como Agente de Cambio se tiene el papel más importante y más difícil, la comunicación con empleados dentro de la fase de recopilación de información es probable que los empleados piensen que el sistema los va a sustituir, aunque algunas veces es cierto, el analista debe internalizar que el cambio es en pro de la organización y no de un grupo minoritario o sectorial. Así desarrollar sus actividades de manera regular. Una pregunta común sobre los analistas de sistemas es ¿Todos los analistas deben programar?, Según Senn (1992, p.16); "…La respuesta depende de la organización. Sin embargo, una cosa es evidente: el analista de sistemas más valioso y mejor calificado es aquel que sabe programar.", ciertamente el analista que tiene fuertes principios de programación sabe que se puede y que no se puede, o que es difícil de desarrollar en un lapso de tiempo, recordemos que todos los proyectos informáticos tienen siempre lapsos de tiempo bien reducidos y que si no se tiene el equipo apropiado es difícil cumplir con los plazos establecidos, lo que trae como consecuencia muchas veces la falla de todo el proyecto. Además el analista programador tiene facilidad para comunicar sus ideas a los constructores de código, ya que él estuvo en ese lugar alguna vez y sabe en que forma se necesita la información al momento de generar código. Contacto del Analista con los Usuarios Es difícil determinar el tamaño de un sistema a desarrollar si no conocemos los diferentes niveles del mismo, los diferentes detalles de las salidas de información, a quienes van dirigidas y cual es la mejor forma de hacerlo. Los analistas de Sistemas están en la obligación de recorrer desde los niveles más altos de la empresa (gerentes y directivos), hasta los niveles más bajos (obreros y empleados) para determinar quienes realmente necesitan la información, con que oportunidad y grado de detalle de cada peldaño de la escalera institucional. "Los gerentes y empleados tienen buenas ideas a qué es lo que si trabaja y qué es lo que no, qué causa problemas y qué no, dónde son necesarios los cambios y dónde no."(Senn, p.13), en efecto, quien mejor que los que día a día ven el sistema y como sus compañeros o subordinados lo reciben, para decirle al analista con anticipación cual será la aceptación del producto final y que mejoras deben tener. A fin de cuentas ellos son los que le sacarán provecho al sistema, los que se alimentarán del mismo. 13

14 Determinación de requerimientos
Es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras. El objetivo del análisis de sistemas es comprender situaciones, no resolver problemas. Por tanto, los buenos analistas hacen hincapié en la investigación y el cuestionamiento para conocer cómo opera el sistema e identificar los requerimientos que tienen los usuarios para modificarlo o proponer uno nuevo. Un requerimiento es una característica que debe incluirse en un nuevo sistema.

15 Preguntas claves Los analistas, al trabajar con los empleados de la empresa, deben estudiar el proceso que se efectúa actualmente para así poder contestar las preguntas claves de esta fase: ¿Qué es lo que hace? y ¿Cómo se está haciendo? ¿Qué tan frecuentemente ocurre? ¿Conque frecuencia se presenta? ¿Qué tan grande es la cantidad de transacciones o decisiones? ¿Cuál es el grado de eficiencia con el que se efectúan las tareas? ¿Existe algún problema?, sí el problema existe, ¿Qué tan serio es y cuál es la causa principal que lo origina?

16 Obtención de respuestas
Para que el analista pueda contestar estas preguntas deberá hablar con diferentes grupos de empleados para así recabar diferente opiniones sobre las causas por las que se originan las cosas. Los métodos de recolección pueden ser cuestionarios a grupos de personas o individuales, también se requiere estudiar los manuales y reportes, observar los comportamientos y actividades, recabar formas y documentos para entender los procesos. Una vez, recopilada la información, los analistas estudian los requerimientos para identificar las características del nuevo sistema.

17 Enfoque primario El enfoque primario durante el análisis de sistemas debe estar en las operaciones de la empresa, los requerimientos de los usuarios y los componentes estructurales de la entrada, la salida, la base de datos y los controles.  Uno de los mayores errores que se repiten una y otra vez en el trabajo en sistemas se resume de la siguiente manera: “Vamos a conseguir una computadora; luego vamos a  ver si existe algún software que corra en ella; y después de eso, vamos a ver como lo vamos a usar”. El objetivo tanto del usuario como de los analistas de sistemas durante el análisis de sistemas es llegar a un acuerdo de ideas para establecer lo que realmente se necesita para realizar el trabajo y lo que el sistema les puede proporcionar.

18 Investigación preliminar
La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones. Sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona - administrador, empleado o especialista en sistemas -. Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigación preliminar. Esta actividad tiene tres partes: aclaración de la solicitud, estudio de factibilidad y aprobación de la solicitud.

19 Aclaración de la solicitud
Muchas solicitudes que provienen de empleados y usuarios no están formuladas de manera clara. Por consiguiente antes de considerar cualquier investigación de sistemas, la solicitud de proyecto debe examinarse para determinar con precisión lo que el solicitante desea. Si este tiene una buena idea de lo que necesita pero no esta seguro como expresarlo, entonces bastara con hacer una llamada telefónica. Por otro lado, si el solicitante pide ayuda sin saber lo que esta mal o donde se encuentra el problema, la aclaración del mismo se vuelve más difícil. En cualquier caso, antes de seguir, adelante la solicitud debe estar claramente planteada.

20 Estudio de factibilidad
Un resultado importante de la investigación preliminar es la determinación de que el sistema solicitado sea factible. En la investigación preliminar existen tres aspectos relacionados con el estudio de factibilidad: Factibilidad técnica. El trabajo para el proyecto, ¿Puede realizarse con el equipo actual, la tecnología existente de software y el personal disponible? Si se necesita nueva tecnología, ¿Cual es la posibilidad de desarrollarla? Factibilidad económica . Al crear el sistema, ¿los beneficios que se obtienen serán lo suficientes para aceptar los costos?. ¿Los costos asociados con la decisión de no crear el sistema son tan grandes que se debe aceptar el proyecto? Factibilidad operacional Si se desarrolla e implanta, ¿será utilizado el sistema? ¿Existirá cierta resistencia al cambio por parte de los usuarios que de como resultado una disminución de los posibles beneficios de la aplicación?

21 Estudio de factibilidad (2)
El estudio de factibilidad lo lleva a cabo un pequeño equipo de personas (en ocasiones una o dos) que esta familiarizado con técnicas de sistemas de información. Dicho equipo comprende la parte de la empresa u organización que participara o sé vera afectada por el proyecto, y es gente experta en los procesos de análisis y diseños de sistemas. En general, las personas que son responsables de evaluar la factibilidad son analistas capacitados o directivos .

22 Aprobación de la solicitud
No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que solo es posible atender unas cuantas. Sin embargo aquellos proyectos que son deseables y factibles deben incorporarse a los planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo común es que los miembros del equipo de sistemas se encuentren ocupados con otros proyectos. Cuando esto ocurre, la administración decide que proyectos son los más importantes y decide el orden en que se llevaran a cabo. Muchas organizaciones desarrollan sus planes para sistemas de información con el mismo cuidado con el que planifican nuevos productos y programas de fabricación o la expansión de sus instalaciones. Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta información se determina como ubicarlo dentro de la lista existente de proyectos. Mas adelante cuando los demás proyectos se han completado, se inicia el desarrollo de la aplicación propuesta.

23 Lista detallada de actividades

24 Diseño de sistema El diseño de un sistema de información produce los detalles que establecen la forma en que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la de desarrollo del software, a la que denominan diseño físico. Los analistas de sistemas comienzan el proceso de diseño identificando los reportes y demás salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisión los datos específicos para cada reporte y salida. Es común que los diseñados hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema este terminado. Lo anterior se efectúa en papel o en la pantalla de un terminal utilizando para ello alguna de las herramientas automatizadas disponibles para el desarrollo de sistemas. El diseño de un sistema también indica los datos de entrada, aquellos que serán calculados y los que deben ser almacenados.

25 Diseño … (2) Asimismo se escriben con todo detalle los procedimientos de calculo y los datos individuales. Los diseñadores seleccionan las estructuras de archivos y los dispositivos de almacenamiento, tales como discos y cintas magnéticas o incluso archivos en papel. Los procedimientos que se escriben indican como procesar los datos y producir las salidas. Los documentos que contienen las especificaciones de diseño representan a este de muchas maneras (diagramas, tablas y símbolos especiales). La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software. Los diseñadores son los responsables de dar a los programadores las especificaciones de software completas y claramente delineadas. Una vez comenzada la fase de programación, los diseñadores contestan preguntas, aclara dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones del diseño.

26 Desarrollo de software
Los encargados de desarrollar software pueden instalar (o modificar y después instalar) software comprado o terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Por regla general, los programadores (o analistas programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. En empresas pequeñas, donde no hay programadores, se pueden contratar servicios externos de programación. Los programadores también son responsables de la documentación de los programas y de proporcionar una explicación de como y por que ciertos procedimientos se codifican en determinada forma. La documentación es esencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicación se encuentra instalada.

27 Prueba de Sistemas Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y después se examinan sus resultados. En ocasiones se permite que varios usuarios utilicen el sistema para que los analistas observen si tratan de emplearlo en formas no previstas. Es preferible descubrir cualquier sorpresa antes de que la organización implante el sistema y dependa del. En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribió los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean completas e imparciales y por otra, que el software sea más confiable.

28 Resumen de las etapas

29 Sistemas de Información Organizacionales

30 Sistemas de Información: Clasificación en tres categorías
Sistemas de Procesamiento de Transacciones (TPS): Son los que llevan a cabo los procedimientos estándares de operación que facilitan el manejo de las transacciones. Se incluyen, en general, en los programas de computo que controlan la entrada de datos, el procesamiento de los datos, el procesamiento de los detalles y almacenamiento y presentación tanto de datos como de información. Sistemas de Información Administrativos: Están orientados hacia la toma de decisiones y utilizan datos relacionados con las transacciones así como cualquier otra información que sea generada dentro o fuera de la compañía. Sistemas para el Soporte de Decisiones: Tienen como finalidad ayudar a los directivos que enfrentan problemas de decisión únicos. Con frecuencia, un aspecto importante de estas decisiones es determinar que información es la que se debe considerar.

31 Estrategias para el desarrollo de sistemas
Los sistemas de información basados en computadoras sirven para diversas finalidades que van desde el procesamiento de las transacciones de una empresa (la sangre de muchas organizaciones), hasta proveer de la información necesaria para decidir sobre asuntos que se presentan con frecuencia, asistencia a los altos funcionarios con la formulación de estrategias difíciles y la vinculación entre la información de las oficinas y los datos de toda la corporación. En algunos casos, los factores que deben considerarse en un proyecto de sistemas de información, tales como el aspecto mas apropiado de la computadora o la tecnología de comunicaciones que se va a utilizar, el impacto del nuevo sistema sobre los empleados de la empresa y las características especificas que el sistema debe tener, se pueden determinar de una manera secuencial. En otros casos, debe ganarse experiencia por medio de la experimentación conforme el sistema evoluciona por etapas.

32 Enfoques para el desarrollo de sistemas de información
A medida que las computadoras son empleadas cada vez mas por personas que no son especialistas en computación, el rostro del desarrollo de sistemas de información adquiere una nueva magnitud. Los propios usuarios emprenden ya el desarrollo de alguno de los sistemas que ellos emplean, como por ejemplo el ejecutivo. Todas estas situaciones están representadas por tres distintos enfoques al desarrollo de sistemas de información: Método del ciclo de vida para el desarrollo de sistemas. Método del desarrollo del análisis estructurado Método del prototipo de sistemas

33 Estrategias de desarrollo de sistemas
Estrategia de desarrollo Descripción Características de Aplicación Método del ciclo de vida de desarrollo de sistemas. Incluye las actividades de: Investigación preliminar, Determinación de requerimientos, Diseño del sistema, Desarrollo del software. Prueba de sistema e Implantacion. Requerimientos del sistema de información predecibles. Manejable como proyecto. Requiere que los datos se encuentren en archivos y bases de datos. Gran volumen de transacciones y procesamiento. Requiere de la validación de los datos de entrada. Abarca varios departamentos. Tiempos de desarrollo largos. Desarrollo por equipo de proyectos. Método del análisis estructurado. Se enfoca en lo que el sistema o aplicación realizan sin importar la forma en que llevan a cabo su función (se abordan los aspectos lógicos y no los físicos.). Emplea símbolos gráficos para describir el movimiento y procesamiento de datos. Los componentes importantes incluyen los diagramas de flujos de datos y los diccionarios de datos. Adecuado para todo tipo de aplicaciones. Mayor utilidad como complemento de otros métodos de desarrollo. Método del prototipo de sistemas. Desarrollo iterativo o en continua evolución donde el usuario participa directamente en el proceso. Condiciones únicas de la aplicación donde los encargados del desarrollo tiene poca experiencia o información, o donde los costos y riesgos de cometer un error pueden ser altos. Asimismo, útil para probar la factibilidad del sistema, identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.

34 Ciclo de vida clásico del desarrollo de sistemas
El desarrollo de sistemas, un proceso formado par las etapas de análisis y diseño, comienza cuando la administración o algunos miembros del personal encargado de desarrollar sistemas, detectan que un sistema de la empresa necesita mejoras. El método del ciclo de vida para desarrollo de sistemas (SDLC) es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. 34

35 Ciclo de vida clásico del desarrollo de sistemas (2)
El método del ciclo de vida para desarrollo de sistemas consta de las siguientes actividades: Investigación preliminar Determinación de los requerimientos del sistema Diseño del sistema Desarrollo del software Prueba de los sistemas Implantación y evaluación 35

36 Ciclo de vida clásico del desarrollo de sistemas
Simplificando aún más estas fases descritas anteriormente obtenemos el CVDS moderno: Planificación del Proyecto. Análisis del Sistema Actual. Diseño del Sistema Propuesto. Implantación y documentación del sistema. Evaluación y soporte del sistema.

37 Análisis Estructurado
Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de: La división del sistema en componentes y La construcción de un modelo del sistema. El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadores, terminales, sistemas de almacenamiento, etc.). (incluye cuestionario) 37

38 Análisis Estructurado (2)
Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado. El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente. (incluye cuestionario) 38

39 Componentes del análisis estructurado
Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o automatizado. Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas: estándares para describir y documentar el sistema en forma correcta y completa. (incluye cuestionario) 39

40 Diseño Estructurado Es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica. Se enfoca en el desarrollo de especificaciones del software. Su objetivo es programas formados por módulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él. (incluye cuestionario) 40

41 Análisis de flujo de datos y herramientas
Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas. Usa los diagramas de flujos de datos y los diccionarios de datos. Herramientas Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si. Como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones. (incluye cuestionario) 41

42 Diagrama de flujo de datos (DFD)
Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes. El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Esta secuencia se repite hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación. (incluye cuestionario) 42

43 Diagramas físico y lógico
El diagrama físico de datos brinda un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos. El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico, es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos específicos y la localización de los almacenes de datos o personas en el sistema. Sin indicarse las características físicas. (incluye cuestionario) 43

44 Notaciones en diagramas físico y lógico
Fueron desarrollados y promovidos al mismo tiempo por dos organizaciones: Yourdon / De Marco y Gane & Sarson. Son cuatro símbolos: Flujo de datos: Son movimientos de datos en una determinada dirección, desde un origen hasta un destino. Es un paquete de datos. Proceso: Son personas, procedimientos o dispositivos que utilizan o producen datos. No identifica el componente físico. Fuente o destino de los datos( Entidad externa): Pueden ser personas, programas, organizaciones u otras entidades que interactúan con el sistema pero que se encuentran fuera. Almacenamiento de datos: Es un lugar donde se guardan los datos. El almacenamiento de datos puede representar dispositivos tanto computarizados como no computarizados. (incluye cuestionario) 44

45 Símbolos del DFD Flujo de datos Proceso Entidad Externa

46 Ejemplo

47 Diagramas físico y lógico
Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombre descriptivo. Los nombres de los procesos reciben un numero para poder identificarlos, este numero tiene un valor adicional cuando se estudian los componentes que integran un proceso especifico. (incluye cuestionario) 47

48 Prototipo de Sistemas La construcción de prototipos representa una estrategia de desarrollo cuando no es posible determinar todos los requerimientos del usuario. Es por ello que incluye el desarrollo interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso. Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos. Así mismo este método resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.

49 Prototipo de Sistemas (2)
El método consta de 5 etapas: Identificación de requerimientos conocidos Desarrollo de un modelo de trabajo Utilización del prototipo Revisión del prototipo Repetición del proceso las veces que sea necesarias

50 Identificación de requerimientos conocidos
La determinación de los requerimientos de una aplicación es tan importante para el método de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.

51 Desarrollo de un modelo de trabajo
Es fácil comenzar el procesos de construcción del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un cronograma para el inicio y el fin de la primera interacción es de gran ayuda. En el desarrollo del prototipo se preparan los siguientes componentes: El lenguaje para el dialogo o conversación entre el usuario y el sistema. Pantallas y formatos para la entrada de datos. Módulos esenciales de procesamiento. Salida del sistema

52 Utilización del prototipo
Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas.

53 Revisión del prototipo
Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios. Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.

54 Repetición del proceso
El proceso antes descrito se realizará todas las veces que sean necesarias. El proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.

55 Plantación de Sistemas en una Organización

56 Plantación de Sistemas
La implantación es el proceso de verificar e instalar nuevo equipo: Entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Dependiendo del tamaño de la organización que empleara la aplicación y el riesgo asociado con su uso, puede elegirse comenzar la operación del sistema solo en un área de la empresa (prueba piloto), por ejemplo en un departamento o con una o dos personas.

57 Plantación de Sistemas (2)
Algunas veces se deja que los sistemas, el viejo y el nuevo, trabajen en forma paralela, con la finalidad de comparar los resultados. En otras circunstancias, el viejo sistema deja de utilizarse determinado día para comenzar a emplear el nuevo el día siguiente. Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cual sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.

58 Uso de los Sistemas Una vez instaladas, las aplicaciones se emplearan posiblemente durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo. Incluso, el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente es indudable que debe darse mantenimiento a las aplicaciones, realizar cambios y modificaciones en el software archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de las organizaciones junto con el ambiente de las empresas experimentan cambios de manera continua, los sistemas de información deben mantenerse siempre al día. En este sentido, la implantación es un proceso en constante evolución.

59 Evaluación de Sistemas
La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones: Evaluación Operacional Impacto Organizacional Opinión de los Administradores Desempeño del desarrollo Desafortunadamente la evaluación de sistema no siempre recibe la atención que merece. Sin embargo, cuando se conduce en forma adecuada, proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.

60 Evaluación de Sistemas (2)
Evaluación Operacional Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización. Impacto Organizacional Identificación y medición de los beneficios para la organización en ares tales como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información interno y externo.

61 Evaluación de Sistemas (3)
Opinión de los Administradores Evaluación de las actitudes de directivos y administradores dentro de la organización así como de los usuarios finales. Desempeño del desarrollo La evaluación del proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuesto y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.

62 Ejercicios ¿Qué es el análisis de sistemas? Explique.
¿Cuáles son las fuentes de datos para el análisis de sistemas? ¿Cuál es el objetivo tanto del usuario como de los analistas de sistemas durante el análisis de sistemas?  ¿Qué es un prototipo de sistemas? ¿Qué es el análisis estructurado? ¿Cuál es la diferencia entre el método del ciclo de vida de desarrollo de sistemas y el análisis estructurado? ¿Se pueden vincular estos métodos? ¿Qué habilidades de un analista de sistemas no se aprenden en clases? ¿Qué son los requerimiento de un sistema de información? 

63 Ejercicios (2) ¿Cuál es la función de la Información?
Analice la siguiente afirmación: "La información es el cemento que mantiene unida la organización". Mencione y describa 7 maneras de utilizar la Información Investigue cuáles son los atributos de la Información. Investigue la relación de los Conceptos Sistemas de Información con la aplicación de los conceptos del Enfoque de Sistemas. Explique tres objetivos básicos que se persiguen a través de los Sistemas de Información. Elegir una empresa y discutir que información es relevante para el cumplimiento de sus objetivos, además de ordenarla de acuerdo a las categorías de la información. Mencionar cinco sistemas que sean típicos en la etapa de inicio de una empresa.

64 Ejercicios (3) Elaborar el diseño conceptual de un Sistema de Información, indicando claramente las entradas, almacenamiento, proceso y las salidas. Hacer una lista de los Sistemas de Información que se encuentren operando en alguna empresa mediana o grande indicando el tipo de sistema al que pertenece cada uno. Haga una comparación entre los diferentes tipos de usuarios de los sistemas de información. ¿Qué diferencias existen entre las responsabilidades de cada uno? La mayoría de los problemas que se tienen con los sistemas de información desaparecerán cuando las computadoras sean más rápidas y baratas. ¿Cierto? En un grupo con tres o cuatro compañeros describir un sistema de información en términos de sus insumos, procesos y productos, y en términos de las características de su administración, organización y tecnología.

65 Tarea Analice comparativamente las ventajas y desventajas del ciclo de vida clásico y el modelo de prototipos.

66 Bibliografía Básica: Gloria Appelgren et. al. “Curso de Análisis de Sistemas” (documento en archivo Partebasica_SENN_Para_Curso_de_Analisis_de_Sistemas.doc) James A. Senn: “Análisis y Diseño de Sistemas de Información”, Segunda Edición, Editorial McGraw-Hill, España, Eduard Yourdon, Análisis Estructurado Moderno. Primera Edición, Prentice Hall Hispanoamericana S.A México 1993. Complementaria: “Análisis de Sistemas” (archivo Analisis_de_Sistemas.pdf) Juan Bravo Carrasco: “Análisis de Sistemas”, Primera Edición, Editorial Evolución S.A., Chile, 1998. Roger S. Presmann: “Ingeniería del Software: un Enfoque Práctico”, Tercera Edición, Editorial McGraw-Hill, España,

67 Referencias en Internet
Ingeniería de software Análisis y Diseño de Sistemas de Información. Metodología de James A. Senn Análisis Estructurado de Sistemas de Información (Incluye cuestionario y casos de estudio.) Índice. “El analista de sistemas y el paradigma estructurado” Fernández “Desarrollo de sistemas de información: Una metodología basada en el modelado” Whitten, Bentley y Dittman “Systems Analysis and Design Methods”, 6/e Enlaces Web: Sistemas Herramientas del Análisis Estructurado