Unidades 1 y 2 AUDITORÍA DE SISTEMAS by Lupita Pérez

UNIVERSIDAD PRIVADA DEL ESTADO DE MÉXICO CAMPUS TECAMAC

PÉREZ ESPINOZA MARÍA GUADALUPE MAT.: 111160121

AUDITORÍA DE SISTEMAS

INTRODUCCIÓN Y CARACTERÍSTICAS TÉCNICAS DE ANÁLISIS ESTRUCTURADO PARA EL MEJORAMIENTO DE LA CALIDAD EN EL DISEÑO DE SISTEMAS DE INFORMACIÓN

FECHA: 06 DE SEPTIEMBRE DEL 2013

¿Por qué fallan los sistemas de información? 1 La gran cantidad de proyectos cancelados todos los años nos dice que algo funciona muy mal en la ingeniería informática. ¿Qué es? Según una encuesta del 2004, el 71 por ciento de los proyectos de sistemas terminan fracasando. ¿Cuál es el problema con el IT y cómo resolverlo? En 1985 un grupo de profesionales de West Yarmouth, Massachussets creó el Standish Group con una visión: obtener información de los proyectos fallidos de IT. El objetivo: encontrar (y combatir) las causas de los fracasos. Con el tiempo, la seriedad y el profesionalismo del Standish Group lo convirtieron en un referente mundial sobre los factores que inciden en el éxito o fracaso de los proyectos de IT. Sus análisis apuntan fundamentalmente a los proyectos de software y se aplican tanto a los desarrollos como a la implementación de paquetes (SAP, Oracle, Microsoft, etc.) A lo largo del tiempo, el Standish Group relevó 50.000 proyectos fallidos. Así, sus conclusiones nos brindan interesantes pistas sobre dónde poner el foco para mejorarlos. Veamos lo que ocurrió en la última década... En 1994, el 31 por ciento de los proyectos fueron cancelados. El 53 por ciento registró enormes desvíos en presupuesto y en cronograma. Sólo el 16 por ciento se completó en tiempo y dentro de los costos presupuestados (apenas nueve por ciento en el caso de grandes empresas). Para colmo, de la funcionalidad comprometida sólo se cumplió, en promedio, con el 61 por ciento (42 por ciento en grandes empresas).

En vista de estos fracasos, durante los últimos diez años, la industria invirtió varios miles de millones de dólares en el desarrollo y perfeccionamiento de metodologías y tecnologías 1 http://http-peru.blogspot.mx/2008/03/porqu-fallan-los-proyectos-informticos.html consultada el 02 de septiembre del 2013

3 (CMMI, ITIL, SOA, etc.) destinadas a mejorar la administración y productividad de los proyectos de software. ¿Sirvieron estas inversiones? Veamos los resultados de la encuesta del 2004...

La buena noticia: los proyectos exitosos crecieron al 29 por ciento. La mala noticia: los proyectos fracasados representan el 71 por ciento. ¿No es aterrador? Siete de cada diez proyectos se cancelaron o registraron desvíos del 45 por ciento sobre lo presupuestado en costos y del 63 por ciento de lo previsto en tiempos. Por otro lado, apenas se cumplió con el 67 por ciento de la funcionalidad comprometida. Según el informe de Standish las diez principales causas de los fracasos son las siguientes (por orden de importancia): 1) Escasa participación de los usuarios finales (12,8%): El usuario es quien finalmente evaluará y aprobará o desaprobará el proyecto terminado. Por eso siempre se debe siempre de involucrar al usuario en la definición del proyecto y en los subsiguientes pasos. Se deben establecer canales y vías de comunicación constante con el usuario para poder brindarle la mayor información posible del avance del proyecto, para que éste pueda valorarlo y dar su feedback, que es la base para hacer los reajustes sin algo no estuviese del todo bien. 2) Requerimientos y especificaciones incompletas (12,3%): La ingeniería de requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas. La ambigüedad ayuda a generar falsas expectativas y provoca enormes pérdidas de tiempo cuando lo que se implementa es la solución equivocada.

3) Cambios frecuentes en los requerimientos y especificaciones (11,8%): Durante el proceso de construcción de un sistema de información es común encontrarse con usuarios ávidos en añadirles nuevas funcionalidades o características al mismo. Esto se constituye en un factor peligroso ya que el equipo de desarrollo podría perder días, semanas y hasta meses valiosos haciendo algo que al usuario inicialmente no especificó. Los requerimientos de los usuarios tienen contienen generalmente muchas ambigüedades, malos entendidos, inconsistencias y omisiones. 4) Falta de soporte ejecutivo (7,5%): Todo proceso de cambio tecnológico genera cierto grado de oposición en las organizaciones. En este sentido los funcionarios de mayor rango

5 deben estar comprometidos con este proceso y este compromiso debe ser transmitido a los demás miembros de la organización.

5) Incompetencia tecnológica (7,0%): La incompetencia tecnológica proviene de la resistencia, psicológica o cultural, de los usuarios para modernizar sus procedimientos de trabajo, roles y obligaciones organizacionales. 6) Falta o recorte de recursos (6,4%): La asignación de recursos humanos y materiales suele ser, en la práctica, uno de los aspectos que más complicaciones produce en un proyecto. La definición y asignación de recursos implica de hecho prever tres elementos: •Qué tipo de recursos se van a usar • En qué cantidad • Durante cuánto tiempo La mayoría de proyectos grandes que fracasan lo hacen porque se reducen sutilmente todos los recursos necesarios para llevarlos a cabo. Cualquier albañil sabe que hay una proporción correcta entre cal y cemento y que no se puede quitar un 5% de hierro a un edificio porque los precios del acero se hayan disparado. En informática, en cambio, es normal contratar un profesional de 3 años en experiencia en el puesto de uno de 5. No importa convertir 9 meses en 8 o US$100.000 del presupuesto en US$90.000. Se van metiendo pequeños recortes por todas partes, un poco de cada lado hasta que se arruina cualquier posibilidad de éxito

7) Expectativas no realistas (5,9%): Comparta toda la información posible con sus clientes, evitando el uso de la jerga técnica, y ayude a los clientes en la descripción de sus necesidades. Aclare las percepciones de sus clientes y explicite las limitaciones de manera frontal y honesta. 8) Objetivos poco claros (5,3%): Un principio básico en la gestión de proyectos es que los objetivos estén definidos a priori y con un grado de suficiente de claridad y precisión. Los objetivos generalmente son: el resultado, el costo y el plazo del proyecto. Estos tres objetivos son inseparables y forman un sistema en el que cada modificación de cada una de las partes afecta a las restantes. Dado que la maximización individual de los tres criterios básicos no es posible, es necesario maximizar una cierta combinación entre ellos. 9) Cronogramas irreales (4,3%): Se deben estimar plazos realistas para cada una de las etapas del proyecto teniendo en cuenta los recursos disponibles. Es frecuente que los plazos se definan sin criterios técnicos 10) Nuevas tecnologías (3,7%): Observemos que de los diez factores mencionados, siete están referidos a factores humanos (1 a 4 y 7 a 9). Si bien algunas de las metodologías cubren temas de comunicación, manejo de conflictos y negociación, en su abordaje se pone mucho más énfasis en los elementos hard (duros) que en los suaves (soft). Así, muchas metodologías

7 cometen el error de prestigiar el contenido procedimental por encima del conceptual. Es decir, se apunta más al COMO que al QUE. En este marco, para incrementar los resultados de los proyectos de IT, es fundamental reformar la educación en sistemas, adoptando un enfoque original y desafiante que comprenda no sólo la difusión de metodologías, técnicas y experiencias sino también el replanteo de varios paradigmas incorporando nuevos marcos conceptuales.

Definición de calidad en los sistemas de información 2 Empezaremos por definir solo la palabra calidad: ¿Qué es Calidad? Calidad tiene muchas definiciones, pero la básica es aquella que dice que aquel producto o servicio que nosotros adquiramos satisfaga nuestras expectativas sobradamente. La ISO 9000, 14000 y 18000, la define como: “la capacidad de los procesos de servicios que incrementan su valor al desarrollar la servucción (proceso de elaboración de un servicio) en equilibrio y con clima adecuado de forma competitiva para satisfacer necesidades, deseos y/o expectativas de los clientes sin efectos negativos para el medio ambiente y que contribuyen a la elevación de su nivel de vida”. Ahora que es un sistema: Conjunto de partes o elementos organizadas y relacionadas que interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos, energía o materia del ambiente y proveen (salida) información, energía o materia. ¿Qué es un sistema de información? Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. El equipo computacional: el hardware necesario para que el sistema de información pueda operar. El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema. Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información. Sistema de Información de la Calidad (SIC): Es un método organizado para recolectar, almacenar y reportar la información sobre la calidad para ayudar a los tomadores de decisiones en todos los niveles. 2 http://www.monografias.com/trabajos89/calidad-y-sistemas-informacion/calidad-y-sistemas-informacion.shtml consultada el 3 de septiembre del 2013

8 Manipulación o proceso de los datos: para transformarlos en información útil para los usuarios aplicando los procedimientos más apropiados diseñados por los constructores del sistema de información. Funciones de los SIC Recogida de datos: o captura de la información que han de procesar, almacenar y distribuir, para lo cual han de conectar con la fuente de suministro de forma estable y fiable. Evaluación de la calidad y relevancia de los datos: Es decir, filtran la información recogida evitando los errores, las redundancias, las pérdidas, y contrastando la validez de la fuente utilizada. Presentación: De la información al usuario con el formato más apropiado para su utilización. Funciones de los SIC Almacenamiento: Garantizando la seguridad, la disponibilidad y la calidad de la información hasta el momento en que es requerida por el usuario. Distribución: O transporte de la información que precisa el usuario, cumpliendo los requisitos de lugar y tiempo que aquel requiera. Soportes; o conjunto de instrumentos en que se materializa el sistema de información, y que facilitan el desempeño de las funciones mencionadas anteriormente. Elementos de los SIC Información; en el sentido más amplio del término, es decir, datos, imágenes y sonido, de forma aislada o en combinación. Sin este elemento el sistema de información no tiene razón de ser. Usuario/s; que pueden ser de la propia organización como ajenos a ellas. Además no se debe olvidar que estos usuarios son a su vez, elementos de otros sistemas de información (por ejemplo: el empleado del departamento de venta de un proveedor). Difusores; que son los elementos dedicados al transporte de la información desde los almacenes al lugar en que la precisa el usuario. Elementos de los SIC Sensores; que captan la información lo más cerca del origen, llegando a evaluar su calidad y grado de relevancia por el sistema. Portadores; que son quienes muestran la información al usuario (el papel de un informe, la pantalla en la que se consulta determinada información.). Almacenes; donde se mantiene la información, ya procesada o en forma bruta, hasta que es requerida por el usuario. La entrada para un SIC incluye: Información de investigación de mercado sobre la Calidad Datos de pruebas del diseño del producto Información sobre la evaluación del diseño para la Calidad Información sobre partes y materiales comprados Datos de proceso Datos de inspección final Resultados de la medición de la calidad.

9 Planeación de un Sistema de Información Basado en Computadora Comienza con el análisis de las necesidades del cliente, la creación de una especificación del diseño para sistema y la preparación de una propuesta indicando los costos y el tiempo requerido. Cuando la administración aprueba la propuesta, se desarrolla el Sistema, se aprueba y se implementa. Por último, se toma en cuenta la revisión del desempeño del sistema. Un sistema debe estar hecho a la medida para cumplir con las necesidades de los clientes de una organización. Planear el sistema para recibir la información en casi cualquier forma imaginaria. Aunque la mayor parte de la información se recibirá en formas especiales, el sistema debe hacer posible que se reciba y procese a través de una llamada telefónica, cartas u otro medio. Prevenir la flexibilidad para cumplir con las necesidades de nuevos datos. Un ejemplo fundamental es la forma de reporte de fallas, que debe de revisarse de manera periódica por que se descubre una necesidad crítica de un elemento adicional de información que debe guardarse. Prevenir la recolección de datos en tres etapas: a) Tiempo real (Continua) b) Reciente (Minutos a horas) c) Histórica (Tiempo extenso) Prevenir la eliminación de la recolección de datos ya que no es útil al igual que los informes que ya no son necesarios. Esto requiere una auditoria periódica del uso de datos y reportes. Emitir reportes que sean legibles, se entreguen a tiempo y contengan suficientes detalles útiles sobre problemas actuales para facilitar las investigaciones y acciones correctivas. Preparar resúmenes que abarquen largos periodos para destacar áreas potencialmente problemáticas, y mostrar el progreso sobre los problemas conocidos. Mantener un registro de costos de recolección, procesamiento y reportes de la información. El software, es la colección de programas, procedimientos y documentación asociada de computadora, necesaria para la operación del sistema de información.

10 Ejemplo de un Sistema de Informaci贸n de Calidad de una Empresa de Ciudad Guayana:

Sistema de Informaci贸n de Calidad mostrado a trav茅s de un Site

Detalle porcentual que permite verificar la Producci贸n en una L铆nea Determinada.

Gr谩fico que permite controlar la producci贸n de un determinado producto

Detalle del an谩lisis de la curva de Control de la Producci贸n

Re portes de un Sistema de Informaci贸n de Calidad

Control de Material Retenido por L铆neas de Producci贸n

Control de Reclamos de Clientes

Control de Quejas de Clientes

Modularidad de un Sistema de Informaci贸n de Calidad

Medici贸n del Grado de Cumplimiento a Cliente

Auditor铆a de los Sistemas de Informaci贸n de Calidad

Medici贸n comercializaci贸n por Mercado

Reporte de áreas críticas.

Control de Calidad en Laboratorios

TÉCNICAS DE INGENIERÍA DE CALIDAD •

Investigar: para lo cual se requiere buscar nuevos conocimientos y técnicas en forma permanente.

•

Desarrollar: significa emplear nuevos conocimientos y técnicas en el desarrollo de sus actividades o funciones.

•

Diseñar: convertir las ideas de los proyectos en elemento factibles de ser útiles en la solución de los problemas que dio origen al proyecto, para lo cual finalmente se debe especificar las soluciones.

•

Producir: requiere la transformación de materias primas en productos, para lo cual se debe planificar los procesos y los parámetros bajo los cuales deben ser ejecutados.

•

Construir: propiamente es la fase más importante ya que significa llevar a la realidad la solución aprobada en el diseño a la realidad.

•

Operar: es el proceso de manutención y administración para optimizar productividad de la solución adoptada.

24 •

Vender: es parte inherente a todo ingeniero, ya que requiere ofrecer servicios, herramientas y productos, para lo cual se requiere el dominio de las relaciones humanas y otras cualidades propias de esta labor.

•

Administrar: significa participar en solución de problemas para lo cual se deben combinar los recursos, bajo la mejor receta posible.

Para verificar el cumplimiento del alcance se debe actuar bajo dos aspectos: a. Alcance del producto, se mide contra sus requerimientos mientras. b. Alcance del proyecto, se mide contra el plan de gestión del alcance Ambos tipos de administración de alcance deben estar bien integrados para asegurar que el trabajo del proyecto resultará en la entrega del producto especificado.

Necesidades de competencias  Competencias técnicas: Diseño, evaluación de proyectos, desarrollo, cálculo de sistemas, dirección de operaciones, desarrollo, cálculo de sistemas, dirección de operaciones, optimización, etc. (Dependen de cada especialidad).  Autoaprendizaje: Capacidad de mantenerse actualizado(a) y de desarrollar las capacidades y atributos que el entorno laboral demanda.  Ética profesional: Capacidad de identificar, analizar y resolver problemas de ética profesional.  Comunicación: Capacidad de informar, de recibir información y de persuadir.  Trabajo en equipo: Capacidad de asumir responsabilidades en trabajo grupal con un fin común.  Innovación: Capacidad de proponer y desarrollar nuevas y mejores formas de realizar tareas profesionales.  Emprendimiento: Capacidad de desarrollar iniciativas de carácter económico, social y/o cultural, a través de realización de proyectos, que requieren de toma de decisiones, asumir riesgos y de liderazgo.

Modelos aplicados a los proyectos en ingeniería: Es necesario definir5 ciertas reglas para dirigir equipos de proyectos y los contingentes de trabajo que fueron tomadas en cuenta por aquellas empresas que están haciendo la diferencia, las que están trabajando en proyectos y utilizando contingentes de trabajo para producir cambios tecnológicos y enfrentar las exigencias de los mercados competitivos. Las reglas son diez y fueron desarrolladas y perfeccionadas a través del tiempo con un marcado éxito: a. Fije una meta clara b. Precise los objetivos. c. Establezca puntos de control, actividades, relaciones y estimaciones de Tiempo. d. Ilustre gráficamente el programa de trabajo. e. Capacite a las personas, individualmente y como equipo. f. Refuerce el compromiso y el entusiasmo del personal g. Informe a las personas relacionadas con el proyecto. h. Estimule al personal estableciendo acuerdos. i. Aumente el poder, tanto el suyo como el de los demás. j. Atrévase a acercarse con creatividad a los problemas. La norma técnica es elaborada exclusivamente bajo el consenso de las partes interesadas (productores, consumidores y técnicos), donde destacan:  Los fabricantes, a través de sus organizaciones sectoriales y en su condición de Empresa.  Los usuarios y consumidores, a través de sus organizaciones y a título personal.  La administración pública, velando el bien público y los intereses de los ciudadanos.  Los centros de investigación y laboratorios, aportando su experiencia y dictamen técnico.  Los profesionales, a través de asociaciones y colegios profesionales o empresas.  Expertos en el tema que se normalice, nombrados a título personal.

26 Estos agentes acuerdan sobre las características técnicas que deberá reunir un producto, servicio o proceso. La NT se diferencia por su lugar de aplicación, teniendo normas nacionales (como las aprobadas por el INDECOPI), regionales (aprobadas por la Comunidad Andina de Naciones) e Internacionales (como las certificaciones ISO). Campos de la normalización técnica Entre los procesos, prácticas, métodos, técnicas, sistemas, procedimientos y productos que son susceptibles de ser normalizados a través de normas técnicas de carácter obligatorio, se encuentran aquellas actividades (y sus resultados): a. De las que depende directamente la vida y la salud de las personas; por ejemplo: la producción, conservación, manejo y consumo de alimentos y bebidas (naturales y procesados); el cuidado, conservación, manejo, tratamiento, distribución y uso del agua; la producción, aplicación y uso de medicamentos; las prácticas de salud y sanidad; los procesos de emisión intencional y no intencional de sólidos, líquidos y gases contaminantes de los cuerpos de agua, de la atmósfera, de la biosfera y, en general, del medio ambiente en el que viven las personas y los demás seres vivos; los procesos de emisión intencional y no intencional de radiaciones ionizantes y no ionizantes; las condiciones de protección y seguridad de la vida y la salud de las personas en el medio ambiente general y laboral; la producción, distribución, manejo, transporte, conservación y uso de recursos energéticos; el manejo, transporte y confinamiento de materiales y residuos industriales peligrosos y de sustancias radioactivas; etc. b. De las que depende indirectamente la vida y la salud de las personas; por ejemplo: la protección y la salud de la vida animal y vegetal; el cuidado, protección y preservación de los recursos naturales y los ecosistemas; la protección y cuidado de las vías generales de comunicación; las condiciones de salud, seguridad e higiene en los centros de trabajo, en los centros públicos de reunión, en las viviendas y en las demás obras e instalaciones en las que realizan sus actividades las personas; la información comercial, sanitaria, ecológica, de calidad, seguridad e higiene sobre los productos y servicios; etc.

27 c. Aún cuando no ponen en riesgo la vida y la salud de las personas de manera directa o indirecta, tienen impacto importante en los intereses de los usuarios y consumidores, como por ejemplo: exactitud, precisión y certidumbre en las mediciones de cualquier tipo; la determinación de la información comercial, sanitaria, ecológica, de calidad, de seguridad, de higiene y los requisitos que deben cumplir etiquetas de envases, embalajes y publicidad para dar información al consumidor, así como ciertas prácticas comerciales. Entre los procesos, prácticas, métodos, técnicas, sistemas, procedimientos y productos que son susceptibles de ser normalizados a través de normas técnicas de carácter voluntario se encuentran: a. Aquellas actividades (y sus resultados) relacionados con calidad, funcionalidad, efectividad, capacidad, durabilidad, resistencia, exactitud, conformidad, conveniencia, concordancia, etc. b. La evolución de las actividades económicas hacia procesos de normalización es innegable, y resulta imprescindible para asegurar que los diversos sectores productivos alcancen el nivel de competitividad y eficiencia que exige el nuevo entorno comercial internacional. Así, las normas técnicas surgen como una respuesta a los requerimientos de la sociedad, que apuntan hacia aspectos fundamentales del bienestar de la población. Por esta razón, para su elaboración se necesita de la participación multidisciplinaria de expertos, que garantice la conjunción de dichos requerimientos con los resultados de la investigación científica y tecnológica, así como de la experiencia y acervo en materia de normalización. Las normas técnicas que aplican a los proyectos de ingeniería tienen que ver con la aplicación de su alcance en el llamado ciclo de vida de los proyectos de ingeniería. Los profesionales que tengan algún proyecto bajo su responsabilidad deberán ubicarse adecuadamente para identificar su rol dentro de los proyectos, según lo cual podrán identificar la necesidad de códigos o normas. Es responsabilidad de los profesionales identificar adecuadamente los estándares aplicables, y particularmente desarrollar el ¿Cómo cumplirlos? En la documentación de los proyectos, es decir, que en las especificaciones técnicas, planos deberán dejar claramente

28 identificado mediante notas generales y especĂficas la forma en que las personas o empresas deban cumplir con los requisitos de calidad definidos en la etapa del proyecto.

2. Técnicas de análisis estructurado para el mejoramiento de la calidad en el diseño de sistemas de información. Existen algunas Técnicas de Auditorías de Sistemas y todas dependen de lo que se pretenda revisar o analizar, pero como estándar analizaremos las cuatro fases básicas de un proceso de revisión: • Estudio preliminar • Revisión y evaluación de controles y seguridades • Examen detallado de áreas criticas • Comunicación de resultados Estudio preliminar: Incluye definir el grupo de trabajo, el programa de auditoría, efectuar visitas a la unidad informática para conocer detalles de la misma, elaborar un cuestionario para la obtención de información para evaluar preliminarmente el control interno, solicitud de plan de actividades, Manuales de políticas, reglamentos, Entrevistas con los principales funcionarios del PAD. Revisión y evaluación de controles y seguridades: Consiste de la revisión de los diagramas de flujo de procesos, realización de pruebas de cumplimiento de las seguridades, revisión de aplicaciones de las áreas críticas, Revisión de procesos históricos (backups), Revisión de documentación y archivos, entre otras actividades. Examen detallado de áreas críticas: Con las fases anteriores el auditor descubre las áreas críticas y sobre ellas hace un estudio y análisis profundo en los que definirá concretamente su grupo de trabajo y la distribución de carga del mismo, establecerá los motivos, objetivos, alcance Recursos que usará, definirá la metodología de trabajo, la duración de la auditoría, Presentará el plan de trabajo y analizará detalladamente cada problema encontrado con todo lo anteriormente analizado. Comunicación de resultados: Se elaborará el borrador del informe a ser discutido con los ejecutivos de la empresa hasta llegar al informe definitivo, el cual se presentará esquemáticamente en forma de matriz, cuadros o redacción simple y concisa que destaque los problemas encontrados, los efectos y las recomendaciones de la Auditoría. El informe debe contener lo siguiente: • Motivos de la Auditoría • Objetivos

30 • Alcance • Estructura Orgánico-Funcional del área Informática • Configuración del Hardware y Software instalado • Control Interno • Resultados de la Auditoría

Simplificación de flujos de proceso de datos mediante el uso de diagramas.

DIAGRAMA DE FLUJO DE DATOS (DFD’s)3 DFD’s Muestran en forma visual sólo el flujo de datos entre los distintos procesos, entidades externas y almacenes que conforman un sistema. • Cuando los analistas de sistemas indagan sobre los requerimientos de información de los usuarios, deben ser capaces de concebir la manera en que los datos fluyen a través del sistema u organización, los procesos que sufren estos datos y sus tipos de salidas.

Entidad Externa • Representa personas, organizaciones, o sistemas que no pertenecen al sistema. • En el caso de que las entidades externas se comunicasen entre sí, esto no se contemplaría en el diagrama, por estar fuera del ámbito de nuestro sistema. • Puede aparecer en los distintos niveles de DFD para mejorar su comprensión, aunque normalmente sólo aparecerá en el diagrama de contexto. 3 http://alayo.files.wordpress.com/2008/12/diagrama-de-flujo-de-datos2.pdf consultada el 02 de septiembre del 2013

32 • Pueden aparecer varias veces en un mismo diagrama, para evitar entrecruzamientos de líneas. • Suministra información acerca de la conexión del sistema con el mundo exterior. Procesos • Cuando un flujo de datos entra en un proceso sufre una transformación. Un proceso no es origen ni final de los datos, sólo lugar de transformación de ellos. • Un proceso puede trasformar un dato en varios. • Es necesario un proceso entre una Entidad Externa y un Almacén de datos. • Un proceso puede representarse señalando una localización. La localización expresa la unidad o área dentro de la organización donde se realiza el proceso. Almacén de Datos • Representa la información en reposo • No puede crear, destruir ni transformar datos • No puede estar comunicado directamente con otro almacén o Entidad externa • El flujo de datos (Entrada y Salida) no lleva nombre cuando incide sobre su contenido completo • No debe estar referido al entorno físico, y por tanto, no se diferencian los ficheros convencionales de las bases de datos • No se representa la clave de acceso a este almacén sino sólo la operación que se realiza (lectura, escritura, actualización) Flujo de Datos • El concepto de flujo de datos es similar al concepto de tubería a través del cual fluye información de estructura conocida. • Los datos no pueden ser creados ni destruidos por un flujo de datos. • Sirve para conectar el resto de los componentes de un DFD. • No es un activador de procesos.

33 • Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la dirección del almacén de datos y a la inversa si es el proceso el que lee datos en el almacén.

Diagrama de entidades – asociaciones (ER) 4 •

Propuesto por Peter Chen en 1976

•

Se trata de un modelo que sirve para crear esquemas conceptuales de bases de datos.

•

Gran aceptación porque es gráfico y fácil de entender.

•

Estos modelos expresan entidades relevantes para un sistema de información así como sus interrelaciones y propiedades.

Elementos básicos

4 https://docs.google.com/viewer? a=v&pid=sites&srcid=ZWxwb2xpLmVkdS5jb3xiYXNlc2RlZGF0b3N8Z3g6Mjg2NmYyYjViMzBkZjhjMQ consultada el 02 de septiembre del 2013

35 Entidad: Objeto del mundo real sobre el que queremos almacenar información. Clase de objetos relevantes y distinguibles del mundo, que son los sujetos de interés para el modelo, para la organización. Ej.: Cliente, Empleado, Proveedor, Almacén, etc. Asociación: conexión, asociación entre 2 entidades (relación binaria) Atributo: datos que definen el objeto. Propiedad básica o característica de interés que describe una entidad o asociación. Ej. Atributos de la entidad Cliente: cédula, nombre, dirección, teléfono, etc.

TIPOS DE RELACIONES:

Diagramas de transición de estados (DTE)5 El diagrama de transición de estado (también conocido como DTE) enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de modelo sólo importaba para una categoría de sistemas conocido como sistemas de tiempo-real; Ejemplo de estos sistemas se tienen el control de procesos, sistemas de conmutación telefónica, sistemas de captura de datos de alta velocidad y sistemas de control y mando militares. En el siguiente gráfico se muestra un DTE típico.

Este diagrama muestra el comportamiento de un contestador de teléfono normal. Los principales componentes del diagrama son estados, y flechas que representan los cambios de estado. Cada rectángulo representa un estado en el que se puede encontrar el sistema. Pudiendo ser este: •

Esperar a que el usuario dé su contraseña.

•

Calentar una mezcla de sustancias químicas.

•

Esperar la siguiente orden.

•

Acelerar el motor.

5 https://sites.google.com/site/cursofpeanalistafuncional/diagramas-de-transicion-de-estados consultada el 02 de septiembre del 2013

39 •

Mezclar los ingredientes.

•

Esperar datos del instrumento.

•

Llenar el tanque.

•

Aguardar en reposo.

¿Cómo cambia un sistema de un estado a otro? Sí se tienen reglas ordenadas que gobiernan su comportamiento, entonces generalmente sólo algunos tipos de cambio de estado serán significativo y válidos. Se muestran los cambios de estado válidos en el DTE conectando pares relevantes de estado con una flecha.

Así, la figura muestra que el sistema puede ir del estado 1 al estado 2. También muestra que cuando el sistema se encuentra en el estado 2 puede ir al estado 3 o regresar al 1. A pesar de que la figura proporciona información interesante acerca del comportamiento dependiente del tiempo de un sistema, no dice cuales son los estados inicial y final del sistema. La mayoría de los sistemas tienen un estado inicial reconocible y estado final reconocible:

Lo que identifica al estado 1 de la figura como inicial es la flecha "desnuda" que no está conectada a ningún otro estado, y lo que identifica al estado 5 como final es la ausencia de una flecha que salga de él. El sentido común dice que un sistema sólo puede tener un estado inicial; sin embargo, puede tener múltiples estados finales. Los estados finales son mutuamente excluyentes, lo cual significa que sólo uno de ellos puede ocurrir durante alguna ejecución del sistema. Condiciones y acciones. Para completar nuestro DTE necesitamos añadir dos cosas más: las condiciones que causan un cambio de estado y las acciones que el sistema toma cuando cambia de estado. Como vemos en el siguiente diagrama, las condiciones y acciones se muestran junto a la flecha que conecta dos estados relacionados.

Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar; típicamente es una señal, una interrupción o la llegada de un paquete de datos. Esto usualmente hace que el sistema cambie de un estado de espera X a un estado de espera Y; o de llevar a cabo la actividad X a llevar a cabo la actividad Y. Como

parte

del

cambio

estado,

normalmente

hará

una

más

acciones:

Producirá una salida, desplegará una señal en la terminal del usuario, llevará a cabo un cálculo, etc. Construcción del diagrama de transición de estados. Así como en los DFD se utilizó la partición también es recomendable usarla en los DTE en donde los sistemas son muy complejos. Para

construcción

DTE

puede

seguir

cualquiera

dos

enfoques:

1. Se puede comenzar por identificar todos los posibles estados del sistema y representar cada uno como una caja separada en una hoja de papel. Luego, se pueden explorar todas las conexiones con significado (es decir, los cambios de estado) entre las cajas. 2. Como alternativa, se puede comenzar por el estado inicial, y luego metódicamente ir siguiendo un camino hasta el o los estados restantes; luego de los estados secundarios, proseguir a los terciarios, etc.

42 Cuando se termina de construir el DTE preliminar, deben seguirse las siguientes reglas para verificar la consistencia: •

¿Se han definido todos los estados?

•

¿Se pueden alcanzar todos los estados?

•

¿Se han definido estados que no tengan caminos que lleven a ellos?

•

¿Se puede salir de todos los estados?

•

¿El sistema responde adecuadamente a todas las condiciones posibles?

El DTE representa una especificación de proceso para una burbuja de control en DFD. Como herramienta de modelado de alto nivel, el DTE puede servir incluso como especificación de proceso para todo el sistema. Si se representa todo el sistema como un diagrama de una burbuja, puede usarse el DTE para mostrar la secuencia de actividades en el sistema.