1. L I C E N C I A T U R A E N A N A L I S I S D E S I S T E M A S<br />C O M P U T A C I O N V I FUNDAMENTACIÓN<br />Teniendo en cuenta los cambios tan acelerados de la tecnología y en especial de la<br />Informática, hace necesaria una adecuación constante de las organizaciones, se pretende obtener especialistas con amplios conocimientos de la problemática organizacional y sus componentes básicos y la solución de éstos a través de la implementación de sistemas de información.<br />OBJETIVOS<br />1. Introducción a la problemática en el desarrollo de software. Métodos de análisis y especificación de requerimientos, diseño de software, implementación, integración y prueba. Introducción a al menos un método formal del análisis y diseño contemporáneos, orientado a objetos. Proporcionar conocimientos detallados de las capacidades, técnicas y métodos básicos requeridos para el análisis y diseño de sistemas de información.<br />2. Presentar los requerimientos esenciales del diseño de sistemas lógicos y desarrollar<br />las aptitudes de los estudiantes para diseñar subsistemas bien concebidos y eficaces, tanto manuales como informatizados.<br />3. Definir e ilustrar las normas que deben cumplirse en la especificación, diseño y documentación de los sistemas de información.<br />4. Desarrollar las aptitudes de comunicación del estudiante.<br />UNIDADES PROGRAMÁTICAS<br />CONTENIDOPÁG.<br />1.La información como un recurso de las organizaciones.03<br />2.Papeles del analista de sistemas.07<br />3.El ciclo de desarrollo de los sistemas.12<br />4.Archivos convencionales y bases de datos.16<br />5.Conceptos de datos.18<br />6.Normalización.30<br />7.Uso de la base de datos.32<br />8.DFD - Diagramas de flujos de datos.33<br />9.El diccionario de datos.39<br />10.Metodología para el desarrollo y mantenimiento de sistemas.41<br />11.Casos prácticos.<br />UNIDAD I<br />CONTENIDO<br />1.La información como un recurso de las organizaciones.<br />1.1. Administración de la información como recurso.<br />1.2. Administración de la información generada por computadora.<br />1.3. Conceptos de diseño y análisis de sistema.<br />1.4. Tipos de sistemas.<br />1.4.1. Sistemas de procesamiento de Transacciones.<br />1.4.2. Sistemas de automatización de oficina y sistemas de manejo de conocimiento.<br />1.4.3. Sistema de información gerencial.<br />1.4.4. Sistemas de apoyo para la toma de decisiones.<br />1.4.5. Sistemas expertos e inteligencia artificial.<br />1.5. Necesidad del análisis y el diseño de sistemas.<br />1.6. Tipos de usuarios de sistemas.<br />Aspectos generales.<br />Las organizaciones reconocían, desde hace mucho la importancia de administrar recursos básicos tales como la mano de obra y las materias primas. Pero solo desde hace poco a la información se la ha considerado como recurso principal. Los tomadores de decisiones están comenzando a comprender que la información no es sólo un subproducto de la conducción, sino que a la vez alimenta a los negocios y puede ser el factor crítico para la determinación del éxito o fracaso de éstos.<br />1.1Administración de la información como recurso.<br />Para maximizar la utilidad de la información, un negocio debe administrarla correctamente tal como maneja los demás recursos. Los administradores necesitan comprender que hay costos asociados con la producción, distribución, seguridad, almacenamiento y recuperación de la información. Aunque la información se encuentra<br />a nuestro alrededor, ésta no es gratis ni libre, y su uso es estratégico para incrementar la competitividad de un negocio.<br />1.2Administración de la información generada por computadora.<br />La fácil disponibilidad de computadoras ha creado una explosión de información a través de la sociedad en general y de los negocios en particular. El manejo de información generada por computadora difiere en forma significativa del manejo de datos producidos manualmente. Por lo general, hay mayor cantidad de información de computadora a administrar.<br />El costo de organizarla y mantenerla puede crecer a niveles alarmantes, y los usuarios la juzgan frecuentemente, como más confiable que la información obtenida por otras vías.<br />1.3Conceptos de diseño y análisis de sistema.<br />Los sistemas de información son desarrollados con propósitos diferentes dependiendo<br />de las necesidades del negocio. Los sistemas de procesamiento de transacciones (TPS<br />por sus siglas en inglés) funcionan al nivel operacional de la organización, los sistemas<br />de automatización de oficina (OAS por sus, siglas en inglés) y los sistemas de trabajo de conocimiento (KWS por sus siglas en inglés) que dan cabida al trabajo a nivel de conocimiento. Los sistemas de más alto nivel incluyen a los sistemas de apoyo a decisiones (DSS por sus siglas en inglés) así como a los sistemas de información gerencial (MIS por sus siglas en inglés). Los sistemas expertos aplican la experiencia de<br />los tomadores de decisiones para resolver problemas específicos estructurados. Al nivel estratégico de la administración encontramos sistemas de apoyo a ejecutivos (ESS por sus siglas en inglés) y los sistemas de apoyo a decisiones de grupo (GDSS por sus siglas<br />en inglés) ayudan a la toma de decisiones al mismo nivel, en una forma sin estructura o semi-estructurada.<br />1.4Tipos de sistemas.<br />1.4.1 S ist e mas d e p r oc esa mien to d e t ran s ac cion e s<br />Los sistemas de procesamiento de transacciones (TPS) son sistemas de información computarizadosdesarrolladosparaprocesargrancantidaddedatospara transacciones rutinarias de los negocios, tales como nómina e inventario. Los TPS eliminan el tedio de las transacciones operacionales necesarias y reducen el tiempo que alguna vez se requirió para ejecutarlas manualmente, aunque la gente todavía debe alimentar datos a los sistemas computarizados.<br />Los sistemas de procesamiento de transacciones son sistemas que traspasan fronteras<br />y que permiten que la organización interactúe con ambientes externos Debido a que<br />los administradores consultan los datos generados por el TPS para información al minuto acerca de lo que está pasando en sus compañías, es esencial para las operaciones diarias que estos sistemas funcionen lentamente y sin interrupción.<br />1.4.2 Sistemas de automatización de oficina y sistemas de manejo de conocimiento<br />Al nivel de conocimiento de la organización hay dos clases de sistemas. Los sistemas de automatización de oficina (OAS) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la información para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organización y algunas veces más allá. Los aspectos familiares de los OAS incluyen procesamiento de<br />palabras, hojas de cálculo, editor de publicaciones, calendarización electrónica y comunicación mediante correo de voz, correo electrónico y videoconferencias.<br />Los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como científicos, ingenieros y doctores, les ayudan a crear un nuevo conocimiento que contribuya a la organización, o a toda la sociedad.<br />1.4.3 S ist e mas d e in f or maci ón g er en ci al<br />Los sistemas de información gerencial (MIS) no reemplazan a los sistemas de procesamiento de transacciones, sino que todos los MIS incluyen procesamiento de transacciones. Los MIS son sistemas de información computarizada que trabajan debido a la interacción resuelta entre gentes y computadoras. Requieren que las personas, el software (programas de computadora) y el hardware (computadoras, impresoras, etc.) trabajen armoniosamente. Los sistemas de información dan soporte<br />a un espectro más amplio de tareas organizacionales que los sistemas de procesamiento de transacciones, incluyendo el análisis de decisiones y la toma de decisiones.<br />Para poder ligar la información, los usuarios de un sistema de información gerencial comparten una base de datos común. La base de datos guarda modelos que ayudan a<br />los usuarios a interpretar y aplicar esos mismos datos. Los sistemas de información gerencial producen información que es usada en la toma de decisiones. Un sistema<br />de información gerencial también puede llegar a unificar algunas de las funciones de información computarizada, aunque no exista como una estructura singular en ningún lugar del negocio.<br />1.4.4 S ist e mas d e ap oyo p a ra l a t o ma d e d ecisi on es<br />Una clase de más alto nivel en los sistemas de información computarizada son los sistemas de apoyo a decisiones (DDS). El DSS es similar al sistema de información gerencial tradicional en que ambos dependen de una base de datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de información gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisión actual todavía es del dominio del tomador de decisiones. Los sistemas de apoyo a decisiones están hechos más a la medida de la persona o grupo que los usa que los sistemas de información gerencial tradicionales.<br />1.4.5 S ist e mas exp e r tos e in teli gen cia a r t if icial<br />La inteligencia artificial (AI por sus siglas en inglés) puede ser considerada la meta<br />de los sistemas expertos. El empuje general de la Al ha sido desarrollar máquinas que se comporten de forma inteligente. Dos caminos de la investigación de la AI son<br />la comprensión del lenguaje natural y el análisis de la habilidad para razonar un problema y llegar a conclusiones lógicas. Los sistemas expertos usan los enfoques del razonamiento de la Al para resolver los problemas que les plantean los usuarios<br />de negocios (y otros).<br />Los sistemas expertos son un caso muy especial de un sistema de información, cuyo uso ha sido factible para los negocios a partir de la reciente y amplia disponibilidad<br />de hardware y software tal como las microcomputadoras y sistemas expertos. Un sistema experto (también llamado un sistema basado en conocimiento) captura en forma efectiva y usa, el conocimiento de un experto para resolver un problema particular experimentado en una organización. Observe que a diferencia del DSS, que deja la decisión final al tomador de decisiones, un sistema experto selecciona la mejor solución a un problema o a una clase específica de problemas. Los componentes básicos de un sistema experto son la base de conocimiento, una máquina de inferencia que conecta al usuario con el sistema, procesando consultas por medio de lenguajes tales como SQL (lenguaje de consultas estructurado), y la interfaz de usuario. Los llamados ingenieros de conocimiento capturan la experiencia de los expertos, construyen un sistema de computadora donde incluyen<br />el conocimiento del experto y luego lo implementan. Es totalmente posible que la construcción e implementación de sistemas expertos sea el trabajo futuro de muchos analistas de sistemas.<br />1.5La necesidad del Análisis y Diseño de Sistemas<br />El análisis y diseño de sistemas, tal como es ejecutado por los analistas de sistemas, busca analizar sistemáticamente la entrada de datos o el flujo de datos, el proceso o transformación de los datos, el almacenamiento de datos y la salida de información dentro del contexto de un negocio particular. Además, el diseño y análisis de sistemas es usado para analizar, diseñar e implementar mejoras en el funcionamiento de los negocios que pueden, ser logradas por medio del uso de sistemas de información computarizados.<br />La instalación de un sistema sin la planificación adecuada lleva a grandes frustraciones,<br />y frecuentemente causa que el sistema deje de ser usado. El análisis y diseño de sistemas lleva estructura al análisis y diseño de sistemas de información, un costoso esfuerzo que de otra forma podría haber sido hecho de modo casual. Puede ser visto como una serie de procesos llevados a cabo sistemáticamente para mejorar un negocio por medio del uso de sistemas de información computarizados. Gran parte del análisis y diseño de sistemas involucra el trabajo con los usuarios actuales y eventuales de los sistemas de información.<br />1.6Usuarios finales<br />Cualquiera que interactúe con un sistema de información en el contexto de su trabajo en<br />la organización puede ser llamado un usuario final. A lo largo de los años se han hecho borrosas las distinciones entre usuarios. Además, cualquier categoría de usuarios empleada no debe ser vista como excluyente.<br />Sin importar cómo se hayan clasificado los usuarios finales, un hecho es pertinente al analista de sistemas: el involucramiento del usuario a lo largo del proyecto, es crítico para el desarrollo exitoso de los sistemas de información computarizados. Los analistas<br />de sistemas, cuyos papeles dentro de la organización se tratan a continuación, son el otro componente esencial para el desarrollo de sistemas de información.<br />UNIDAD II<br />CONTENIDO<br />2 .P a p e l e s d e l a n a l i s t a d e s i s t e m a s .<br />2.1. El analista de sistemas como consultor.<br />2.2. El analista de sistemas como especialista de apoyo.<br />2.3. El analista sistemas como agente de cambio.<br />2.4. Cualidades del analista de sistemas.<br />Aspectos Generales<br />El desarrollo de sistemas puede estructurase en forma general mediante dos componentes principales: análisis de sistemas y diseño de sistemas.El diseño de sistemas es el proceso de planeación de un nuevo sistema dentro de la empresa para reemplazar o complementar al existente; pero antes de que esto pueda llevarse a cabo, primero se debe entender por completo el sistema anterior y determinar cómo se puede utilizar la computadora en forma óptima para hacer esta operación en forma más efectiva; por lo tanto, el análisis de sistemas es el proceso que sirve para recopilar e interpretar los hechos, diagnosticar problemas y utilizar estos hechos a fin de mejorar el sistema. En esto consiste el trabajo del analista de sistemas.<br />Orígenes del Analista de Sistemas<br />El origen del analista de sistemas no es del todo claro.No obstante es una convicción firme de quien suscribe que puede rastrearse su origen a la época en que se empezaron a crearse las grandes empresas de capital privado.Debido a la definición misma de analista de sistema entendemos que no reduce a sistemas computacionales solamente, por el contrario sus servicios han sido requeridos por los empresarios en expansión. Más recientemente en la naciente industria del software de los años 60, en que muchos programadores iniciaron sus pasos en el análisis de sistemas de negocios y gerenciales.<br />2.1El analista de sistemas como consultor<br />La consultaría en informática es la revisión y la evaluación de los controles sistemas, procedimientos de informática; de los equipos de cómputo, su utilización, eficiencia y seguridad, de la organización que participan en el procesamiento de la información, a<br />fin de que por medio del señalamiento de cursos alternativos se logre una utilización más eficiente y segura de la información que servirá para una adecuada toma de decisiones.<br />La consultoría en informática deberá comprender no sólo la evaluación de los equipos<br />de cómputo, de un sistema o procedimiento específico, sino que además habrá de<br />evaluar los sistemas de información en general desde sus entradas, procedimientos, controles, archivos, seguridad y obtención de información.<br />La consultoría en informática es de vital importancia para el buen desempeño de los sistemas de información, ya que proporciona los controles necesarios para que los sistemas sean confiables y con un buen nivel de seguridad. Además debe evaluar todo (informática, organización de centros de información, hardware y software).<br />Planeación de la consultoría en informática<br />Para hacer una adecuada planeación de la consultoría en informática, hay que seguir una serie de pasos previos que permitirán dimensionar el tamaño y características de área dentro del organismo a auditar, sus sistemas, organización y equipo.<br />En el caso de la consultoría en informática, la planeación es fundamental, pues habrá que hacerla desde el punto de vista de los dos objetivos:<br />Evaluación de los sistemas y procedimientos.<br />Evaluación de los equipos de cómputo.<br />Para hacer una planeación eficaz, lo primero que se requiere es obtener información general sobre la organización y sobre la función de informática a evaluar. Para ello es preciso hacer una investigación preliminar y algunas entrevistas previas, con base en esto planear el programa de trabajo, el cual deberá incluir tiempo, costo, personal necesario y documentos auxiliares a solicitar o formular durante el desarrollo de la misma.<br />Investigación preliminar<br />Se deberá observar el estado general del área, su situación dentro de la organización, si existe la información solicitada, si es o no necesaria y la fecha de su última actualización.<br />Se debe hacer la investigación preliminar solicitando y revisando la información de cada una de las áreas basándose en los siguientes puntos:<br />Administración<br />Se recopila la información para obtener una visión general del departamento por medio<br />de observaciones, entrevistas preliminares y solicitud de documentos para poder definir<br />el objetivo y alcances del departamento.<br />Para analizar y dimensionar la estructura por auditar se debe solicitar:<br />A nivel del área de informática<br />o Objetivos a corto y largo plazo.<br />o Recursos materiales y técnicos.<br />o Solicitar documentos sobre los equipos, número de ellos, localización y<br />características.<br />o Estudios de viabilidad.<br />o Número de equipos, localización y las características (instalados y por instalar)<br />o Fechas de instalación de los equipos y planes de instalación.<br />o Contratos vigentes de compra, renta y servicio de mantenimiento.<br />o Contratos de seguros.<br />o Convenios que se tienen con otras instalaciones.<br />o Configuración de los equipos y capacidades actuales y máximas.<br />o Planes de expansión.<br />o Ubicación general de los equipos.<br />o Políticas de operación.<br />o Políticas de uso de los equipos.<br />SISTEMAS<br />o Descripción general de los sistemas instalados y de los que estén por instalarse que contengan volúmenes de información.<br />o Manual de formas.<br />o Manual de procedimientos de los sistemas.<br />o Descripción genérica.<br />o Diagramas de entrada, archivos, salida.<br />o Salidas.<br />o Fecha de instalación de los sistemas.<br />o Proyecto de instalación de nuevos sistemas.<br />En el momento de hacer la planeación de la consultoría o bien su realización, debemos evaluar que pueden presentarse las siguientes situaciones.<br />Se solicita la información y se ve que:<br />o No tiene y se necesita.<br />o No se tiene y no se necesita.<br />Se tiene la información pero:<br />o No se usa.<br />o Es incompleta.<br />o No esta actualizada.<br />o No es la adecuada.<br />o Se usa, está actualizada, es la adecuada y está completa.<br />En el caso de No se tiene y no se necesita, se debe evaluar la causa por la que no es necesaria. En el caso de No se tiene pero es necesaria, se debe recomendar que se elabore de acuerdo con las necesidades y con el uso que se le va a dar. En el caso de que<br />se tenga la información pero no se utilice, se debe analizar por que no se usa. En caso de que se tenga la información, se debe analizar si se usa, si está actualizada, si es la adecuada y si está completa.<br />El éxito del análisis crítico depende de las consideraciones siguientes:<br />Estudiar hechos y no opiniones (no se toman en cuenta los rumores ni la información sin fundamento)<br />Investigar las causas, no los efectos.<br />Atender razones, no excusas.<br />No confiar en la memoria, preguntar constantemente.<br />Criticar objetivamente y a fondo todos los informes y los datos recabados.<br />2.2El analista de sistemas como especialista de apoyo.<br />El otro papel que puede protagonizar es el de especialista de apoyo o staff dentro de una empresa, donde de manera regular, trabaje dentro del departamento de sistemas. En esta posición, el analista dispone de una experiencia profesional respecto al hardware y al software y a sus aplicaciones en la empresa. Con frecuencia estas tareas no se asocian a<br />un proyecto ambicioso de sistemas, sino más bien implican decisiones o modificaciones menores que se dan en un departamento individual.<br />Como especialista de apoyo, no dirigirá un proyecto, solo será un recurso humano de apoyo para quienes lo dirigen. Si es un analista de sistemas contratado por una organización de servicioso de manufactura, muchas de sus actividades diarias se ajustarán a este papel.<br />2.3El analista de sistemas como agente de cambio.<br />El papel que mejor se entiende y que le confiere una alta responsabilidad al analista de sistemas, es el de agente de cambio; sin importar si es o no externo a la organización. Como analista, será un agente de cambio cada vez que realice alguna de las actividades<br />del ciclo de desarrollo del sistema del sistema (que se discute en la sección siguiente),<br />las cuales se mantienen presentes en la empresa por un largo periodo (desde dos semanas hasta quizá mas de un año). Un agente de cambio puede definirse como aquella persona que sirve como catalizador para el cambio, que desarrolla un plan para el mismo y que colabora con otros para agilizarlo.<br />Su presencia dentro de la empresa la modifica. Como analista de sistema debe aceptar lo anterior y utilizarlo como el punto de inicio de su análisis. Esto es por lo que tendrá que<br />relacionarse con los usuarios y con la dirección (si ellos no fueran la única y misma<br />persona), desde el principio del proyecto. Sin su colaboración, será incapaz de entender<br />lo que pasa en la organización, y el cambio real no se llevará a cabo.<br />Si el cambio (esto es, los beneficios que la empresa obtiene mediante los sistemas de información) parece quedar garantizado después del análisis, el siguiente paso será desarrollar un plan para tal cambio, en colaboración con las personas que se involucrarán en tales cambios. Una vez que se alcance un consenso para el cambio a realizar, se encontrará en constante relación con aquellos que estén participando del cambio. Facilita el cambio al usar su experiencia en el trato humano y en la computación, para llegar a una integración hombre-maquina en el sistema de información.<br />Como analista de sistemas, al actuar como agente de cambio, apoya una corriente particular de cambio, que involucra el uso de los sistemas de información. Además, transmite a los usuarios el proceso de cambio ya que esta convencido de que tales cambios no ocurren de manera independiente en los sistemas de información, sino mas bien, estos ocasionan cambios a lo largo de las organizaciones.<br />2.4Cualidades del analista de sistemas.<br />De las descripciones precedentes sobre los diferentes papeles que el analista de sistemas tiene que protagonizar, es fácil ver, que el analista de sistemas, con éxito, debe contar con una amplia gama de cualidades. Los analistas de sistemas, son gente de naturaleza muy diversa y seguramente esto, restringe cualquier intento de caracterización; sin embargo hay ciertas características que parecen presentar la mayoría de los analistas de sistemas.<br />Ante todo, el analista es un solucionador de problemas. El o ella es una persona que ve<br />el análisis de los problemas como un reto y que disfruta encontrando soluciones factibles. Cuando es necesario, el analista tiene que ser capaz de abordar de manera sistemática la situación, mediante la aplicación hábil de herramientas, técnicas y experiencia. El analista también debe ser un buen interlocutor, manteniendo una relación cordial con otra gente, durante largos periodos. El analista de sistemas necesita contar con suficiente experiencia en computación para programar, entender las capacidades de las computadoras, recoger las necesidades de información de los usuarios y llegar a transmitir a los programadores lo necesario.<br />El analista de sistemas debe ser autodiciplinado y automotivado como individuo. También el analista debe ser capaz de administrar y coordinar innumerables recursos del proyecto, incluyendo a otras personas. El análisis de sistemas exige demasiado, pero se compensa con la naturaleza cambiante de los problemas, así como por el continuo<br />enfrentamiento al reto.<br />UNIDAD III<br />CONTENIDO<br />3 .E l c i c l o d e d e s a r r o l l o d e l o s s i s t e m a s .<br />3 . 1 . I d e n t i f i c a c i ó n d e p r o b l e m a s , o p o r t u n i d a d e s y o b j e t o s .<br />3 . 2 . D e t e r m i n a c i ó n d e l o s r e q u e r i m i e n t o s d e i n f o r m a c i ó n .<br />3 . 3 . A n á l i s i s d e l a s n e c e s i d a d e s d e l o s s i s t e m a s .<br />3 . 4 . D i s e ñ o d e l s i s t e m a r e c o m e n d a d o .<br />3 . 5 . D e s a r r o l l o y d o c u m e n t a c i ó n d e l s o f t w a r e .<br />3 . 6 . P r u e b a s y m a n t e n i m i e n t o d e l s i s t e m a .<br />3 . 7 . I m p l e m e n t a c i ó n y e v a l u a c i ó n d e l s i s t e m a .<br />Aspectos Generales<br />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 cuidados<br />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.<br />Al establecer los sistemas de información basados en computadoras deben tener la certeza de que se logren dos objetivos principales: que sea un sistema correcto y que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia u organización.<br />Si los dispositivos de un sistema de información no se adaptan a su población de clientes, no lograra sus objetivos potenciales. A mismo tiempo, aun cuando se identifiquen precisamente las necesidades del usuario, un sistema de información va tener un valor único si funciona en forma adecuada.<br />Los informes y las salidas producidas por el sistema deben ser precisos, confiables y completos. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios.<br />Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo<br />al futuro y aceptamos resignados cierto grado de incertidumbre.<br />Aunque la estimación, es más un arte que una Ciencia, es una actividad importante que<br />no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación<br />de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades<br />de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y<br />Software.<br />Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones.<br />A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software. La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.<br />3.1 Identificación de problemas, oportunidades y objetos.<br />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.<br />Factibilidad: Dentro del estudio de factibilidad técnica: si se cuenta con el personal adecuado y capacitado para desarrollar el sistema, además si se tiene la tecnología, equipo, o si se pueden contratar.<br />F. Económica : Si hay dinero ver si el no haber desarrollado el sistema en el futuro sale más caro.<br />Operacional: Realmente se va a utilizar? Hay personas que resisten a ser cambiados.<br />Aprobación: De la solicitud; se estiman costos, tiempos, personal necesario,<br />la administración (generalmente a la lista de proyectos a realizar).<br />3.2 Determinación de los requerimientos del sistema.<br />El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:<br />¿Qué es lo que hace?<br />¿Cómo se hace?<br />¿Con que frecuencia se presenta?<br />¿Qué tan grande es el volumen de transacciones o decisiones?<br />¿Cuál es el grado de eficiencia con el que se efectúan las tareas?<br />¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina? Cuestionarios, entrevistas, observaciones, documentos, formatos manuales para<br />conocer en su totalidad los procesos, en esta fase los analistas identifican características que debe tener el nuevo sistema. Identifica que debe producir el sistema y características operacionales tales como controles de procesamientos, tiempos de respuesta y métodos de entrada y salida.<br />3.3 Análisis de las necesidades de los sistemas.<br />El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta<br />etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.<br />3.4 Diseño del sistema recomendado.<br />Deben producir los detalles, especificar como se van a cumplir los requerimientos;<br />establecer la forma en que el sistema cumplirá con los requerimientos identificados durante la fase del análisis. Los analistas en esta fase:<br />Identifican reportes y demás salidas que debe producir el sistema.<br />Identifican con precisión los datos específicos para cada reporte y salida.<br />Algunas veces realizan bosquejos del formato o pantalla que espera que aparezca<br />(en papel o pantalla).<br />El diseño también:<br />Identifica los datos de entrada<br />Indica los datos que se dan calculados<br />Indica los datos que se dan almacenados<br />Se describen con todo detalle los procedimientos de calculo<br />Se seleccionan las estructuras de archivos<br />Se seleccionan los dispositivos de almacenamiento<br />Nota:<br />Toda la información que contiene los parámetros de diseño se integran en un<br />documento que puede ser presentado de muchas maneras. El documento tiene que<br />ser claro, y así el analista se lo entrega al programador para comenzar la fase del desarrollo del software.<br />3.5 Desarrollo y documentación del software.<br />Los encargados de desarrollar software pueden instalar software comprobando a 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.<br />Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.<br />3.6 Pruebas y mantenimiento del sistema.<br />Durante la 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<br />las especificaciones y en la forma en que los usuarios esperan que lo haga.<br />Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.<br />Se deben tener en cuenta los siguientes factores:<br />Que funciona de acuerdo a las especificaciones<br />La forma en que los usuarios esperan que lo haga. Se alimenta el sistema con datos de entrada para procesarlos y después examinar los resultados. En ocasiones permiten los analistas que los usuarios utilicen el sistema para ver si trata de emplearlo en forma no previstas. En ocasiones la prueba es concluida por personas ajenas al grupo que escribió los programas originales, esto con la finalidad de que el software sea más confiable y que las pruebas sean completas<br />e imparciales.<br />3.7 Implementación y evaluación del sistema<br />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. Una vez instaladas, las aplicaciones se emplean 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.<br />Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. 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:<br />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.<br />Impacto organizacional: Identificación y medición de los beneficios para<br />la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.<br />Opinión del administrador : evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.<br />Desempeño del desarrollo : La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos 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.<br />Pruebas y<br />mantenimiento<br />Desarrollo y doc. del software<br />Diseño del sistema recomendado<br />Análisis de las necesidades de los sistemas<br />Determinación de los requerimientos de información<br />Identificación de problemas, oportunidades y objetos<br />UNIDAD IV<br />CONTENIDO<br />4.Archivos convencionales y bases de datos.<br />4.1. Los Archivos convencionales.<br />4.2. Base de Datos.<br />4.1. Los Archivos convencionales.<br />Los archivos convencionales se pueden usar para almacenar datos por un periodo indefinido.<br />Los archivos temporales se usan almacena datos con un propósito específico. Estos pueden ser:<br />4.1.1 Archivos de transacción : Se usa para hacer cambios que actualiza el archivo maestro y producen informes. Ejemplo: El archivo maestro de un suscriptor de periódico necesita ser actualizado.<br />4.1.2 Archivos de trabajo: Algunas veces un programa se puede ejecutar con mayor eficacia si se usa un archivo de trabajo. Ejemplo: cuando se reordena un archivo para acceder a los registros con mayor rapidez y para cierto tipo de procesos.<br />4.1.3 Archivos de reporte: Cuando se necesita imprimir un informe y no hay ninguna impresora disponible.<br />4.2. Base de Datos.<br />Es una fuente central de datos destinados a compartirse entre muchos usuarios para una diversidad de aplicaciones. El corazón de una base de datos lo constituye<br />el Sistema de Administración de la Base de Datos (DBMS), el cual permite la creación, modificación y actualización de la base de datos, la recuperación de datos y la generación de informes y pantallas. La persona encargada de garantizar que la base de datos cumpla sus objetivos se conoce como administrador de base<br />de datos.<br />Entre los objetivos de efectividad de la base de datos están los siguientes puntos:<br />Asegurar que los datos se puedan compartir entre los usuarios para una diversidad de aplicaciones.<br />Mantener datos que sean exactos y consistentes.<br />Asegurar que todos los datos requeridos por las aplicaciones actuales y futuras se podrán acceder con facilidad.<br />Permitir a la base de datos evolucionar conforme se aumenten las necesidades<br />de los usuarios.<br />Permitir a los usuarios construir su vista personal de los datos sin preocuparse por la forma en que los datos se encuentren almacenados físicamente.<br />La compartición de los datos significa que estos deben almacenarse una sola vez, esto ayuda a lograr la integridad de los datos, debida a que los cambios se realizan con mayor facilidad y confiabilidad si estos aparecen solo una vez en lugar de en muchos archivos diferentes. La salida de una etapa del proceso se convierte en entrada para la siguiente etapa.<br />Cuando un usuario necesita datos específicos, una base de datos bien diseñada anticiparía dicha necesidad. Por lo tanto, es más probable que los datos estén disponibles en una base de datos que en un sistema de archivos convencional. Una base de datos bien diseñada también puede ser más flexible que los archivos separados; es decir, una base de datos puede evolucionar conforme cambien las necesidades de los usuarios y las aplicaciones.<br />El enfoque de una base de datos tiene la ventaja de permitir a los usuarios obtener<br />su propia vista de los datos. Los usuarios no tienen que preocuparse por la estructura real de la base de datos o su almacenamiento físico.<br />UNIDAD V<br />CONTENIDO<br />5.Concepto de datos.<br />5.1. Realidad, datos y metadatos.<br />5.2. Organización de archivos.<br />5.3. Organización de base de datos.<br />5.1. Realidad, datos y metadatos.<br />Al mundo real se le llama realidad. En la realidad, los datos recopilados de personas, lugares o eventos se almacenaran en un archivo o una base de datos.<br />Datos son hechos o sucesos en forma independiente.<br />Para entender la forma y estructura de los datos, se necesita información sobre los datos mismos. A la información que describe los datos se le llama metadatos.<br />Dentro del reino de la realidad hay entidades y atributos;<br />Dentro del reino de los metadatos hay definiciones de registros y definiciones de datos.<br />ENTIDAD: Es cualquier evento u objeto sobre el cual alguien escoge recopilara datos. Ejemplo: una persona, lugar o cosa. Un evento también puede ser una<br />unidad de tiempo.<br />ENTIDADES<br />DATOS<br />METADATOS<br />Entidades<br />Ocurrencias de<br />Registros<br />Definiciones de<br />Registros<br />Atributos<br />Ocurrencias de Datos<br />Definiciones de Datos<br />Hay una unidad menor llamada Subtipo de entidad, su símbolo es un rectángulo más pequeño<br />dentro del rectángulo de la entidad. Un subtipo de entidad es una relación especial uno a uno que representa los atributos adicionales (campos) de otra entidad que podría no estar presente en cada registro de la primera entidad. Los subtipos de entidad eliminan la posibilidad de que una entidad pueda tener campos nulos almacenados en las tablas de la base de datos. Un ejemplo es la entidad principal de un cliente. Los clientes preferidos podrían tener campos especiales que contengan información de descuentos especiales, y esta información estaría en un subtipo de entidad. Otro ejemplo son los estudiantes que tienen periodos de prácticas profesionales. EL ARCHIVO MAESTRO DE ESTUDIANTES no debe contener información sobre los periodos de prácticas profesionales para cada estudiante, debido a que quizá solo un número pequeño de estudiantes tiene dichos periodos.<br />EJEMPLOS DE DIAGRAMA E-R<br />RELACIONES: Son asociaciones entre las entidades. Uno a uno. (1:1). El diagrama anterior muestra que solo hay un paquete de productos para cada producto. Cada empleado tiene una sola oficina. Cada EMPLEADO es miembro de un solo DEPARTAMENTO. Uno a muchos. (1:M). Muchos a uno (M:1). A un MEDICO en<br />un centro de salud, se le asignan muchos PACIENTES. Cada DEPARTAMENTO tiene muchos EMPLEADOS. Muchos a muchos. (M: N). Un ESTUDIANTE podría tener muchosCURSOSperoalmismotiempounCURSOpodríatenermuchos ESTUDIANTES. Un VENDEDOR puede visitar muchas CIUDADES y una CIUDAD puede ser el área de venta para muchos VENDEDORES.<br />En la figura anterior se dan los símbolos estándar para la notación tipo pata de cuervo,<br />la explicación oficial de los símbolos y su significado real.<br />Ejemplo de entidad-relación. Se presenta un diagrama entidad-relación que contiene muchas entidades, muchos tipos diferentes de relaciones y varios atributos. En este diagrama E-R nos enfocamos en un sistema de facturación, y en particular con la parte<br />de la prescripción del sistema. (Por simplicidad, asumimos que las visitas al consultorio<br />se manejan de forma diferente y están fuera del alcance de este sistema)<br />Las entidades son: PRESCRIPCION, MEDIO, PACIENTE y COMPAÑÍA DE SEGUROS. La entidad de TRATAMIENTO no es importante para el sistema de facturación, pero es parte del diagrama E-R porque se usa para establecer una conexión entre la PRESCRIPCION y el PACIENTE. Por lo tanto lo dibujamos como una entidad asociativa.<br />Aquí, un MEDICO trata muchos PACIENTES (1:M), quienes se suscriben por separado<br />a una COMPAÑÍA DE SEGUROS individual. El PACIENTE es solo uno de los muchos pacientes que se suscriben a dicha COMPAÑÍA DE SEGUROS particular (M:1).<br />Para completar los requisitos del MEDICO, el medico necesita guardar la información acercadelostratamientosquetieneunPACIENTE.MuchosPACIENTES experimentan muchos TRATAMIENTOS, lo que se convierte en una relación muchos a muchos (M:N). EL TRATAMIENTO se representa como una entidad asociativa porque<br />noesimportanteennuestrosistemadefacturaciónporsimismo.Los<br />TRATAMIENTOS pueden incluir la toma de PRESCRIPCIONES, y por ellos también<br />es una relación M:N, debido a que muchos tratamientos podrían requerir combinaciones<br />de fármacos y muchos medicamentos podrían funcionar para muchos tratamientos.<br />Los atributos se listan al lado de cada una de las entidades, y la clave se subraya. Por ejemplo,laentidadPRESCRIPCIONtieneunNOMBRE-PRODUCTO, DOSIFICACION, FABRICANTE y CANTIDAD.<br />Atributos. Es una característica de una entidad. Puede haber muchos atributos para cada entidad. Por ejemplo, un paciente (entidad) puede tener muchos atributos como (apellido, nombre, calle, ciudad, estado, etc.). La fecha de la última visita del paciente<br />así como los detalles de la prescripción también son atributos.<br />Registros. Es una colección de datos que tiene algo en común con la entidad descrita.<br />Clases. Es uno de los datos en un registro que se usa para identificar al registro. Cuando una clave identifica de manera única un registro, se llama clave primaria.<br />5.2. Organización de archivos.<br />Un archivo contiene un grupo de registros que proporcionan información para la<br />operación, diseño, administración y toma de decisiones en una organización.<br />Organización secuencial. Cuando los registros están físicamente en orden en<br />un archivo, se dice que este archivo es secuencial.<br />Listas enlazadas. Cuando los archivos se almacenan en dispositivos de acceso directo tal como un disco, las opciones se extienden. Los registros se pueden ordenar lógicamente, en lugar de físicamente, usando listas enlazadas.<br />Organización de un archivo hash. Es el proceso de calcular una dirección a partir de la clave del registro. Los dispositivos de acceso directo también permiten acceso a un registro dado yendo directamente a su dirección. Debido<br />a que no es factible reservar una dirección física para cada registro posible, se usa un método llamado hashing (reordenamiento)<br />Tipos de archivo:<br />Los que se usan para almacenar datos por un periodo indefinido. Ejemplo: Archivos maestros y de tabla.<br />Archivos maestros. Contienen registros para un grupo de entidades.<br />Estos archivos son propensos a tener registros grandes que contienen toda la información sobre una entidad de datos. Cada registro normalmente contiene una clave primaria y varias claves secundarias. Los archivos maestros se encuentran como tablas en una base de datos o como archivos indexados o del tipo indexado-secuencial.<br />Archivos de tabla. Contiene datos usados para calcular más datos o medidas de desempeño. Ejemplo: Una tabla de tasas de correo usadas para determinar los gastos de envío de un paquete.<br />Los que se usan para almacenar datos temporalmente, para un propósito especifico. Pueden ser archivos de:<br />◦Transacción.<br />Se usan para hacer cambios que actualizan el archivo maestro y producen informes. Ejemplo: El archivo maestro de un suscriptor de periódico necesita ser actualizado; el archivo de transacción contendría el numero del suscriptor y un código de transacción tal como E (para extender la suscripción), C para cancelar la suscripción o A para cambiar la dirección.<br />◦De trabajo.<br />Algunas veces un programa se puede ejecutar con mayor eficacia si se usa<br />un archivo de trabajo. Ejemplo: Cuando se reorganiza un archivo para acceder a los registros con mayor rapidez para cierto tipo de procesos.<br />◦De reporte.<br />Cuando se necesita imprimir un informe y no hay ninguna impresora disponible, se usa un archivo de reporte. Enviar la salida a un archivo en lugar de a una impresora se denomina apooling. Después cuando el dispositivo esta listo, el documento se puede imprimir<br />5.3. Organización de base de datos.<br />Se pueden organizar de varias formas.<br />Vistas lógicas y físicas de datos. Una base de datos a diferencia de un archivo, esta diseñada para ser compartida por muchos usuarios. Todos los usuarios ven los datos de formas diferentes. El problema es que diferentes usuarios tienen vistas de usuarios distintas.<br />El analista de sistemas debe examinar estas vistas y debe desarrollar un modelo lógico global de la base de datos. Dicho modelo lógico se debe transformar en el diseño físico correspondiente de la base de datos. El diseño físico describe la forma como se almacenan y relacionan los datos, así como también la forma en que se acceden.<br />Estructurasrelacionalesdedatos.Consisteenunaomástablas bidimensionales, las cuales se denominan relaciones. Las filas representan registros y las columnas contienen atributos.<br />Los tres tipos principales de organización de base de datos son:<br />1.Relacional<br />2.Jerárquica<br />3.Red<br />1- Una base de datos Relacional<br />Es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank<br />Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos.1<br />Características<br />Una base de datos relacional se compone de varias tablas o relaciones.<br />No pueden existir dos tablas con el mismo nombre.<br />Cada tabla es a su vez un conjunto de registros, filas o tuplas.<br />Cada registro representa un objeto del mundo real.<br />Cada una de estos registros consta de varias columnas, campos o atributos.<br />No pueden existir dos columnas con el mismo nombre en una misma tabla.<br />Los valores almacenados en una columna deben ser del mismo tipo de dato.<br />Todas las filas de una misma tabla poseen el mismo número de columnas.<br />No se considera el orden en que se almacenan los registros en las tablas.<br />No se considera el orden en que se almacenan las tablas en la base de datos.<br />La información puede ser recuperada o almacenada por medio de sentencias llamadas «consultas».<br />Relaciones base y derivadas<br />En una base de datos relacional, todos los datos se almacenan y se acceden a ellos por medio de relaciones. Las relaciones que almacenan datos son llamados quot;
relaciones basequot;
y su implementación es llamada quot;
tablaquot;
. Otras relaciones no almacenan datos, pero que son calculadas al aplicar operaciones relacionales. Estas relaciones son llamadas quot;
relaciones derivadasquot;
y su implementación es llamada quot;
vistaquot;
o quot;
consultaquot;
. Las relaciones derivadas son convenientes ya que expresan información de varias relaciones actuando como<br />si fuera una sola.<br />Restricciones<br />Una restricción es una condición que obliga el cumplimiento de ciertas condiciones en la base de datos. Algunas no son determinadas por los usuarios, sino que son inherentemente definidas por el simple hecho de que la base de datos sea relacional. Algunas otras restricciones las puede definir el usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10.<br />Las restricciones proveen un método de implementar reglas en la base de datos. Las restricciones restringen los datos que pueden ser almacenados en las tablas. Usualmente se definen usando expresiones que dan como resultado un valor booleano, indicando si los datos satisfacen la restricción o no.<br />Las restricciones no son parte formal del modelo relacional, pero son incluidas porque juegan el rol de organizar mejor los datos. Las restricciones son muy discutidas junto con los conceptos relacionales.<br />Dominios<br />Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa quot;
todos los valores de este atributo deben de ser elementos del conjunto especificadoquot;
.<br />Distintos tipos de dominios son: enteros, cadenas de texto, fecha, etc...<br />Clave única<br />Cada tabla puede tener uno o más campos cuyos valores identifican de forma única cada registro de dicha tabla, es decir, no pueden existir dos o más registros diferentes cuyos valores en dichos campos sean idénticos. Este conjunto de campos se llama clave única.<br />Pueden existir varias claves únicas en una determinada tabla, y a cada una de éstas suele llamársele candidata a clave primaria.<br />Clave primaria<br />Una clave primaria es una clave única elegida entre todas las candidatas, para especificar los datos que serán relacionados con las demás tablas. La forma de hacer esto es por medio de claves foráneas.<br />Sólo puede existir una clave primaria por tabla y ningún campo de dicha clave puede contener valores NULL.<br />Clave foránea<br />Una clave foránea es una referencia a una clave en otra tabla. Las claves foráneas no necesitan ser claves únicas en la tabla donde están y si a donde están referenciadas.<br />Por ejemplo, el código de departamento puede ser una clave foránea en la tabla<br />de empleados, pero obviamente se permite que haya varios empleados en un mismo departamento, pero existirá solo un departamento.<br />Clave índice<br />Las claves índices surgen con la necesidad de tener un acceso más rápido a los datos. Los índices pueden ser creados con cualquier combinación de campos<br />de una tabla. Las consultas que filtran registros por medio de estos campos, pueden encontrar los registros de forma no secuencial usando la clave índice.<br />Las bases de datos relacionales incluyen múltiples técnicas de ordenamiento, cada una de ellas es óptima para cierta distribución de datos y tamaño de la relación.<br />Los índices generalmente no se consideran parte de la base de datos, pues son<br />un detalle agregado. Sin embargo, las claves índices son desarrolladas por el mismo grupo de programadores que las otras partes de la base de datos.<br />Procedimientos almacenados<br />Un procedimiento almacenado es código ejecutable que se asocia y se almacena con la base de datos. Los procedimientos almacenados usualmente recogen y personalizan operaciones comunes, como insertar un registro dentro<br />de una tabla, recopilar información estadística, o encapsular cálculos complejos. Son frecuentemente usados por un API por seguridad o simplicidad.<br />Los procedimientos almacenados no son parte del modelo relacional, pero todas las implementaciones comerciales los incluyen...<br />Estructura<br />La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o instancia).<br />El esquema es la definición de la estructura de la base de datos y principalmente almacena los siguientes datos:<br />El nombre de cada tabla<br />El nombre de cada campo<br />El tipo de dato de cada campo<br />La tabla a la que pertenece cada campo<br />Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización, el resultado de dicho proceso es un esquema que permite que la base de datos sea usada de manera óptima.<br />Los datos o instancia es el contenido de la base de datos en un momento dado. Es en si, el contenido de todos los registros.<br />Manipulación de la información<br />Para manipular la información utilizamos un lenguaje relacional, actualmente<br />se cuenta con dos lenguajes formales el álgebra relacional y el cálculo<br />relacional. El álgebra relacional permite describir la forma de realizar una consulta, en cambio, el cálculo relacional sólo indica lo que se desea devolver.<br />El lenguaje más común para construir las consultas a bases de datos relacionales es SQL (Structured Query Language), un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.<br />En el modelo relacional los atributos deben estar explícitamente relacionados a<br />un nombre en todas las operaciones, en cambio, el estándar SQL permite usar columnas sin nombre en conjuntos de resultados, como el asterisco taquigráfico (*) como notación de consultas.<br />Al contrario del modelo relacional, el estándar SQL requiere que las columnas tengan un orden definido, lo cual es fácil de implementar en una computadora,<br />ya que la memoria es lineal.<br />Es de notar, sin embargo, que en SQL el orden de las columnas y los registros devueltos en cierto conjunto de resultado nunca está garantizado, a no ser que explícitamente sea especificado por el usuario.<br />Manejadores de base de datos relacionales<br />Existe software exclusivamente dedicado a tratar con bases de datos relacionales. Este software se conoce como SGBD (Sistema de gestión de base<br />de datos relacional) o RDBMS (del inglés Relational database management system).<br />Entre los gestores o manejadores más actuales y populares encontramos: MySQL, PostgreSQL, Oracle y MicrosoftSQL Server.<br />Ventajas y desventajas<br />Ventajas<br />Provee herramientas que garantizan evitar la duplicidad de registros.<br />Garantiza la integridad referencial, así, al eliminar un registro elimina todos los registros relacionados dependientes.<br />Favorece la normalización por ser más comprensible y aplicable.<br />Desventajas<br />Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas de información geográfica.<br />No se manipulan de forma manejable los bloques de texto como tipo de dato.<br />Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo<br />de satisfacer las necesidades de las aplicaciones anteriores y así, complementar pero no sustituir a las bases de datos relacionales. Esto lo dijo el analista en sistemas wilson e.<br />2- Una base de datos Jerárquica<br />Es un tipo de Sistema Gestor de Bases de Datos que, como su nombre indica, almacenan la información en una estructura jerárquica que enlaza los registros<br />en forma de estructura de árbol (similar a un árbol visto al revés), en donde un nodo padre de información puede tener varios nodos hijo.<br />Esta relación jerárquica no es estrictamente obligatoria, de manera que pueden establecerse relaciones entre nodos hermanos. En este caso la estructura en forma de árbol se convierte en una estructura en forma de grafo dirigido. Esta variante se denomina Bases de datos de red.<br />Cómo funcionan<br />A diferencia del modelo relacional, el modelo jerárquico no diferencia una vista lógica de una vista física de la base de datos. De manera que las relaciones entre datos se establecen siempre a nivel físico, es decir, mediante referencia a direcciones físicas del medio de almacenamiento (sectores y pistas).<br />Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo relacional. Cada registro consta de un conjunto de campos, el equivalente a las columnas del modelo relacional. Un conjunto de registros con los mismos campos se denomina fichero (record type, en inglés), el equivalente a las tablas del modelo relacional.<br />El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales. En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda secuencial por todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de un departamento). En las bases de datos jerárquicas no existen índices que faciliten esta tarea. Obsérvese que, a priori, no existen relaciones N:M (de muchos a muchos) en el modelo jerárquico. Salvo que se simulen mediante varias relaciones 1:N. No obstante, esto puede provocar problemas de inconsistencia, ya que el gestor de base de datos no controla estas relaciones. Como ya se ha mencionado, las relaciones<br />se establecen mediante punteros entre registros. Es decir, un registro hijo contiene la dirección física en el medio de almacenamiento de su registro padre. Esto tiene una ventaja fundamental sobre las bases de datos<br />relacionales: el rendimiento. El acceso de un registro a otro es prácticamente inmediato sin necesidad de consultar tablas de correspondencia.<br />Las relaciones jerárquicas entre diferentes tipos de datos pueden hacer que sea muy sencillo responder a determinadas preguntas, pero muy difícil el contestar<br />a otras.<br />Limitaciones del modelo jerárquico<br />A continuación se mencionan los problemas típicos de las bases de datos jerárquicas y que no existen en las bases de datos relacionales. Todos estos problemas derivan del hecho de que el sistema gestor de base de datos no implementa ningún control sobre los propios datos, sino que queda en manos<br />de las aplicaciones garantizar que se cumplen las condiciones invariantes que<br />se requieran (por ejemplo, evitar la duplicidad de registros). Dado que todas las aplicaciones están sujetas a errores y fallos, esto es imposible en la práctica. Además dichas condiciones suelen romperse ex profeso por motivos operativos (generalmente, ajustes debidos a cambios en el negocio) sin evaluarse sus consecuencias.<br />3- Una Base de datos de Red<br />Una base de datos de red es una base de datos conformada por una colección o<br />set de registros, los cuales están conectados entre sí por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional. Un registro es una colección o conjunto de campos (atributos), donde cada uno de los contiene solamente un único valor almacenado, exclusivamente el enlace es la asociación entre dos registros, así que podemos verla como una relación estrictamente binaria. Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca más que la estructura de árbol, porque un nodo hijo en la estructura red puede tener más de un nodo padre. En otras palabras, la restricción de que en un árbol jerárquico cada hijo puede tener sólo un padre, se hace menos severa. Así, la estructura de árbol se puede considerar como un caso especial de la estructura<br />de red.<br />Ejemplo : Para ilustrar la estructura de los registros en una base de datos de red, mostraremos la base de datos alumno – materia, con los siguientes registros (en el Lenguaje de programación Pascal):<br />typealumno = record nombreA: string[30]; control: string[8];<br />esp: string[3]<br />end;<br />typemateria = record clave: string[7] nombreM: string[25] cred: string[2];<br />end;<br />UNIDAD VI<br />CONTENIDO<br />6 .N o r m a l i z a c i ó n .<br />6.1. Los tres pasos de la Normalización.<br />6.2. Ejemplo de Normalización.<br />Aspectos generales.<br />La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica.<br />Ayuda a prevenir errores lógicos en la manipulación de datos.<br />Facilita también agregar nuevas columnas sin romper el esquema actual ni las relaciones.<br />6.1. Los Tres pasos de la Normalización.<br />1.Quitar todos los grupos repetitivos e identificar la clave primaria. Para ellos la relación se debe dividir en dos o más relaciones.<br />2.Asegura que todos los atributos sin clave son totalmente dependientes de la clave primaria.<br />3.Quitacualquierdependenciatransitiva(losatributossinclaveson dependientes de otros atributos sin clave).<br />6.2. Ejemplo de Normalización.<br />Lineamientos para el diseño de relación archivo maestro/base de datos.<br />Se deben tomar en cuenta los siguientes lineamientos:<br />Cada entidad de datos separada debe crear una tabla maestra de base de datos. No combine dos entidades distintas en un solo archivo.<br />Un campo de datos específicos solo debe existir en una tabla maestra. Si un informe o pantalla necesita información de muchas tablas, los índices deben proporcionar la vinculación para obtener los registros necesarios.<br />Cada tabla maestra o relación de la base de datos debe tener programas para<br />Crear, Leer, Actualizar y Eliminar (abreviado CLAE) los registros.<br />Restricciones de Integridad.<br />Son reglas que controlan el cambio y eliminación de registros, y ayuda a mantener<br />los datos en la base de datos exacta. En una base de datos se aplican tres tipos de restricciones de integridad.<br />Integridad de identidad. Son reglas que controlan la composición de reglas principales. La clave primaria no puede tener un valor nulo y si la clave primaria es una clave compuesta, ninguno de los campos de componente en<br />la clave puede tener un valor nulo.<br />Integridad referencial. Controla la naturaleza de los registros en una relación de uno a muchos. Significa que todas la claves externas de la tabla muchos (la tabla hija) debe tener un registro de coincidencia en la tabla padre. Por lo tanto no puede agregar un registro en la tabla muchos Hija) sin<br />un registro de coincidencia en la tabla padre.<br />Integridad de dominio. Se usan para validar los datos, tales como la tabla, limite, rango y otras marcas de validación. Las reglas de integridad de dominio se almacenan en la estructura de base de datos de una o dos formas.<br />UNIDAD VII<br />CONTENIDO<br />7 .U s o d e l a B a s e d e D a t o s<br />7.1. Pasos para la recuperación y presentación de los datos.<br />7.1Pasos en la recuperación y presentación de datos.<br />a.Escoja una relación de la base de datos. b.Una dos relaciones.<br />c.Proyecte las columnas de la relación. d.Seleccione filas de la relación.<br />e.Derive nuevos atributos.<br />f.Indexe o clasifique las filas<br />g.Calcule los totales y medidas de desempeño. h.Presente los datos.<br />El primer y ultimo paso son obligatorios, pero los seis pasos intermedios son opcionales, dependiendo de cómo se usen los datos.<br />DESNORMALIZACION.<br />Es el proceso de tomar el modelo de datos lógicos y transformarlo en un modelo físico que es eficaz para las tareas más comunes. Estas tareas pueden incluir generación de informes, pero también pueden significar consultas más eficaces. Una de las razones de<br />la normalización es organizar los datos para reducir los datos redundantes. Si no se le pide almacenar los datos una y otras vez, puede ahorrar mucho espacio. Dicha organización permite al analista reducir la cantidad necesaria de almacenamiento, algo muy importante cuando el almacenamiento era caro. La desnormalizacion se puede lograr de varias formas diferentes:<br />Podemos tomar una relación de muchos a muchos, tal como el de VENDEDOR Y cliente, la cual comparte las entidades asociativas de VENTAS. Al combinar los atributos de VENDEDOR y VENTAS podemos evitar uno de los procesos de la unión. Esto podría producir una cantidad considerable de duplicidad de datos, pero hace las consultas sobre los modelos de las ventas más eficaces.<br />Evitar la referencia repetida para una tabla de búsqueda. Podría ser más eficaz repetir la misma información, por ejemplo, la ciudad, el estado y el código postal, aun cuando esta información normalmente se puede almacenar solo como un código postal.<br />UNIDAD VIII<br />CONTENIDO<br />8 .D F D – D i a g r a m a d e f l u j o d e d a t o s<br />8.1. Ventajas de un enfoque de flujo de datos.<br />8.2. Convenciones en los diagramas de flujo de datos.<br />8.3. Un ejemplo de diagrama de flujo de datos.<br />8.4. Desarrollo de diagrama de flujo de datos.<br />8.5. Uso de los diagramas de flujo de datos.<br />Aspectos generales. Modelación de procesos<br />Es la elaboración de un diagrama que representa todo el sistema o proceso a estudiar. Es una parte del análisis de sistemas que facilita la comprensión de todos los procesos de un sistema<br />en estudio.<br />Diagramas de flujo de datos (DFD)<br />Es la representación gráfica de la secuencia de pasos que se realizan para obtener un cierto resultado. Este puede ser un producto, un servicio o la combinación de ambos.<br />El DFD lógico que es el que se enfoca en el negocio y en la manera en que opera el negocio.<br />En este diagrama no importa la manera que en el sistema va a ser realizado o construido. Es por esto que solo describe los eventos del negocio que suceden y los datos requerido y producidos por cada evento. Tiene ciertas ventajas como es que puede existir mejor comunicación con los usuarios, sistemas más estables, que el analista comprenda mejor el<br />funcionamiento del negocio.<br />El DFD físico es todo lo contrario, en este diagrama se muestra como va a ser realizado el sistema incluyendo tanto el hardware como el software del sistema. La utilización de los diagramas de flujos de datos físicos también tiene algunas ventajas como son el de calificar<br />los tipos de procesos, describen procesos a mayor detalle, identifican almacenamientos de datos temporales, añaden controles para asegurar que los procesos son realizados<br />adecuadamente.<br />8.1Ventajas de un enfoque de flujo de datos.<br />El uso de los diagramas de flujo de datos da ciertas ventajas como pueden ser las<br />siguientes:<br />a. Libertad para realizar en forma temprana la implementación técnica de un sistema.<br />b. Mejor comprensión entre las interrelaciones de los sistemas y los subsistemas.<br />c. Comunicación del conocimiento del sistema actual a los usuarios por medio de diagramas de flujos de datos.<br />d. Análisis de un sistema propuesto para determinar si han sido definidos los datos y los procesos necesarios.<br />8.2Convenciones en los diagramas de flujo de datos.<br />Los diagramas de flujos de datos utilizan cuatro símbolos básicos como los son un cuadrado doble para representar las entidades del sistema, una flecha para representar<br />los flujos dentro del sistema, un rectángulo con esquinas redondas para representar los<br />procesos y un rectángulo con un lado abierto para representar los almacenamientos de datos.<br />Procesos: Es el símbolo principal de un DFD, Son unconjunto de tareas o acciones realizadas a partir de un flujo de datos de entrada para producir flujos de datos de salida. Losprocesospuedenserrealizadosporpersonas, departamentos, máquinas u ordenadores.Flujo de datos: Es la parte del DFD que representa la entraday/o salida de datos para un proceso. Se representa con una flecha y puede ser la actualización de datos en cualquier medio de almacenamiento.Agentes internos y externos: son las partes que definen loslímites de un sistema, se encargan de suministrar entradas y recibir salidas de un sistema. También son denominados entidad.Almacén de Datos: es la parte del DFD que representaBases de Datos o archivos de almacenamiento.<br />635986155000<br />10909302273300010160718820008.3Ejemplo de diagrama de flujos.<br />El diagrama de flujo de datos proporciona una visión global de los componentes funcionales<br />del sistema, pero no da detalles de estos. Para mostrar detalles acerca de que información se transforma y como se transforma, se ocupan dos herramientas textuales de modelado adicionales: el Diccionario de Datos y la Especificación de Procesos.<br />635986155000<br />10909302273300010160718820008.4Desarrollo de un diagrama de flujos.<br />Al final de la elaboración se deben conservar únicamente los procesos que:<br />oRealicen cálculos, como por ejemplo el cálculo promedio de calificaciones.<br />oTomen decisiones, como por ejemplo decidir la aprobación de una beca a un<br />estudiante según diversas reglas.<br />oDividan los flujos de datos según su contenido o las reglas de la empresa, como por ejemplo separar los pedidos aprobados de los rechazados en función de las reglas<br />de gestión de la concesión de crédito.<br />oCombinen los flujos de gestión de datos, como por ejemplo: combinar los cursos requeridos con los cursos disponibles para crear la planificación de cursos de un estudiante.<br />oFiltren y/o resuman los flujos de datos para producir nuevos flujos de datos, como por ejemplo: filtrar los datos de facturación para identificar solo las cuentas no pagadas o resumir los datos de inscripción a cursos para identificar los cursos de mayor demanda (en ambos casos los datos no cambian pero si su estructura).<br />Existen algunos errores frecuentes en la creación de DFD´s, ellos son:<br />oAgujero Negro: Se caracterizan porque son procesos que tienen entradas perono tienen salidas.oEl Milagro: Es aquel que tiene salidas pero que no tiene entradas.oAgujero Gris: Cuando las entradas no son suficientes para las salidas que<br />presenta el proceso.<br />635986155000<br />Actividades a tener en cuenta a la hora de realizar un DFD<br />a)Eliminación de procesos de canalización: significa que los procesos que no cambian los flujos o no sirven para tomar decisiones a partir de los datos de entrada deben ser eliminados. Ello suprime también nombres duplicados de los flujos de datos.<br />b)El concepto de paquete de flujo de datos: cuando hay dos o más flujos de datos independientes que se desplazan siempre juntos, se deben mostrar como un único flujo de datos.<br />635986155000<br />c)Flujos de datos divergentes: son flujos basados en criterios de implantación y deberían evitarse en los DFD esenciales.<br />Sustitúyanse dichos flujos divergentes por un flujo de datos único, independiente y con nombre.<br />d)Evitar la creación de flujos de datos incorrectos tales como:<br />- Todos los flujos de datos deben empezar y/o terminar en un proceso.<br />- Los diagramas de la izquierda violan esta regla.<br />- Los de la derecha corrigen estos errores<br />NOTA:<br />Un flujo de datos sólo es correcto cuando todos los flujos de datos empiezan y/o terminan en un proceso.<br />Incluir ejemplo gráfico<br />635986155000<br />1090930227330001016071882000<br />UNIDAD IX<br />CONTENIDO<br />9 .E l d i c c i o n a r i o d e d a t o s<br />9.1. La necesidad de comprender el diccionario de datos.<br />9.2. Datos que contiene el diccionario de datos.<br />9.3. Elaboración del diccionario de datos.<br />Aspectos generales.<br />Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas<br />de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.<br />9.1La necesidad de comprender el diccionario de datos.<br />El diccionario de datos se desarrolla durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto.<br />Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.<br />En un diccionario de datos se encuentra la lista de todos los elementos que forman parte<br />del flujo de datos de todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción<br />de todos estos elementos.<br />Significado<br />=: Esta compuesto<br />+: Y<br />(): Optativo<br />{}: Iteración<br />[]: Selección<br />@: Identificación de clase<br />|: Separador, opción<br />635986155000<br />9.2Datos que contiene el diccionario de datos 9.3 Elaboración del diccionario de datos<br />1. Datos elementales<br />Son aquellos para los cuales no hay una descomposición significativa. Por ejemplo,<br />puede ser que no se requiera descomponer el nombre de una persona en primer- nombre, apellido-materno y apellido-paterno; esto depende del contexto del sistema que se esté modelando. Cuando se han identificado los datos elementales, deben ser introducidos en el DD y proveer una breve descripción que describa el significado del dato. En el caso de que el dato tenga un nombre significativo, se puede omitir la descripción, sin embargo; es importante especificar las unidades de medida que el<br />dato puede tomar.<br />Ejemplo:<br />Peso = * peso del paciente al ingresar al hospital *<br />Unidad: kilo, rango: 2-150 *<br />Altura = * unidad: cm, rango: 100-200 * Sexo = * valores : [F|M] * APGR Ingeniería de Software I Análisis Estructurado 24<br />2. Datos opcionales<br />Un dato opcional es aquel que puede o no estar presente como componente de un<br />dato compuesto.<br />Ejemplo:<br />Dirección = calle + número + (ciudad) + (país) + (código-postal)<br />3. Selección<br />Indica que un elemento consiste de exactamente una opción de un conjunto de<br />alternativas.<br />Ejemplos:<br />Sexo= [ Femenino | Masculino ]<br />Tipo-de-cliente= [ Gubernamental | Académico | Industria | Otros ]<br />4. Iteración<br />Se usa para indicar ocurrencias repetidas de un componente en un elemento<br />compuesto.<br />Ejemplo: Orden-de compra = nombre-cliente + dirección-de-envío + {artículo} significa que una orden de compra siempre debe contener un nombre de cliente, una dirección de envío y cero o más ocurrencias de un artículo.<br />Ejemplo:<br />Se pueden especificar límites superiores e inferiores a las iteraciones.<br />Orden-de compra = nombre-cliente + dirección-de-envío + 1{artículo}10 significa que una orden de compra siempre debe contener un nombre de cliente, una dirección<br />de envío y de 1 a 10 artículos.<br />Ejemplos de iteraciones con límites:<br />a = 1{b}<br />a = {b}10<br />a = 1{b}10<br />a = {b}<br />635986155000<br />1090930227330001016071882000<br />UNIDAD X<br />CONTENIDO<br />1 0 .M e t o d o l o g í a p a r a e l d e s a r r o l l o y m a n t e n i m i e n t o d e s i s t e m a s .<br />Aspectos generales.<br />A lo largo de este texto, buscamos mostrar que toda actividad debe estar basada en una metodología y en principio, cualquier metodología es mejor que ninguna; Cualquier centro de desarrollo puede montar su metodología, aunque esta alternativa implica disponer del tiempo necesario para el desarrollo de la nueva metodología; por lo tanto, lo más práctico es seguir<br />los métodos que ya han demostrado su validez y son de aplicación universal; sepa utilizar el conocimiento científico, que involucra tanto esfuerzo y sacrificio.<br />Todas las metodologías; MERISE, YOURDON Y SSADM (Structured Sydtem Analysis Design Method ) y tantas otras, consideran el hecho informático dividido en fases, cuyo conjunto forma el ciclo de vida de un sistema informático.<br />Todas tienen en común la idea de descomposición del hecho informático en cuatro grandes grupos<br />1) Análisis<br />a) Definición del problema<br />b) Estudio de la situación actual c) Requisitos a considerar<br />d) Estudio de factibilidad<br />2) Diseño lógico<br />a) Análisis funcional<br />b) Definición de datos y procesos c) Modelación<br />3) Diseño físico<br />a) Creación de ficheros y tablas<br />b) Elaboración de programas<br />4) Implementación y control a) Formación del usuario b) Implantación del sistema c) Explotación del sistema<br />d) Mantenimiento<br />Esta metodología la podrá encontrar en un amplio universo bibliográfico, nosotros nos concentraremos, como lo describimos en la introducción de la obra en las metodologías simplificadas.<br />635986155000<br />