Carga de trabajo de anlisis de sistemas. UNIDAD I. MTODOS TRADICIONALES DEL ANLISIS DE SISTEMAS. 1.1. CONCEPTOS GENERALES.

Un proyecto de sistema o software es el proceso de gestin para la creacin de un sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimacin. Estimar es prever el futuro y aceptar cierto grado de incertidumbre, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costos de tiempo dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena ingeniera sistemas y software. Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificacin. El tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software. La disponibilidad de informacin histrica es otro elemento que determina el riesgo de la estimacin. Objetivos de la planificacin del proyecto. El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente a medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor y peor caso, de modo que los resultados del proyecto pueden limitarse. El objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables.

1.1.1. SISTEMAS.
Sistema. Conjunto de reglas o principios sobre una materia relacionados entre s. Conjunto de cosas que, ordenadamente relacionadas entre s, contribuyen a un fin determinado. En computacin se le considera un conjunto de elementos interdependientes; conjunto de axiomas y reglas que determinan un perfecto desarrollo de sus funciones. Caractersticas de un sistema. Se desarrollan en su propio medio ambiente. Poseen subsistemas. Estn bajo control. Pasos para mantener el control en un sistema. Poseen un estndar para poseer un desempeo aceptable. Tienen y aplican un mtodo para medir el desempeo actual. Poseen y aplican un medio para comparar el desempeo actual con el anterior. Poseen y aplican un mtodo para realimentar el sistema, Tipos de sistemas. Sistemas Fsicos.- son los que estn compuestos por equipos, maquinaria y objetos. Pueden ser descritos en trminos cuantitativos de desempeo. Sistemas abstractos.- son los que estn compuestos por conceptos, planes e ideas. En estos los smbolos representan atributos y objetos, que solo existen en el pensamiento. Sistemas determinsticos.- son aquellos cuyo funcionamiento puede predecirse con toda certeza. Las organizaciones son sistemas probabilsticos, aunque existen vertiginosas fuerzas internas que tiendan a convertirlos en determinsticos Sistemas probabilsticos.- son aquellos en los que existe incertidumbre en cuanto a su funcionamiento. La organizacin cuenta con su medio circundante probabilstico, la incertidumbre permea todas las actividades de la organizacin.

 Sistemas abiertos.- son los que presentan relaciones de intercambio con el ambiente, a travs de entradas y salidas. Los sistemas abiertos intercambian materia y energa regularmente con el medio ambiente. Sistemas cerrados.- son los que no presentan intercambio con el medio ambiente que lo rodea, pues son hermticos a cualquier influencia ambiental; son prcticamente una utopa, todo sistema debe tener interrelacin con el exterior.

1.1.2. SISTEMAS DE INFORMACIN.

Sistema de informacin. Conjunto de elementos que interactan con un objetivo comn. Se considera una unidad abstracta (sistema de informacin). Un sistema de informacin tiene elementos que interactan entre s para apoyar las actividades de la organizacin. Permiten el logro de objetivos mediante la automatizacin de un sistema. Retroalimentacin

Entrada

Procesamiento

Salida

Almacenamiento Actividades de un sistema de informacin. Un sistema de informacin basado en computadoras hace uso de seis (6) elementos fundamentales: a) Software. Son programas de computadora con estructuras de datos y su documentacin que hacen efectiva la logstica metodologa o controles de requerimientos del programa. b) Hardware. Dispositivos electrnicos y electromecnicos, que proporcionan capacidad de clculos y funciones rpidas, exactas y efectivas (computadoras, censores, maquinaria, bombas, lectores, etc.), que proporcionan una funcin externa dentro de los sistemas. c) Personal. Operadores o usuarios directos de las herramientas del sistema.

d) Base de datos. Es una gran coleccin de informaciones organizadas y enlazadas al sistema a las que se accede por medio del software. e) Documentacin. Manuales, formularios y otra informacin descriptiva que detalla o da instrucciones sobre el empleo y operacin del programa. f) Procedimientos. Pasos que definen el uso especfico de cada uno de los elementos o componentes del sistema y las reglas de su manejo y mantenimiento. Tipos de sistemas comerciales. Existen diferentes tipos de sistemas de informacin para satisfacer las diversas necesidades de una empresa, estos sistemas se pueden clasificar en: a) TPS. Sistema de procesamiento de transacciones. Se considera el ms importante dentro de una organizacin. Tiene como finalidad mejorar las actividades rutinarias de una empresa y de las que depende toda la organizacin, incluye entre otras actividades: clculos, clasificacin, ordenamiento, almacenamiento y recuperacin, generacin de resmenes. Un ejemplo es el cajero automtico. Entre esta clasificacin se contemplan: OAS. Sistema para automatizacin de oficina. KWS. Sistema para trabajo de conocimiento. b) MIS. Sistema de informacin administrativa. Proporciona informacin para la toma de decisiones y anticipa requerimientos de informacin, ayudan a los directivos a tomar decisiones y resolver problemas presentando reportes peridicos basados en las actividades de nivel de transaccin. Un ejemplo son los reportes sobre depsitos y retiros en forma global y por sucursal de un banco, esto con el objeto de mantener al tanto a los funcionarios bancarios sobre el comportamiento de cada sucursal. c) DSS. Sistema para el soporte de decisiones. Proporciona informacin especfica a directivos en circunstancias que no estn bien estructuradas, es decir, se recurre a ellos cuando se presentan decisiones no recurrentes. Una decisin se considera no estructurada si no existen procedimientos claros para tomarla y tampoco es posible identificar, con anticipacin, todos los factores que deben considerarse en la decisin.

d) Como ejemplo puede considerarse el proceso de decisin que debe seguir un funcionario bancario para decidir entre comenzar a ofrecer cuentas para manejo de efectivo o instalar mquinas de caja automtica teniendo en cuenta que los dos servicios son nuevos en el banco. e) IA y SE. La inteligencia artificial (IA) es el anlisis y razonamiento lgico de un problema para darle solucin. Un sistema experto (SE) usa el conocimiento de un experto para la solucin de problemas particulares. f) GDSS. Sistema de apoyo a decisiones de grupo. Renen grupos para la solucin de problemas, se apoyan con cuestionarios, votaciones, etc. mediante un trabajo colaborativo apoyado por computadora (utiliza groupware). g) ESS. Sistema de apoyo a ejecutivos. Ayuda a organizar interacciones con el ambiente externo con ayuda de grficos y comunicacin a distancia.

ES S GDSS SE DSS MI S KW S OA S TP S

Nivel Gerencial

Nivel Medio

Pirmide que ilustra la posicin de los SI en base a su aplicacin administrativa.

Obrero

1.1.3. ANLISIS.
Anlisis. Es examinar la situacin de un sistema mediante un conjunto de mtodos y procedimientos. El anlisis permite reemplazar, mejorar y/o reorganizar un sistema. Anlisis de Sistemas. Es el diagnstico de problemas de un sistema (estudio del sistema), para su actualizacin y/o reemplazo. Esta accin es la funcin principal del analista de sistemas. La funcin del anlisis es dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios.

Objetivos del anlisis de sistemas: Identificar las necesidades del Cliente. Evaluar que conceptos tiene el cliente del sistema para establecer su viabilidad. Realizar un Anlisis Tcnico y econmico. Asignar funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema. Establecer las restricciones de presupuestos y planificacin temporal. Crear una definicin del sistema que forme el fundamento de todo el trabajo de Ingeniera. Definir los usuarios que interactan con el sistema. Los usuarios se clasifican en: a) Final primario (directo). Aquel que solamente opera el sistema. No es un especialista en sistemas de informacin. b) Final indirecto. Aquel que no opera el sistema y emplea la informacin generada por el mismo. No es un especialista en sistemas de informacin. c) Administrador (gerente). Aquel que supervisa la inversin en el sistema de informacin y controlan las actividades del sistema. d) Directivos. Aquellos que incorporan usos estratgicos del sistema en planes y estrategias de la organizacin. Evalan los riesgos por fallas del sistema.

1.1.4. DISEO.
Diseo. Es el desarrollo y/o elaboracin de los procesos planificados durante la fase de anlisis. Diseo de Sistemas. Planifica, reemplaza y/o complementa un sistema mediante un conjunto de mtodos y medios, en base a un previo anlisis del sistema.

1.1.5. ANALISTA DE SISTEMAS.

El analista de sistemas es el encargado de realizar el estudio del sistema para su actualizacin y/o reemplazo. Conduce el estudio del sistema, detecta hechos relevantes, rene la informacin necesaria y determina los requerimientos del sistema. Tambin se le denomina Analista de informacin. Analista diseador. Aquel que realiza el estudio completo del sistema y disea o actualiza el sistema. Analista programador. Aquel que conduce la investigacin, desarrolla las especificaciones del diseo y escribe el software.

1.1.6. PROGRAMADOR.
Programador. Aquel especializado en un solo campo y slo se encarga del cdigo del sistema.

1.1.7. ADMINISTRADOR DE BASES DE DATOS.

Es la persona responsable del diseo fsico y administracin de las bases de datos, as como de la evaluacin, seleccin e implementacin del DBMS. En organizaciones pequeas, el administrador de bases de datos y el administrador de datos son lo mismo; sin embargo, cuando las dos responsabilidades son manejadas por separado, las funciones del administrador de bases de datos son ms tcnicas. El DBMS (Data Base Management System Administrador de bases de datos) es un software que provee la administracin de las bases de datos (database management cabability) para lenguajes de programacin tradicional tales como Cobo, Basic y C, pero sin la capacidades interactivas (interactive capabilities)

1.2. CICLO DE VIDA CLSICO.

El ciclo de vida del desarrollo de sistema representa el conjunto de actividades que el analista, diseador y usuarios realizan para desarrollar e implantar un sistema. Diversos autores difieren en cuanto al nmero de actividades a realizar, pero se pueden considerar en forma general: a) Investigacin preliminar. Parte inicial del proyecto en la cual se realiza una solicitud de un sistema de informacin. b) Determinacin de requerimientos. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las preguntas clave: Qu es lo que se hace?, cmo se hace?, con qu frecuencia se presenta?, qu tan grande es el volumen de transacciones o de decisiones?, cul es el grado de eficiencia con el que se efectan las tareas?, existe algn problema?, si existe un problema qu tan serio es? y cul es la causa que lo origina?. El analista debe reunir detalles relacionados con los procesos de la empresa, sus opiniones sobre por qu ocurren las cosas, las soluciones que proponen y sus ideas para cambar el proceso, se valen de herramientas tales como entrevistas, cuestionarios, observacin y lectura de reportes. c) Diseo del sistema. Se le conoce como diseo lgico. El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. d) Se comienza por identificar los reportes y salidas que debe producir el sistema as como los datos especficos para cada uno de ellos. Indica tambin los datos de entrada, aquellos que sern calculados y los que deben ser almacenados; se determinan con detalle los procedimientos de clculo y los datos individuales. Se eligen las estructuras de archivo y los dispositivos de almacenamiento (discos, cd-rom, impresoras, etc.). Los documentos de apoyo para este diseo se representan de muchas formas, tales como diagramas, tablas y smbolos especiales, etc. e) Desarrollo de software. Fase donde los encargados pueden instalar (o modificar e instalar) software comprado o desarrollar software hecho a la medida. La eleccin depende de factores tales como costos, tiempos disponibles y disponibilidad de los programadores.

Los programadores son los responsables de la documentacin de los programas y de la capacitacin. f) Prueba del sistema. Es la utilizacin del sistema de manera experimentas para asegurar la carencia de fallas, as como de que cumpla con las especificaciones requeridas. En algunos casos las pruebas son conducidas por personas ajenas al grupo de analistas de tal forma que se asegure que las pruebas sean completas e imparciales y se tenga un software confiable. g) Implantacin y evaluacin. Es el proceso de verificar e instalar el nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarlas. Se contempla tambin en esta fase, el mantenimiento al sistema. Este mantenimiento se proporciona al sistema debido a que con el paso del tiempo las organizaciones y usuarios cambian y se deben realizar cambios y modificaciones en el software, archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios. La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes, la evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones: Evaluacin operacional. Valoracin de la forma en que funciona el sistema, el tiempo de respuesta, los formatos de informacin, confiabilidad global y nivel de utilizacin. Impacto organizacional. Identificacin y medicin de los beneficios para la organizacin como finanzas, eficiencia operacional, impacto competitivo e impacto sobre el flujo de informacin interno y externo. Opinin de los administradores. Evaluacin de las actitudes de directivos, administradores y usuarios finales dentro de la organizacin. Desempeo del desarrollo. Cuando la evaluacin del proceso de desarrollo de acuerdo con criterios de tiempo y esfuerzo de desarrollo concuerdan con presupuestos, estndares y otros criterios de administracin de proyectos. Incluye la valoracin de los mtodos y herramientas utilizados en el desarrollo.

1.2.1. INVESTIGACIN PRELIMINAR.

La solicitud de un sistema siempre se inicia con la peticin de una persona. Determina con precisin lo que se desea y realiza una identificacin inicial de el (los) problemas, oportunidades y objetivos del sistema. Esta actividad tiene 3 partes: a) SOLICITUD DEL PROYECTO. La solicitud del proyecto permite el anlisis de la solicitud, de tal manera que se pueda determinar con precisin lo que el solicitante desea, aclarando dnde se encuentra el problema y los objetivos que se pretenden alcanzar; todo esto debe plantearse de forma clara y precisa. Motivos para realizar la solicitud. Resolver problemas. Permite modificar actividades, procesos o funciones que en el presente o futuro no satisfacen estndares y/o expectativas del sistema. Aprovechar una oportunidad. Cambios para ampliar/mejorar el rendimiento econmico y competitividad empresarial. Dar respuesta a directivos. Para dar informacin o respuesta a rdenes, solicitudes o mandatos, realizar tareas de cierta forma, cambiar informacin o desempeo. Razones para emprender proyectos. Capacidad.- Aumentar la velocidad del procesamiento. Incremento en el volumen de informacin de procesamiento. Rpida recuperacin de informacin. Control.- Mejora en exactitud y consistencia, es decir, funcionalidad adecuada y correcta en los procesos. Seguridad e integridad en los datos. Comunicacin. Mejora en la comunicacin. Integracin de reas (coordinacin de actividades de la empresa de las diferentes reas por medio de la captura y distribucin de la informacin) Costos. Monitoreo y reduccin de costos. Ventajas competitivas. Atraer y asegurar clientes (mejor precio, servicios exclusivos, productos diferentes). Dejar fuera la competencia. Mejores acuerdos con los proveedores. Desarrollo de nuevos productos.

Fuentes de solicitud de proyectos. Gerentes departamentales Altos ejecutivos (presidentes, directores de consejo, vicepresidentes) Analistas de sistemas Grupos externos (gobierno, hacienda, etc.) Informacin que debe contener una solicitud de proyecto. Cul es el problema? Detalles del problema Importancia del problema Cul cree el usuario que es la solucin? En qu forma ser de ayuda un sistema de informacin? Qu otras personas tienen conocimiento de ste problema y si se pueden contactar?

Para identificar problemas:

Buscar estos signos:

Revise la salida contra los criterios de Demasiados errores desempeo. Trabajo terminado lentamente Trabajo hecho incorrectamente Trabajo hecho en forma incompleta Trabajo que no se realiza del todo Observe el comportamiento de los Alto ausentismo empleados. Alta insatisfaccin en el trabajo Alta rotacin de personal Escuche la retroalimentacin externa de Quejas

vendedores, clientes, proveedores.

Sugerencias de mejoras Prdida de ventas Menores ventas

Identificacin de problemas. Oportunidades o mejoras. Son los cambios que darn como resultado aumento de beneficios e incluyen: Aceleracin de procesos Agilizacin de un proceso excluyendo pasos innecesarios o duplicados Combinacin de procesos. Reduccin de errores en la entrada por medio de cambios en formas y pantallas VDT. Reduccin de salidas redundantes. Mejora en la integracin de sistemas y subsistemas. Mejora de la satisfaccin del trabajo con el sistema. Mejora de la facilidad de interaccin de los clientes, proveedores y vendedores, con el sistema. b) ESTUDIO DE FACTIBILIDAD. El estudio de factibilidad ayuda a determinar que el sistema solicitado sea de utilidad para la organizacin, evaluando 3 pruebas de factibilidad: operacional, tcnica y financiera. Este estudio pretende localizar los objetivos organizacionales y determinar si el proyecto puede orientarse a dichos objetivos. Estos objetivos pueden ser: Reducir errores y mejorar la precisin de entrada de datos. Reducir costos de salida agilizando y eliminando reportes duplicados e innecesarios. Integrar subsistemas del negocio. Mejora de servicios al cliente para ganar una posicin competitiva. Acelerar la entrada.

 Reducir tiempo de proceso de datos. Automatizar procesos manuales. Tipos de factibilidad. Tcnica. Es viable cuando el equipo, la tecnologa de software y el personal son suficientes para satisfacer el trabajo. Se presentan incgnitas tales como: Existe o se puede adquirir la tecnologa necesaria para realizar las peticiones?. El equipo propuesto tiene la capacidad tcnica para soportar los datos del nuevo sistema?. El sistema ofrecer respuestas adecuadas sin importar el nmero y ubicacin de los usuarios?. Puede crecer el sistema?. Existen garantas tcnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de datos? Econmica. Es viable cuando los beneficios econmicos que se obtienen sern suficientes para aceptar los costos, es decir, los beneficios financieros deben igualar o exceder los costos. Para considerarse factible se debe considerar: El costo de la investigacin completa del sistema. El costo del hardware y software para la aplicacin considerada. Obtener beneficios en la reduccin de costos o disminucin de errores costosos. El costo de no llevar a cabo el sistema. Operacional. Es viable cuando al desarrollar e implantar el sistema, satisface los requerimientos de la organizacin. Para evaluar esta factibilidad es importante la respuesta de preguntas como: Existe apoyo suficiente para el proyecto por parte de la administracin y de los usuarios?. Los mtodos que actualmente se emplean en la empresa son aceptados por los usuarios?. Los usuarios han participado en la planeacin y desarrollo del proyecto?. El sistema propuesto causar perjuicios, resultados pobres, perder el control en alguna rea, perder la facilidad de acceso a la informacin, disminuir la productividad o se afectar a los clientes desfavorablemente?

C)APROBACIN DE LA SOLICITUD.

Si la solicitud es deseable y factible se incorpora a los planes, se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal y as determinar dnde ubicarlo dentro de la lista de proyectos.

Planeacin y control de actividades. Incluye todas las actividades requeridas para seleccionar un equipo para el anlisis de sistemas, asignacin de tareas, estimacin del tiempo requerido y calendarizacin del proyecto. Toma en cuenta la retroalimentacin y la comparacin del plan del proyecto con su evolucin actual. En la Tabla 2 se presenta un ejemplo sobre la planeacin de actividades, muestra las fases del proyecto, las actividades a desarrollar en cada fase as como el tiempo requerido para llevarlas a cabo. Fase Actividades detalladas Semanas requeridas Recoleccin de datos Realizacin de entrevistas. Administracin de cuestionarios. Lectura de reportes de la compaa. Presentacin del prototipo. Observacin de las reacciones ante el prototipo. Anlisis de flujo de datos y toma de decisiones Anlisis del flujo de datos y para la toma de decisiones. 8 (D) 3 (A) 4 (B) 4 (C) 5 (E) 3 (F)

Preparacin de la propuesta

Realizacin costo/beneficio.

del

anlisis

3 (G)

 Preparacin de la propuesta. Presentacin de la propuesta Ejemplo sobre la planeacin de actividades.

2 (H) 2 (I)

Grficas de Gantt. Una grfica de Gantt es una forma fcil para calendarizar tareas por medio de una grfica de barras que representan cada tarea o actividad y su longitud representa su duracin. En la siguiente figura se muestra un ejemplo sobre la elaboracin de un diagrama de Gantt, desarrollado en base a una previa planeacin de actividades, muestra las actividades a desarrollar y el tiempo requerido para llevarlas a cabo. Por medio de esta grfica se puede verificar el cumplimiento de las actividades en el tiempo estimado. Actividad A B C D E F G H I 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Semanas Ejemplo de un diagrama de Gantt.

1.2.2. DETERMINACIN DE REQUERIMIENTOS.

La determinacin de requerimientos es el estudio de un sistema para conocer cmo trabaja y dnde es necesario efectuar mejoras. Un requerimiento es una caracterstica que debe incluirse en un nuevo sistema, puede ser la inclusin de determinada forma para capturar o procesar datos, producir informacin, controlar una actividad de la empresa o brindar soporte a la gerencia.

Actividades de la determinacin de requerimientos. a) Anticipacin de requerimientos. Los analistas deben prever las caractersticas y requerimientos del sistema as como ciertos problemas. En base a la experiencia de los analistas, pueden realizarse investigaciones en reas y aspectos que de otra forma no seran tomados en cuenta. Permite tambin la toma de atajos al conducir la investigacin. b) Investigacin de requerimientos. Se considera la ms importante del anlisis. Es el estudio del sistema actual con la ayuda de herramientas y habilidades para su documentacin y posterior anlisis. c) Especificacin de requerimientos. Se refiere al anlisis de los datos obtenidos en la recopilacin de hechos para determinar las caractersticas del nuevo sistema y contempla: El anlisis de datos basados en hechos reales.- se examinan los datos obtenidos para determinar el grado de desempeo del sistema y si cumple con las demandas. La identificacin de requerimientos esenciales.- son las caractersticas que deben incluirse en el sistema (desde detalles de operacin hasta criterios de desempeo). La seleccin de estrategias para satisfacer los requerimientos.- son los mtodos que se utilizarn para alcanzar los requerimientos establecidos y seleccionados. Requerimientos bsicos. Cul es el proceso bsico de la empresa? Qu datos utiliza o produce este proceso? Cules son los lmites impuestos por el tiempo y la carga de trabajo? Qu controles de desempeo utiliza? Comprensin del proceso. Cul es la finalidad de esta actividad dentro de la empresa? Qu pasos se siguen para llevarla a cabo? Dnde se realizan estos pasos? Quines los realizan?

 Cunto tiempo tardan en efectuarlos? Con cunta frecuencia lo hacen? Quines emplean la informacin resultante?

Identificacin de datos empleados e informacin generada. Se debe detectar qu datos se utilizan para llevar a cabo cada actividad. Por ejemplo: para reabastecer el inventario, el comprador requiere datos que describan para cada artculo la cantidad existente, la demanda esperada, el nombre del proveedor y el costo; para saber cundo hacer el pedido, el comprador debe considerar el tiempo de entrega de la mercanca.

Frecuencia y volumen del proceso. La frecuencia con la que se presentan las actividades en una empresa es variable por lo tanto, es imprescindible identificar con cunta frecuencia se repite un proceso o actividad, as como su efecto sobre las actividades de la empresa. La forma ms efectiva para recabar dicha informacin es identificando el objetivo de la actividad (determinando la causa de la actividad permite comprender adecuadamente la razn de una actividad y as poder darle la debida importancia). La causa directa es la funcin de iniciacin; las actividades pueden ser iniciadas por los clientes, sucesos y por el paso del tiempo. El volumen de la informacin manejada puede aumentar el tiempo necesario para completar las actividades. La cantidad total de pasos de que consta una actividad, puede generar problemas especiales para el estudio que efecta el analista, a pesar de que dicha actividad se realice con poca frecuencia. Como por ejemplo: los bancos preparan estados de cuenta de los clientes 4 veces al ao, independientemente de que la frecuencia es baja, el volumen de trabajo es grande, ya que en ocasiones se necesitan preparar decenas de miles de estados de cuenta.

Identificacin de controles. Es importante examinar los mtodos de control durante la etapa de anlisis tales como: los estndares de desempeo, las personas que se encargan de comparar el desempeo contra los estndares, cmo se detectan errores, cmo se corrigen los errores y el margen de error existente. En situaciones donde se ejerce buen control de los procesos disminuye los problemas al determinar si una actividad se ha llevado a cabo en forma adecuada.

Requerimientos de las transacciones de los usuarios. Se debe conocer todo lo relacionado con la forma en que se procesan las transacciones; para entender estos requerimientos se enlistan algunas preguntas que sirven para obtener una descripcin apropiada del sistema, tambin sealan la relacin entre los sistemas de transacciones y los de decisiones. a) Volumen: Cul es el volumen de actividades que se presentan?. Con qu frecuencia ocurren las actividades?. Ocurren las actividades de acuerdo con un ciclo? b) Control: Qu reas necesita un control especfico?. Cules son los mtodos de control utilizados?. Qu criterios se emplean para medir y evaluar el desempeo?. Qu mtodos se emplean para detectar lagunas en los controles?. Se toman precauciones especficas de seguridad para proteccin contra una actividad impropia?. Existen mtodos para evadir el sistema?. Por qu se presentan? c) Procesos: Qu procesos, pasos o funciones constituyen esta actividad?. Qu es lo que da inicio a la actividad?. Cunto tiempo tarda cada actividad?. Qu factores intervienen en la duracin de la actividad?. Qu retrasos ocurren o pueden ocurrir?. Cmo interactan los elementos entre s?. Cul es el costo de operacin del sistema?. Se satisfacen los objetivos especficos de la gerencia? d) Datos: Qu datos entran al sistema y cul es su origen?. En qu forma se reciben los datos del sistema?. En qu forma son almacenados?. Qu datos son almacenados en el sistema o como parte de las actividades del mismo?. Quines utilizan la informacin generada por el sistema?. Con qu finalidad la utilizan?. Qu es lo que no se utiliza

(partes extraas)?. Qu datos faltan con mayor frecuencia?. Existen datos desarrollados o empleados sobre una base ad hoc?. Qu tablas de referencia, diagramas u otros datos se utilizan?. Cmo estn codificados o abreviados los datos y actividades?. e) Otros: Quines son las personas clave en el sistema?. Por qu son importantes?. Qu obstculos o influencias de tipo poltico afectan la eficiencia del sistema?.

Requerimientos de decisin de los usuarios. Estas actividades no siguen un procedimiento especfico debido a que las decisiones se toman al integrar la informacin de tal forma que los gerentes puedan saber qu acciones emprender; es probable que los sistemas de decisin tengan que ver con el pasado, presente o futuro. Dan soporte a decisiones recurrentes, as como a no recurrentes y nicos. Estos sistemas utilizan datos originados dentro de la empresa, generados por el procesamiento de transacciones o datos externos derivadas de asociaciones o fuentes comerciales por ejemplo. Al investigar los sistemas para el soporte de decisiones deben formular las preguntas mencionadas sobre frecuencia y volumen, anexando las especificas para los requerimientos de decisin: Qu informacin se utiliza para tomar la decisin?. Cul es la fuente de esta informacin?. Qu sistemas de transacciones producen los datos utilizados en el proceso de decisin?. Qu otros datos son necesarios y no es posible obtener del procesamiento de transacciones?. Qu datos se originan en fuentes externas?. Cmo se deben procesar los datos para producir la informacin necesaria?. Cmo se debe presentar la informacin? Requerimientos de toda la organizacin. Los departamentos dependen unos de otros para brindar servicios, fabricar productos y satisfacer a los clientes. Como consecuencia de esto; al estudiar sistemas para un departamento, se deben evaluar las implicaciones para los dems departamentos e identificar las dependencias y como los afecta.

1.2.3. DISEO DEL SISTEMA.

El objetivo de los diseadores es producir un modelo o representacin de una entidad que ser construida a posteriori. El diseo es una representacin significativa de ingeniera de algo que se va a construir. Se puede hacer el seguimiento basndose en los requisitos del cliente, y al mismo tiempo la calidad se puede evaluar y cotejar con el conjunto de criterios predefinidos para obtener un diseo bueno. Considerando la ingeniera del software, el diseo se centra en cuatro reas importantes de inters: datos, arquitectura, interfaces y componentes. El ingeniero de software es quien disea los sistemas basados en computadoras, pero los conocimientos que se requieren en cada nivel de diseo funcionan de diferentes maneras. En el nivel de datos y de arquitectura, el diseo se centra en los patrones de la misma manera a como se aplican en lo que se va a construir. En el nivel de la interfaz, es la ergonmica humana la que dicta nuestro enfoque de diseo. Y en el nivel de componentes, un enfoque de programacin conduce a diseos de datos y procedimientos eficaces. El diseo comienza con el modelo de los requisitos. Se trabaja por transformar este modelo y obtener cuatro niveles de detalles de diseo: la estructura de datos, la arquitectura del sistema, la representacin de la interfaz y los detalles a nivel de componentes. Durante cada una de estas actividades se aplican los conceptos y principios bsicos que llevan a obtener una alta calidad. El diseo del software, al igual que los enfoques de diseo de ingeniera en otras disciplinas, va cambiando continuamente a medida que se desarrollan mtodos nuevos, anlisis mejores y se ampla el conocimiento. Conceptos del diseo: a) Abstraccin. Cuando se tiene en consideracin una solucin modular a cualquier problema, se pueden exponer muchos niveles de abstraccin. En el nivel ms alto, la solucin se pone como una medida extensa empleando el lenguaje del entorno del problema. En niveles inferiores, se toma una orientacin ms procedimental.

En el nivel ms bajo, se establece la solucin para poder implementarse directamente, maneja los siguientes niveles: Abstraccin procedimental.- es una secuencia nombrada de instrucciones que tiene una funcin especfica y limitada. Un ejemplo sera la palabra abrir para una puerta; abrir implica una secuencia larga de pasos procedimentales (llegar a la puerta, alcanzar y agarrar el pomo de la puerta, etc.).

Abstraccin de datos.- es una coleccin nombrada de datos que describe un objeto de datos. En el contexto de la abstraccin procedimental abrir, podemos definir una abstraccin de datos llamada puerta y acompaara a un conjunto de atributos que la describen (tipo de puerta, direccin de apertura, tamao, etc.). Abstraccin de control .- implica un mecanismo de control de programa sin especificar los datos internos. Un ejemplo es el semforo de sincronizacin utilizado para coordinar las actividades en un sistema operativo.

b) Refinamiento. Es una estrategia de diseo descendente donde el desarrollo de un programa se realiza refinando sucesivamente los niveles de detalle procedimentales. Una jerarqua se desarrolla descomponiendo una sentencia macroscpica de funcin paso a paso hasta alcanzar las sentencias del lenguaje de programacin. El refinamiento hace que el diseador trabaje sobre la sentencia original, proporcionando cada vez ms detalles a medida que van teniendo lugar sucesivamente todos y cada uno de los refinamientos. c) Modularidad.- la arquitectura de computadoras expresa la modularidad, es decir, el software se dividen en componentes nombrados y abordados por separado, llamados mdulos, que integran para satisfacer los requisitos del problema. El software monoltico (formado por un nico mdulo) no puede ser entendido fcilmente por el lector; es ms fcil resolver un problema complejo cuando se rompe en piezas manejables.

Para definir el tamaa adecuado de un mdulo se debe considerar: La capacidad de descomposicin modular, la capacidad de empleo de componentes modulares, la capacidad de comprensin modular, la continuidad modular, la proteccin modular. d) Arquitectura del software.- alude a la estructura global del software y a las formas en que la estructura proporciona la integridad conceptual de un sistema. Es la estructura jerrquica de los componentes del programa (mdulos), la manera en que los componentes interactan y la estructura de datos que van a utilizar los componentes. Los componentes se pueden generalizar para representar los elementos principales del sistema y sus interacciones. e) Jerarqua de control.- llamada tambin estructura de programa, representa la organizacin de los componentes de programa (mdulos) e implica una jerarqua de control. No representa los aspectos procedimentales del software, ni se puede aplicar necesariamente a todos los estilos arquitectnicos.

f) Representa dos caractersticas diferentes de la arquitectura del software: visibilidad (indica el conjunto de componentes de programa que un componente dado puede invocar o utilizar como dato, incluso cuando se lleva a cabo indirectamente) y conectividad (indica el conjunto de componentes que un componente dado invoca o utiliza directamente como datos). g) Divisin estructural.- si el estilo arquitectnico de un sistema es jerrquico, la estructura del programa se puede dividir tanto horizontal como verticalmente. El enfoque ms simple de la divisin horizontal define tres particiones: entrada, transformacin de datos y salida. Ventajas: software ms fcil de probar, mantener y ampliar, y propaga menos efectos secundarios. Desventajas: suele hacer que los datos pasen a travs de interfaces de mdulos y pueden complicar el control global del flujo del programa. La divisin vertical (factorizacin) sugiere que dentro de la estructura de programa el control y el trabajo se distribuyan de manera descendente. Los mdulos del nivel superior debern llevar a cabo funciones de control y no realizarn mucho trabajo de procesamiento.

Los mdulos inferiores deben ser los trabajadores y realizarn todas las tareas de entrada, proceso y salida. g) Estructura de datos.- es una representacin de la relacin lgica entre elementos individuales de datos. La organizacin y complejidad estn limitados nicamente por la ingenuidad del diseador, no existe un nmero limitado de estructuras de datos clsicas que componen los bloques de construccin para estructuras ms sofisticadas. Un elemento escalar es la estructura de datos ms simple, representa un solo elemento de informacin que puede ser tratado por un identificador (una sola direccin de memoria). El tamao y formato puede variar dentro de los lmites que dicta el lenguaje de programacin. Cuando estos elementos se organizan como una lista o grupo contiguo se forma un vector secuencial, estas estructuras de datos son las ms comunes y abren la puerta a la indexacin variable de la informacin. Al ampliar el vector secuencial a dos, tres o un nmero arbitrario de dimensiones, se crea un espacio n-dimensional, siendo la ms comn la matriz bidimensional (array). Una lista enlazada es una estructura de datos que organiza elementos escalares no contiguos, vectores o espacios (nodos) de manera que les permita ser procesados como una lista, cada nodo contiene la organizacin de datos adecuada o un puntero o ms que identifican la direccin de almacenamiento del siguiente nodo de la lista. h) Procedimiento de software.- se centra en el procesamiento de cada mdulo individualmente, debe proporcionar una especificacin precisa de procesamiento, incluyendo la secuencia de sucesos, los puntos de decisin exactos, las operaciones repetitivas e incluso la estructura/organizacin de datos.

1.2.4. DESARROLLO DEL SOFTWARE.

El diseo del software es importante para el adecuado funcionamiento del mismo, de tal forma que cubra los requerimientos y necesidades que se establecieron durante la fase del anlisis. Debe considerarse:

DISEO DE SALIDA EFECTIVA. Se refiere a los resultados e informacin generados por el sistema. Para algunos usuarios finales es la nica razn para el desarrollo del sistema y la base sobre la que evaluarn la utilidad de la aplicacin. El diseo de la salida est especificado en los formularios de distribucin1, que son hojas que describen la ubicacin, caractersticas (como longitud y tipo) y formato de los encabezados de columnas y la paginacin. Consideraciones. Determinar qu informacin presentar. Decidir si la informacin ser presentada visual, verbal o impresa y seleccionar el medio de salida. Disponer la presentacin de la informacin en un formato aceptable. Decidir cmo distribuir la salida entre los posibles destinatarios.

Objetivos de la salida. Expresar informacin relacionada con actividades pasadas, estado actual o proyecciones a futuro. Sealar eventos importantes, oportunidades, problemas o advertencias. Iniciar una accin. Confirmar una accin.

Tipos de salidas. Una salida es el resultado de un proceso, puede ser:

.

Reportes Documentos Mensajes

De acuerdo con las circunstancias y contenidos, puede ser impresa o en pantalla; el contenido de la salida tiene su origen en: Recuperacin de un dispositivo de almacenamiento. Transmisin desde un proceso o actividad del sistema. Directamente desde una fuente de entrada.

El DFD contiene anotaciones que indican aspectos relacionados con el diseo de la salida tales como: dnde es necesario una salida generada por el sistema y la necesidad de copias, formularios y otros detalles. Aspectos importantes de la salida. Se debe tomar en cuenta quines recibirn la salida debido a que los usuarios pueden tener requerimientos especficos que no pueden ser cambiados. El uso que se le pretende dar a la salida pues determinar el contenido, forma y medio a utilizarse para su generacin. La cantidad de detalles necesarios que debe contener la salida. Cundo y con qu frecuencia es necesaria la salida. El mtodo que se utilizar (impresa o en pantalla).

Forma de presentacin de salidas. Formato Tabular. Formato que contiene renglones y columnas donde se distribuye la informacin, ejemplos: control de inventario, cuentas por pagar, calendarios de produccin, etc. El formato debe presentar los detalles en orden significativo para su fcil localizacin, evitar incluir demasiados detalles y poca informacin as como datos innecesarios, este tipo de formato se utiliza bajo las siguientes condiciones: Cuando los detalles dominan y son necesarios pocos comentarios o explicaciones. Cuando los detalles son presentados en categoras discretas. Cuando cada categora debe tener una etiqueta. Cuando se deben obtener totales o realizar comparaciones entre diversos componentes.

Se debe considerar resaltar los siguientes aspectos: Excepciones a las expectativas normales. Categoras ms importantes de actividades o entidades. Resmenes de las categoras o actividades ms importantes. Identificacin nica de la informacin. Entidades que dependen del tiempo. Formato Grfico. Las grficas empresariales no son por s mismas una nueva reas aunque permiten a nivel gerencial, mejoras en la presentacin de la informacin. Las grficas deben contener anotaciones que indiquen la escala utilizada, el significado de cada lnea u objeto y lo que la grfica representa. Una grfica complementan otra informacin no la reemplaza, deben hacer notar su objetivo con rapidez al lector o de lo contrario perder el inters.

Tipos de grficas. De sectores. Describen partes de un todo que guardan relacin con un desarrollo o actividad en particular, por ejemplo: comparacin en el porcentaje de gastos asignados al departamento de produccin en comparacin con el resto de los departamentos. De reas. Muestran cambios en el desempeo a lo largo de varios periodos de tiempo. Una escala horizontal indica el tiempo (das, meses, aos) mientras que una vertical seala las unidades de medicin de inters (dlares, porcentajes, unidades). La superposicin de varios objetos sobre la misma grfica permite ver el cambio de uno en relacin con los dems. Por ejemplo: sealar el aumento en los gastos de los sistemas de produccin, mercadotecnia y personal sobre la misma grfica de curvas. En una grfica no se deben mostrar ms de tres o cinco lneas y se sugiere emplear diferente grosor o color para transmitir la informacin.

 De barras o escalones. Muestran cambios en categoras, miden los puntos dato desde la escala horizontal hasta el nivel apropiado de la escala vertical. Con frecuencia, se superponen varios objetos para comparar las categoras de un ao a otro. Mapas. Pueden mostrar con eficacia variaciones a travs de distintas zonas geogrficas, por ejemplo: los mapas climatolgicos. Las grficas se emplean para: Mejorar la efectividad de los reportes que como salida se envan a los usuarios que deben recibirlos. Manejar el volumen de informacin, la comprensin de grandes cantidades de datos en una grfica no disminuye la cantidad de informacin. El beneficio de la comprensin es que separa la informacin en grupos pequeos, lo que permite recordarlos y comprenderlos con mayor facilidad. Ajustarse a preferencias personales.

Tabla 15. Cuando son o no eficientes las grficas. Las grficas son eficientes para: 1. Detectar patrones en los datos. 1. Detectar tendencias o cambios en stas. Las grficas no son eficientes para: 1. Determinar los valores especficos para ciertos puntos dato.

2. Identificar relaciones de desempeo entre 2. Determinar el cambio absoluto en los valores numricos representados en elementos. tendencias o patrones. 3. Representar una pequea cantidad de datos.

Los estndares para el diseo de grficas apoyan el trabajo del diseador en la preparacin de presentaciones grficas tales como el diseo del texto de la grfica: contenido y cantidad de texto (ttulo, fecha, nmero de pgina); legibilidad; ubicacin; debe estar en forma horizontal; evitar exceso; espaciamiento; tipo, estilo y tamao de letra.

Los conos se emplean comnmente en las interfaces de computadora para representar documentos, cestos, archivos e impresoras. Estos comunican informacin en forma inmediata cuando son seleccionados en forma apropiada, ya que duplican imgenes con las que los usuarios estn familiarizados. Se deben considerar los siguientes lineamientos sobre cundo y cmo utilizar los conos: Seleccionar los conos que sern reconocidos y comprendidos inmediatamente por los usuarios; si no existen se debe emplear etiquetas que eviten la necesidad de que los usuarios aprendan y recuerden smbolos o imgenes poco familiares. Utilice el mismo cono para representar los mismos conceptos a travs de varios medios de salida. Evitar el empleo de etiquetas en los conos. Distribucin adecuada que evite la aglomeracin. Utilizar el mismo tamao entre los diferentes tipos de smbolos. El uso inadecuado del color puede ser ms un obstculo que una ayuda. Se recomienda el uso de cuatro o menos colores en un reporte o pantalla. Entre ms colores utilicen mayor deber ser la informacin proporcionada por datos y figuras. Debe mantenerse la consistencia en el uso del color a travs de todas las salidas de un sistema, por ejemplo: el rojo es excelente para resaltar excepciones y problemas; el verde y azul para representar situaciones normales. Los colores intensos sobre una pantalla recalcan la informacin ms importante, los colores brillantes incluyen el blanco, turquesa y rosa. Los colores oscuros son el magenta, rojo, verde y azul. Ni el color ni las grficas mejoran o compensan un diseo pobre, sin embargo, el uso efectivo de las grficas puede mejorar los resultados que alcanzan los gerentes y usuarios cuando trabajan con la salida del sistema. Las grficas, conos y el color pueden aparecer en cualquier tipo de salida. Salida de audio. Puede considerarse el opuesto de la salida impresa, es transitoria y emitida usualmente para beneficio de un usuario.

Le da al usuario confirmacin verbal de lo tecleado o borrado, pistas del tiempo, etc. Tiene como desventajas : El costo del dispositivo, limitado vocabulario, tiempo de respuesta lento. Salida electrnica. Muchos de los nuevos sistemas tienen la capacidad de enviar salida electrnica en forma de correo electrnico, fax y mensajes de tablero electrnico, pudiendo ser enviados de computadora a computadora sin la necesidad de copia en papel. Algunas de sus ventajas radican en que facilita el intercambio de documentos es rpido, utiliza firmas electrnicas para su autenticidad, se puede ajustar y ejecutar internamente dentro de la organizacin o por medio de compaas de comunicacin o servicios en lnea, ayuda a reducir el desperdicio de papel, elimina el juego de etiquetas telefnicas, ayuda a los usuarios a transmitir mensajes a grupos de trabajo y proporcionar un medio para actualizar la salida muy fcilmente. Las desventajas incluyen la dificultad en el control del formateo, el potencial de abusar del sistema, dificultades en el desarrollo de un protocolo til para el manejo de correo electrnico basura y la necesidad de desarrollar polticas organizacionales para un uso aceptable, dificulta expresar el estado de nimo o la intencin de un mensaje.

Diseo de salida impresa. Varan en tamao pero utilizan en forma estndar (tamaos para formas continuas): 9 por 11 pulgadas 11 por 14 7/8 pulgadas 8 por 14 7/8 pulgadas Impresoras de impacto. De lneas de baja velocidad. Con una velocidad de operacin de 300-600 lneas por minuto. De lneas de alta velocidad. Con una velocidad aproximada de operacin de hasta 3600 lneas por minuto. De matriz de puntos. Con una velocidad aproximada de operacin de 40-1200 caracteres por segundo.

Tiene este nombre debido a que tiene un cabezal mvil con un conjunto de agujas separadas en una o varias columnas. El procesador de la impresora recibe la informacin de la tabla de bitmaps y se dedica a calcular el camino ms eficiente, lnea por lnea, para el viaje del cabezal. A partir de esto enva las seales al cabezal y al rodillo para realizar la impresin. Cada aguja termina en una pieza plstica de forma de un sector circular que a su vez tiene un imn cilndrico. El imn se desplaza por un alambre que lo rodea, si se hace circular energa elctrica por este alambre se genera un campo magntico que atrae el imn. El desplazamiento del imn hace que la pieza plstica impacte contra la cinta de tinta y se marque el papel. Cuando no circula ms corriente por el electroimn, este deja de ser atrado por el campo magntico y el resorte hace que la aguja vuelva a la posicin de reposo. A pesar de ser ruidosas, las impresoras de matriz de puntos se siguen usando debido a que resulta econmico para realizar varias copias en la facturacin en todo tipo de negocios. Por otra parte, el mantenimiento de estas impresoras es muy econmico comparado con las dems tecnologas. De caracteres con tipografa slida. Con una velocidad aproximada de operacin de 12120 caracteres por segundo. Impresoras de no impacto. Chorro de tinta. Con una velocidad aproximada de operacin de 20-240 caracteres por segundo. Hasta 22 pginas por minuto y la primera pgina en slo 17 segundos. Deposicin de iones. Con una velocidad aproximada de operacin de 30-150 pginas por minuto. Lser. Con una velocidad aproximada de operacin de 8-215 pginas por minuto. Las impresoras lser estn compuestas por una amplia gama de velocidades, la aceleracin de la impresora lser se mide en ppm o en ipm. En las impresoras dobles reduce la velocidad de impresin a la mitad. Las impresoras lser a color son un caso especial el medir la velocidad, cada color requiere un paso separado a travs del mecanismo de impresin, debido a que casi todas las impresoras lser trabajan con cuatro colores can, magenta, amarillo y negro.

Estas pueden imprimir en blanco y negro y a color. Al imprimir en color las impresoras corren a un cuarto de su velocidad en impresin blanco y negro, o sea una impresora a color que imprime a 30 ppm en blanco y negro, correra aproximadamente a 7,5 ppm en color. Algunas impresoras mas rpidas de produccin pueden imprimir en hojas individuales a 135 ppm., algunos especializaron impresoras que usan papelera continua que pueden imprimir a 200 ppm Trmicas. Una cabeza mvil presenta una matriz de puntos, que pueden calentarse por la accin de resistores. Los puntos calientes forman el caracter a imprimir, y al ser aproximados al papel termo sensible, lo imprimen por calor, resultando una formacin de puntos ms oscuros. El controlador determina qu resistores se calentarn, ordenando la circulacin de corrientes elctricas por los mismos. Se trata de una impresin por formaciones de puntos, como en la impresora de matriz de agujas, pero al no percutir la matriz sobre el papel resulta un funcionamiento totalmente silencioso. Por no existir vibraciones mecnicas se simplifica el diseo del sistema resultando econmico, aunque por otra parte el costo del papel termo sensible es relativamente elevado. La calidad de la impresin est determinada por la densidad de los puntos la que ser limitada horizontalmente por la velocidad de barrido de la cabeza y verticalmente por el tamao del resistor. La disminucin del consumo posibilita versiones porttiles con bateras. Estas impresoras tienen una velocidad de impresin comparable impresoras de caracteres ms lentas. Impresoras electrostticas. Consisten en un tambor cilndrico, con superficies de selenio, donde la carga elctrica de las mismas est controlada por la intensidad de un haz de luz incidente. Dicho haz , modulado por la seal recibida por el controlador, realiza un barrido del rea del tambor. La distribucin de cargas sobre cada superficie ser proporcional a la intensidad del haz modulado. Los distintos puntos, cargados elctricamente, atraern el tonner, cargado en forma similar al de una fotocopiadora. El tambor transfiere luego el tonner al papel, para reproducir la imagen a travs de la aplicacin de presin y calor. Graduando el voltaje aplicado se pueden obtener desde puntos finos y brillantes hasta puntos ms opacos, logrndose muy buenos grisados. a las

La calidad de impresin de las copias depende, en gran medida, del papel. Se pueden lograr velocidades del orden de centenares de pginas por minuto. Se debe considerar la salida en pelcula, microfilmes o microfichas cuando es grande la cantidad de papel necesaria para hacerlo pues reduce costos a una tercera parte. Los sistemas de informacin producen formas especiales como la forma preimpresa. Est diseada para incluir smbolos especiales y marcas registradas de la organizacin y que se imprime con varios colores. Algunas formas tienen un formato tradicional que permanece sin cambios, son preimpresas con la finalidad de mantener caractersticas estndares, algunos ejemplos tpicos: facturas, cheques, notas de mostrador, etc. Se deben considerar este tipo de formas preimpresas en las siguientes situaciones: Reglamentos o requerimientos legales que obligan al uso de formas preimpresas. Destinatarios que esperan un formato estndar La inclusin del logotipo de la organizacin, una marca registrada o smbolo que debe incluirse en la forma. Trabajo artstico o grficas que tendrn mejor apariencia si se preimprimen. Las organizaciones necesitan a menudo ms de una copia de un reporte o documento, existen las copias sin papel carbn (hojas con recubrimiento especial en su parte trasera) y las copias con papel carbn. Las primeras tienen un costo ms alto pero tienen la ventaja de no requerir de tiempo o equipo extra para retirar el papel carbn. Si la empresa emplea rastreadores pticos capaces de leer formas impresas o escritas a mano, entonces el sistema puede preparar una proposicin en un documento u otra forma para utilizarla como documento de retorno, salida que ms adelante regresar como documento de entrada. Un ejemplo tpico es cuando una compaa prepara sus estados de cuenta por cliente, elabora su estado de cuenta y lo enva por correo; el cliente cuando efecta el pago regresa una parte de dicho estado de cuenta junto con el pago, este documento de retorno se puede rastrear y leer por el sistema eliminando los pasos de preparacin para la factura.

La plantilla de salida es la distribucin de objetos en el medio de salida. La plantilla es el prototipo que conducir ms adelante a la elaboracin de los programas durante el proceso de desarrollo. La plantilla debe mostrar la localizacin y posicin de la informacin variable (detalles, resmenes y totales, marcas de control, separadores) as como los detalles preimpresos o informacin constante (encabezados, ttulos y nombres del documento, nombre de la compaa y direccin, instrucciones, notas y comentarios). En este aspecto, la salida puede ser impresa en innumerables tipos y tamaos de papel y su restriccin es el costo (formas preimpresas, a varias tintas, de varias copias con carbn o de transferencia sin carbn). Un conjunto comn de convenciones describen los detalles de la salida. La notacin utilizada incluye: informacin variable e informacin constante. La informacin numrica puede presentarse bajo varios formatos que indican dnde colocar comas, la supresin de ceros, la insercin de smbolos, etc. Las plantillas de los reportes pueden formarse a partir de las plantillas de pantallas, con herramientas CASE o de otro tipo. Debe contener: encabezados, nmero de pgina, fecha, encabezados, datos y detalles resmenes de informacin. Pasos para la preparacin de la hoja impresa. Determinar la necesidad del reporte, los usuarios y los conceptos de datos a ser impresos. Estimar la cantidad de espacios necesarios y decidir el tamao general del reporte. Darle ttulo al reporte, numerar las pginas, incluir fecha de preparacin, etiquetar columnas de datos. Definir la lnea de detalle para los datos variables, indicar la posicin de los totales. Revisar prototipos del reporte con los usuarios y programadores para factibilidad, utilidad, legibilidad, comprensin y atractivo esttico. de la informacin que aparecer bajo los encabezados,

Diseo de salida en pantalla. La mayora de los principios anteriores se aplican a la salida en pantallas pero debe tomarse en cuenta que se tiene un espacio menor de trabajo y el usuario requiere instrucciones sobre cmo utilizar la pantalla. Cada pgina de presentacin visual recibe el nombre de pantalla o panel y su diseo comienza con la verificacin de las caractersticas de la pantalla de presentacin visual: Dimensiones fsicas de la pantalla. Nmero de renglones y columnas de datos que pueden ser mostrados al mismo tiempo. Grado de resolucin (alta, mediana o baja) Nmero de colores disponibles (monocromtico, tres colores, ocho colores, etc.) Mtodos de realce (subrayado, negritas, parpadeo, diferentes intensidades) Mtodos para el control de la intensidad (alta/baja, normal/inversa) Las pantallas tienen por lo general 80 columnas con 24 o 25 lneas, en algunos casos las terminales de punto de venta y computadoras porttiles tienen dimensiones ms pequeas.

3-esquina

4-esquina

5-cuadrante superior izquierdo 1-centro

2-lnea horizontal central

3-esquina

2-lnea vertical central

4-esquina

Escape al men de formatos de pantalla

Nota: la parte superior izquierda es la parte ms visible de la pantalla. Secciones de una pantalla.

Lnea de estado

Ventana principal Ventana de banderas (30 columnas) Ventana de 80 columnas

Men de escape

Ubicacin efectiva de la informacin sobre pantalla La informacin que indica a los usuarios cmo seguir se muestra generalmente en la parte inferior de la pantalla, tambin debe instruir al programador para que escriba el software en una forma que si se presiona otra tecla puede causar error. Con frecuencia se emplean varias pantallas para dar la informacin que necesitan y permite a los usuarios recorrer con rapidez todos los detalles e identifican la informacin precisa. Las ventanas son subdivisiones de la pantalla y hacen posible presentar al mismo tiempo diferentes conjuntos de salida, los usuarios manejan multitarea2 y presentar la salida de cada programa en una ventana o presentar ms de una salida al mismo tiempo. El uso de ventanas debe considerarse cuando: Se presentan datos diferentes o conjuntos de reportes al mismo tiempo. Para cambiar entre varios programas, mostrando la salida de cada uno de ellos. Mover informacin de una ventana a otra (dentro del mismo programa o entre programas diferentes) Permitir que los usuarios reposicionen la informacin sobre la pantalla para adecuarla a sus necesidades particulares.

DISEO DE ENTRADA EFECTIVA. La calidad de un sistema determina la calidad de la salida del sistema. Una entrada pobre plantea preguntas sobre la confiabilidad del sistema completo, deben satisfacer los objetivos de efectividad, precisin, facilidad de uso, consistencia, simplicidad y atractivo. Consideraciones para el diseo de formas. Haga que las formas sean fciles de llenar Asegurarse de que las formas satisfacen el objetivo para el que fueron diseadas. Disear formas que aseguren el llenado preciso. Mantener las formas atractivas. Las formas deben fluir (flujo de llenado) de izquierda a derecha y de arriba hacia abajo. Debe contener: encabezado, identificacin y acceso, instrucciones, cuerpo, firma y verificacin, totales, comentarios. Disear formas atractivas y simples. La proteccin es importante considerarla debido a que es parte de la seguridad en la informacin de captura. Diseo de interfaz grfica de usuario El diseo de entradas es el enlace que une al sistema de informacin con el mundo y los usuarios. Algunos aspectos del diseo cambian, lo que depende de si el sistema est orientado hacia lotes o en lnea, pero existen aspectos generales que se deben tomar en cuenta. Objetivos del diseo de la entrada. Consiste en el desarrollo de especificaciones y procedimientos para la preparacin de datos, la realizacin de los pasos necesarios para poner los datos de una transaccin en una forma utilizable para su procesamiento, as como la entrada de los datos. Los objetivos en el diseo de entradas son: a) Control de la cantidad de entrada. Disminuir los requerimientos de datos pueden reducir los costos y al disminuir los requerimientos de la entrada, el analista puede acelerar el proceso general desde la captura de datos hasta los resultados finales.

b) Evitar los retrasos. Evitar los cuellos de botella, utilizando documentos de retorno y otras formas para evitar los retrasos en el procesamiento. c) Evitar los errores en los datos. El analista puede reducir el nmero de errores al disminuir el volumen de datos que deben ingresarse por cada transaccin y la forma en que se deben ingresar dichos datos. Las verificaciones y balances en los programas para entrada de datos (tcnicas de validacin de entradas), descubren errores en la entrada. d) Evitar los pasos adicionales. Cuando no es posible reducir el volumen de transacciones, el analista debe asegurar que el proceso sea lo ms eficiente posible; evitar diseos para la entrada que tengan como consecuencia procesos adicionales innecesarios. e) Mantener la sencillez del proceso. La simplicidad evita confusin y multiplicidad de errores en captura, el utilizar un gran nmero de controles puede generar dificultades al emplear el sistema. Lineamientos para la captura de datos. Existen dos tipos de datos que deben considerarse cuando se procesan transacciones: a) Datos variables. Aquellos datos que cambian para cada transaccin o toma de decisin como la identificacin de un artculo en el inventario por ejemplo. b) Datos de identificacin. Es el dato que identifica en forma nica el artculo que est siendo procesado (denominado llave), por ejemplo, el dato de identificacin de una lista de proveedores. Los procedimientos de entrada no deben requerir lo siguiente: a) Datos constantes. Datos que son los mismos para cualquier transaccin. b) Detalles que el sistema puede recuperar. Son los datos almacenados que el sistema puede recuperar con rapidez de sus archivos (por medio del campo llave). c) Detalles que el sistema puede calcular. Son los resultados que se pueden producir al pedir que el sistema utilice combinaciones de datos almacenados y proporcionados.

DISEO DE ARCHIVOS O BASES DE DATOS. Se considera la parte medular de los sistemas de informacin y tiene como objetivos: la integridad de datos, disponibilidad de datos, actualizacin y recuperacin eficiente, almacenamiento de datos eficiente, recuperacin de informacin para un propsito especfico. Archivos convencionales. Un archivo puede ser diseado y construido muy rpidamente y las preocupaciones sobre disponibilidad y seguridad son minimizadas, cuando los diseos de archivos estn cuidadosamente planeados se puede incluir toda la informacin necesaria y el riesgo de omitir datos intencionalmente ser bajo. La velocidad de procesamiento es otra ventaja del uso de archivos, pero tiene inconvenientes: la falta de potencial para que evolucionen los archivos, cuando se requiere consultar el sistema para una combinacin de algunos atributos posiblemente puedan estar contenidos en otro archivo o no existir, el rediseo implica frecuentemente que los programas que accedan los archivos deban ser vueltos a escribir. Un sistema que usa archivos convencionales implica que los datos guardados sern redundantes. Bases de datos. Es una fuente central de datos que est pensado para que sea compartida por muchos usuarios con una diversidad de aplicaciones. La parte medular es el DBMS (sistema de manejo de base de datos) que permite la creacin, modificacin y actualizacin de la base de datos, la recuperacin de datos y la generacin de reportes. Tiene como objetivos: compartir informacin entre una diversidad de aplicaciones, mantener datos precisos y consistentes, asegurar que los datos requeridos para las aplicaciones actuales y futuras estn fcilmente disponibles, permite que la base de datos evolucione y que las necesidades de los usuarios crezcan, permite que los usuarios construyan su vista personal de los datos sin preocuparse de la forma en que estn fsicamente guardados los datos. Tipos de archivos. a) Archivo maestro. Es un conjunto de registros acerca de un aspecto importante de las actividades de una organizacin. Puede contener datos que describan el estado actual de eventos especficos o indicadores de la empresa (un sistema de pagos de cuenta muestra el estado actual de todas las cuentas de la organizacin).

Puede reflejar la historia de los eventos que afectan a una entidad particular (la historia de ventas de una empresa comercial se refleja al contener registros de cada venta hecha a un cliente en un periodo especfico). Estos archivos son permanentes y duran mientras exista el sistema, sin embargo cambia su contenido como resultado del procesamiento y actualizacin. b) Archivos de transacciones. Archivo temporal con dos propsitos: acumular datos acerca de los eventos al momento que ocurran y actualizar los archivos maestros para reflejar los resultados de las transacciones actuales. Son archivos temporales, se destruyen en cuanto ya no son necesarios, pueden durar meses o incluso aos. c) Archivo de tablas. Es un tipo de archivo maestro para cubrir requerimientos especiales de procesamiento con respecto a datos que deben referenciarse repetidamente. Estos archivos contienen datos de referencia utilizados en el procesamiento de transacciones, actualizacin de los archivos maestros o produccin de salida. Conservan datos el especio de almacenamiento y facilitan el mantenimiento del programa guardando en un archivo datos que, de otro modo, se incluiran en los programas o registros del archivo maestro. d) Archivo de reportes. El CPU frecuentemente produce datos de salida a una velocidad ms rpida de lo que la impresora puede retener y si se sigue la secuencia normal de los eventos, habra que retrasar el procesamiento mientras que se imprimen los resultados. Los archivos de reportes son archivos temporales que se utilizan cuando el tiempo de impresin no est disponible para todos los reportes producidos. La computadora escribe el reporte o documento en disco donde permanece hasta que pueda imprimirse, ya sea en la impresora, en un graficador, en unidades de microfilm y microficha o sistemas tipogrficos comerciales. e) Otros. Entre estos se pueden considerar los archivos de respaldo el cual, es una copia de un archivo maestro, de transaccin o de tabla hecho para garantizar que se dispone de un duplicado si algo le ocurre al original. Mtodos de organizacin de archivos. Los registros se almacenan en archivos, utilizando una organizacin que le permite almacenarlos, localizarlos y recuperarlos.

a) Organizacin secuencial. Almacena los registros uno tras otro sin importar el valor real de los datos en los registros. No existen posiciones sin uso, no existen direcciones ni asignaciones de lugar en los archivos secuenciales, no utilizan llave de registro. Una de sus principales desventajas es la localizacin de un registro en un archivo muy grande, debido a que consume mucho tiempo en la bsqueda. Al leer el archivo, el sistema comienza siempre por el primer registro, leyndolos uno a la vez hasta llegar al registro deseado3 (no se puede ir directamente al registro buscado).

b) Organizacin de acceso directo. Este mtodo pide al programa que diga al sistema dnde se almacena un registro antes de poderlo acceder, no requiere que se realice la bsqueda secuencial. Son archivos con llave, asocian un registro con un valor especfico y un lugar particular de almacenamiento. Ejemplo: se desea almacenar un cheque cuyo nmero es el 1248; el sistema utiliza este nmero como la llave de registro fsico, por lo tanto se almacena en la direccin 1248; el programa se instruye para que utilice el nmero de cheque como la llave de bsqueda y va directamente al lugar asignado para el registro y recupera el archivo. 1. El uso de la llave del registro como la direccin de almacenamiento se llama direccionamiento directo, es un mtodo simple y rpido. Para cada valor llave existe un espacio de almacenamiento con una direccin que es equivalente a la llave, los valores llave estn tambin en una secuencia cerrada, pero los valores no utilizados en el rango de los valores de la llave provocan un desperdicio en el espacio de almacenamiento. Otro problema surge cuando las llaves para los registros no coinciden con las direcciones de almacenamiento, por ejemplo, si las llaves contienen caracteres alfabticos no es posible el direccionamiento directo ya que no existe una direccin para estos caracteres. 2. Direccionamiento por hashing (transformacin de llaves o aleatorizacin). Se utiliza cuando se requiere un acceso directo pero no es posible.

Es el proceso de obtener una direccin de almacenamiento a partir de un campo llave; se disea un algoritmo para transformar el valor de la llave en otro valor que sirva como una direccin de almacenamiento (el valor de los datos en el registro no cambian). Algunos mtodos comunes para este tipo de direccionamiento son: Doblez, divide la llave en partes y se le contina procesando (suma, resta, divisin, etc.). Extraccin, se eligen dgitos especficos de la llave y se les procesa con los dgitos restantes. Elevar al cuadrado, se multiplica el nmero por s mismo y entonces se aplican otros mtodos de hashing. Estos algoritmos deben tener: posibilidad de repeticin, distribucin uniforme, minimizar sinnimos. c) Organizacin indexada. Incluye una llave de registro y la direccin de almacenamiento de un registro; para hallar un registro cuando se desconoce la direccin de almacenamiento se debe examinar los registros; sin embargo, la bsqueda se facilita al utilizar un ndice. Un ndice es un archivo aparte del archivo maestro y cada registro en el ndice contiene nicamente dos datos: una llave de registro y una direccin de almacenamiento. Para localizar un registro se busca primero el ndice para hallar la llave del registro deseado.

La organizacin indexada se presenta en: No secuencial y Secuencial (ISAM). En la no secuencial, el archivo no tiene ningn orden especfico, existe un registro en el ndice por cada registro en el archivo maestro. En la secuencial, se crea un archivo seudosecuencial donde los registros se almacenan en bloques con capacidad de una cantidad especfica de datos. No requiere un ndice para cada registro, solo necesita los valores mximo o mnimo de todos los registros en un bloque, es decir, slo un ndice es necesario para cada bloque.

DISEO DE LA INTERFAZ DEL USUARIO. Es la categora de diseo que crea un medio de comunicacin entre el hombre y la mquina, identifica los objetos y acciones de la interfaz y crea un formato de pantalla que formar la base del prototipo de interfaz de usuario., permite disminuir considerablemente errores o frustracin de los usuarios. Deben lograrse los siguientes objetivos: efectividad lograda por medio del diseo de interfaces que permitan a los usuarios acceder el sistema de forma congruente con sus necesidades; efectividad mostrada por medio de interfaces que aumenten la velocidad de la captura de datos y reduzcan errores; demostrar consideracin al usuario diseando interfaces adecuadas y que el sistema les proporcione la realimentacin adecuada; productividad mostrada por su adecuacin a los principios ergonmicos establecidos en el diseo de interfaces y espacios de trabajo para los usuarios. Tipos de interfaz. Interfaz de lenguaje natural, interfaz de preguntas y respuestas, mens, interfaz de llenado de forma (formas de entrada/salida), interfaz de lenguaje de comandos, interfaz grfica de usuario (GUI). Realimentacin para usuarios. Permite monitorear y cambiar el comportamiento de los sistemas, es necesaria la realimentacin al usuario por parte del sistema en ciertas situaciones tales como: reconocimiento de la aceptacin de la entrada, reconocimiento de que la entrada est o no est en la forma correcta, explicacin sobre una espera de procesamiento, reconocimiento de que una peticin esta completa, notificacin de que una peticin no ha sido terminada, proporcionar al usuario realimentacin mas detallada, opciones de ayuda.

DISEO A NIVEL DE COMPONENTES. Consiste en convertir el diseo de datos, interfaces y arquitectura en un software operacional, l diseo a nivel de componentes establece los datos algortmicos que se requieren para manipular las estructuras de datos, efectuar la comunicacin entre los componentes del software por medio de las interfaces e implementar los algoritmos asignados a cada componente. Permite determinar si el programa funcionar antes de construirlo, representa el software que permite revisar los datos del diseo para su correccin y consistencia con las representaciones de diseo anteriores.

1.2.5. PRUEBA DEL SISTEMA.

Todos los programas de un sistema, as como manuales de procedimientos, hardware y las interfaces de sistema deben ser probadas extensamente. Las pruebas se realizan a lo largo del desarrollo del sistema y no simplemente al final y ayuda a asegurar la calidad del sistema eventual. La prueba se realiza en subsistemas o mdulos de programa conforme el trabajo avanza, se hace en muchos niveles diferentes y a diversos intervalos. Antes de que el sistema sea puesto en marcha, todos los programas deben ser probados en el escritorio, revisados con datos de prueba y revisados para ver si los mdulos trabajan juntos entre ellos como se plane. Se manejan varios tipos de pruebas: a) Prueba de programas con datos de prueba. En esta etapa, los programadores prueban sus programas en escritorio para verificar la forma en que el sistema trabajar siguiendo cada paso del programa en papel para revisar si la rutina trabaja como fue escrita. Posteriormente deben crear datos de prueba vlidos e invlidos para ver si trabajan las rutinas bsicas y detectar errores. Si la salida de los mdulos principales es satisfactoria se pueden aadir ms datos de prueba para revisar otros mdulos. Los datos deben probar valores mnimos y mximos. Se deben revisar cuidadosamente los archivos de salida de los datos de prueba. b) Prueba de enlace con datos de prueba. Se le denomina prueba en cadena. Revisa si los programas que son interdependientes trabajan como se plane. Una pequea cantidad de datos de prueba, diseados por lo general por el analista de sistemas para probar las especificaciones del sistema y los programas, se usan para esta prueba. La prueba de todas las combinaciones puede llevarse varios pasos a travs del sistema, debido a que es difcil descubrir los problemas si se trata de probar todo en una sola vez. El analista crea datos de prueba especiales que cubren una diversidad de situaciones de procesamiento para la prueba de enlace, datos para las transacciones normales, variaciones, datos invlidos, etc.

c) Prueba completa del sistema con datos de prueba. En esta epata, los operadores y usuarios finales llegan a estar activamente involucrados en la prueba, se usan datos creados por el equipo de anlisis para el propsito de probar los objetivos del sistema e incluye la reafirmacin de los estndares de calidad para el desempeo del sistema. Incluye mediciones de error, oportunidad, facilidad de uso, ordenamiento adecuado de transacciones, aceptable tiempo cado, manuales de procedimientos comprensibles, etc. d) Prueba completa del sistema con datos reales. Los datos reales son datos que han sido procesados satisfactoriamente usando el sistema existente. Este paso permite una comparacin precisa de la salida del nuevo sistema con la que se sabe que es salida correctamente procesada, as como una buena sensacin de cmo sern manejados los datos reales. Los conceptos a observar son: la facilidad de aprendizaje del sistema, el ajuste a factores ergonmicos y la reaccin del usuario a la realimentacin del sistema, incluyendo lo que sucede cuando se recibe un mensaje de error y lo que sucede cuando al usuario se le informa que el sistema est ejecutando sus comandos. Tipos de pruebas Un caso de prueba es un conjunto de datos que el sistema procesar como entrada normal, sin embargo, los datos se crean con la intencin de determinar si el sistema los procesar correctamente. Existen dos estrategias generales para la prueba del software: a) Prueba de cdigo. Examina la lgica del programa; el analista desarrolla casos de prueba que produzcan la ejecucin de cada instruccin en el programa o mdulo, es decir, prueba cada ruta del programa. Una ruta es una combinacin especfica de condiciones manejadas por el programa. Las consideraciones financieras y las limitaciones de tiempo impiden la ejecucin de cada ruta dentro de un programa ya que puede haber varios miles de ellas. Esta prueba no es una garanta en contra de las fallas del software, no indica si el cdigo cumple sus especificaciones ni tampoco determina si todos los aspectos han sido implantados., no verifica el rango de los datos que aceptar el programa aunque al ocurrir fallas de software en su uso real suele ser frecuente debido a que los usuarios pueden introducir datos fuera de los rangos esperados.

b) Pruebas de especificacin. El analista debe examinar las especificaciones que sealan lo que el programa debe hacer y cmo lo debe llevar a cabo bajo diferentes condiciones, esto pretende determinar si el programa funciona de acuerdo con los requerimientos especificados. Trata al programa como si fuera una caja negra: el analista no mira dentro del programa para estudiar el cdigo y no le interesa si se prueba cada instruccin o ruta dentro del programa. No es una prueba completa, sin embargo, si se cumplen las especificaciones se considera que no fallar. Independientemente de la estrategia utilizada por el analista, hay ciertas prcticas para garantizar que la prueba sea til. Los niveles de prueba y los tipos de datos de prueba, junto con las bibliotecas de prueba, son aspectos importantes del proceso real de prueba. Los sistemas no se disean como sistemas completos ni tampoco se prueban como sistemas nicos; por ello, el analista debe considerar llevar a cabo tanto pruebas parciales como las del sistema. Pruebas parciales. En estas pruebas, el analista prueba los programas que conforman a un sistema. Se centran primero en los mdulos, independientes entre s, para localizar errores; esto permite detectar errores en el cdigo y lgica contenidos dentro de ese nico mdulo. Los casos de prueba necesarios para estas pruebas deben probar cada condicin u opcin. Si el mdulo recibe una entrada o genera una salida, tambin se necesitan casos de prueba para examinar el rango de valores esperado, incluyendo los datos vlidos e invlidos. Si el mdulo se disea para llevar a cabo iteraciones, con procesos especficos contenidos dentro de un ciclo, es recomendable ejecutar cada condicin frontera (cero iteraciones, una iteracin en el ciclo y el mximo nmero de iteraciones en el ciclo) Se pueden llevar a cabo en forma ascendente, comenzando con los mdulos ms pequeos y de nivel inferior y continuando de uno en uno. Para cada mdulo en la prueba ascendente, un programa corto ejecuta el mdulo y proporciona los datos necesarios, de esta forma se pide que el mdulo se desempee en la forma en que lo hara al encajarse dentro del sistema.

La prueba descendente,empieza con los mdulos de nivel superior, sin embargo, no se tienen las actividades detalladas de los niveles inferiores. El mdulo superior solo recibe el resultado del mdulo inferior sin verificar si ste es correcto. Prueba de sistemas. No prueba el software en s, sino la integracin de cada mdulo en el sistema. Busca las discrepancias entre el sistema y su objetivo original, especificaciones y documentacin del sistema. Los analistas tratan de hallar reas en donde los mdulos hayan sido diseados con especificaciones distintas para la longitud y tipo de datos y los nombres de los elementos de los datos. Debe verificar que los tamaos de los archivos son adecuados y que los ndices se han construido en forma adecuada. Deben probar a nivel sistema los procedimientos de ordenamiento y reindexacin, que se supone estn presentes en los mdulos de nivel inferior, para ver que existen y logran los resultados esperados.

Pruebas especiales de sistemas. Tipo de prueba Prueba de carga mxima Descripcin Determinar si el sistema manejar el volumen de actividades que ocurran cuando el sistema est en el punto ms alto de su demanda de procesamiento. Prueba de almacenamiento Determinar la capacidad del sistema para almacenar datos de transacciones en un disco u otros archivos. Prueba de tiempo de ejecucin Determinar el tiempo de mquina que el sistema necesita para procesar los datos de una transaccin. Prueba de recuperacin Determinar la capacidad de uniusuario para recuperar los datos o restablecer el sistema despus de una falla. Prueba de procedimientos Determinar la claridad de la documentacin en los aspectos de operacin y uso de un sistema, haciendo que los usuarios lleven a cabo exactamente lo que el manual pide

Prueba de factores humanos

Determinar como utilizarn los usuarios el sistema al procesar datos o preparar informes.

Diseo de datos de prueba. Hay dos fuentes diferentes de datos de pruebas: reales y artificiales. a) Uso de datos de prueba reales. Los datos son extrados de los archivos de la organizacin, se utilizan estos datos para probar parcialmente el sistema. Es difcil obtener datos reales en cantidad suficiente para conducir una prueba extensa y aunque los datos reales mostrarn cmo funciona el sistema para los requerimientos tpicos de procesamiento, generalmente dichos datos no probarn todas las combinaciones o formatos que puedan entrar al sistema. b) Uso de datos de prueba artificiales. Se crean solamente con fines de prueba ya que se pueden generar para probar todas las combinaciones de formatos y valores. Los programas de prueba ms efectivos usan datos de prueba artificiales generados por personas distintas de las que escribieron los programas; frecuentemente un equipo independiente formula un plan de prueba usando las especificaciones del sistema. Bibliotecas de prueba. Una biblioteca de prueba es un conjunto de datos desarrollados para probar en su totalidad un sistema; se usa por todas las personas involucradas con un sistema particular. No solamente son para las pruebas iniciales, al evolucionar el sistema, modificarse y dar mantenimiento al programa debe volver a probarse. La biblioteca de prueba tiene que conservarse durante toda la vida de un sistema de forma que, al hacer cada cambio, se disponga nuevamente de datos confiables para probar el sistema.

1.2.6. IMPLANTACIN Y EVOLUCIN.

La implementacin es el proceso de primero asegurarse de que el sistema de informacin sea operacional y permitir que luego tomen los usuarios control de la operacin para su uso y evaluacin. La implantacin incluye todas aquellas actividades que tienen lugar para convertir del sistema anterior al nuevo. La adecuada implantacin es esencial para lograr un sistema confiable y que cumpla con las necesidades de la organizacin; una implantacin exitosa no garantiza el mejoramiento de la organizacin que use el sistema. Existen varios enfoques de Implementacin: Es darle responsabilidad a los grupos. Uso de diferentes estrategias para el entrenamiento de los usuarios. El Analista de Sistemas necesita ponderar la situacin y proponer un plan de conversin que sea adecuado para la organizacin. El Analista necesita formular medidas de desempeo con las cuales evaluar a los Usuarios. Debe Convertir fsicamente el sistema de informacin antiguo, al nuevo modificado. En la preparacin de la Implantacin, aunque el Sistema este bien diseado y desarrollado correctamente su xito depender de su implantacin y ejecucin por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento. El analista de sistemas tiene varios enfoques para la implementacin, estos incluyen darle ms poder de cmputo a los usuarios va un centro de informacin y/o procesamiento distribuido, capacitacin de usuarios, conversiones a partir del sistema antiguo y evaluaciones del nuevo. El primer enfoque para la implementacin se refiere al movimiento del poder de cmputo a usuarios individuales, poniendo un centro de informacin (IC) o dndole poder de cmputo y responsabilidad a los grupos a lo largo del negocio con la ayuda de la computacin distribuda.

Otro enfoque es el uso de diferentes estrategias para el entrenamiento de los usuarios y el personal del centro de informacin, asegurndose de que cada usuario comprenda cualquier papel nuevo que deba desempear debido al nuevo sistema. Otro enfoque es la seleccin de una estrategia de conversin que sea adecuado para la organizacin particular del sistema. Un enfoque ms involucra la evaluacin del sistema nuevo o modificado o el centro de informacin. Los analistas se involucran en un proceso educacional con los usuarios llamado capacitacin. En la implementacin de grandes proyectos, el analista estar frecuentemente analizando la capacitacin en vez de estar personalmente involucrado. Estrategias de capacitacin. Son determinadas por quin est siendo capacitado y quin lo capacitar. Se debe capacitar a todas las personas que tendrn uso primario o secundario del sistema, desde el personal de captura hasta aquellos que usarn la salida para tomar decisiones sin usar personalmente una computadora. El tiempo de capacitacin depende de qu tanto cambiar el trabajo de alguien debido al nuevo sistema. Los usuarios de diferentes niveles, habilidades e intereses de trabajo, deben estar separados. Para un proyecto grande, se pueden usar muchos instructores diferentes, dependiendo de qu tantos usuarios deben ser capacitados y quines son. Objetivos de la capacitacin. Los objetivos de la capacitacin son dictados por quienes son capacitados, los objetivos bien definidos son una gran ayuda para permitir que los capacitados sepan lo que se espera de ellos y permiten una evaluacin adecuada. La capacitacin se realiza en diferentes ubicaciones pudiendo ser fuera o dentro del lugar donde operar el sistema. Una desventaja de la capacitacin fuera de sitio e que los usuarios estn alejados del contexto de la organizacin dentro de la cual deben existir eventualmente. La capacitacin en sitio tiene como ventaja que los usuarios ven el equipo puesto en donde estar cuando sea completamente operacional, una desventaja es que los capacitados a veces se sienten culpables de no cumplir con sus labores de trabajo normales si permanecen en el sitio para la capacitacin.

Conversin. Es el proceso de cambiar el sistema anterior al nuevo y los procedimientos empleados para asegurarse que se lleva a cabo adecuadamente. Mtodos de conversin. Mtodo Sistemas paralelos Descripcin Ventajas Desventajas

El sistema anterior se Ofrece la mxima seguridad. Duplica los costos de opera junto con el Se puede recurrir al sistema operacin. El nuevo nuevo. anterior si se hallan errores sistema puede no ser en el nuevo o si ocurren juzgado justamente. problemas de uso

Conversin directa

El sistema anterior se Obliga a los usuarios a que No hay otro sistema al reemplaza nuevo. organizacin por el haban trabajar el nuevo cual recurrir si surgen La sistema. Hay beneficios dificultades con el

confa inmediatos de los nuevos nuevo. Requiere de la ms planeacin. una Proporciona experiencia y Puede dar la cuidadosa

completamente en el mtodos y controles. nuevo sistema. Enfoque piloto Se implanta

versin de trabajo del prueba directa antes de la impresin de que el sistema en una parte implantacin. de Con la organizacin. base en la se nuevo sistema no es confiable si est libre de errores.

retroalimentacin,

hacen cambios y el sistema se instala en el resto de la

organizacin mediante uno de los dems

mtodos. Por etapas Se implanta el sistema Permite de manera gradual a usuarios todos los usuarios. ventajas a los primeros Un largo periodo de las instalacin provoca la

aprovechar del

sistema. duda en el usuario de

Permite la capacitacin y la si el proyecto marcha instalacin sin uso bien (demasiado o mal

innecesario de recursos.

entusiasmo)

(resistencia y falta de un juicio justo).

Plan de conversin. Incluye una descripcin de todas las actividades que deben ocurrir al implantar el sistema nuevo y ponerlo en operacin. Identifica a las personas responsables de cada actividad e incluye un programa de actividades para indicar cundo debe llevarse a cabo cada una de stas. Debe anticipar los posibles problemas y la forma de enfrentarlos. El encargado de la conversin debe estar alerta ante la omisin de pasos en la conversin. Una lista de verificacin prevendr los pasos faltantes, tambin hay que esperar las faltas del personal y especificar los planes de emergencias adecuados. Acondicionamiento de las instalaciones. Se debe definir el acondicionamiento de las instalaciones tales como cableado elctrico, contactos, necesidades de aire acondicionado, controles de humedad, espacio. La distribucin en las instalaciones debe permitir un amplio espacio para mover el equipo y prepararlo para su operacin normal. Estos requisitos deben cumplirse o la garanta puede perderse e interrumpirse el mantenimiento hasta que sean satisfechas.

Preparacin de datos y archivos. Si se inicia un sistema de cero, los datos necesarios deben ser introducidos al sistema, dependiendo del nmero de personas que sean asignadas a esta tarea se requerir de 2 a 3 semanas para un sistema de tamao moderado (aproximadamente 7500 registros). Se sugieren controles tales como: Cuenta de registros que asegure que todos los registros fueron capturados. Totales financieros preestablecidos, el balance general antes de la conversin debe compararse con el balance del sistema nuevo al final de la conversin. Cifras de control (totales preestablecidos por hashing). La cifra de control calculada por el sistema para los registros introducidos deben coincidir con el total preestablecido. Situaciones relacionadas con la transmisin de datos. Asegurarse que cada transaccin enviada es recibida e incluida en los nuevos archivos, evitando prdida de datos.

Revisin despus de la implantacin. Despus de implantar el sistema y completar la conversin, se hace una revisin del sistema conducida igualmente por los usuarios y los analistas. Es importante para recabar informacin para el mantenimiento del sistema.

Seguridad. La seguridad en las instalaciones de computacin, los datos guardados y la informacin generada es parte de una conversin satisfactoria; aunque no hay un sistema totalmente seguro, las acciones que tomen los analistas y los usuarios se pretende que muevan al sistema hacia el lado seguro, disminuyendo la vulnerabilidad del sistema. Conforme ms gente de la organizacin obtenga mayor poder de cmputo, la seguridad llega a ser cada vez ms difcil y compleja. La seguridad es responsabilidad de todos aquellos que estn en contacto con el sistema y es slo tan buena como el comportamiento o poltica ms laxa en la organizacin. La seguridad tiene tres aspectos interrelacionados: fsica, lgica y de comportamiento.

a) Seguridad fsica. Se refiere a la seguridad de las instalaciones de computacin, su equipo y software por medios fsicos. Esto puede incluir el control del acceso al cuarto de la computadora por medio de gafetes, sistemas de registro/despedida humanos, uso de cmaras de televisin de circuito cerrado, respaldo de datos frecuente, almacenamiento de los respaldos en un rea a prueba de fuego y agua. El equipo de cmputo pequeo debe estar asegurado para que un usuario tpico no pueda moverlo y debe garantizar la corriente sin interrupciones. b) Seguridad lgica. Se refiere a los controles lgicos dentro del mismo software. Los controles lgicos familiares para la mayora de los usuarios son contraseas y cdigos de autorizacin de algn tipo. c) Seguridad de comportamiento. Las expectativas de comportamiento de una organizacin estn codificadas en sus manuales de poltica y hasta en signos puestos en tableros de noticias, cabe mencionar que el comportamiento que tienen internamente los miembros de la organizacin tambin es crtico para el xito de los esfuerzos de seguridad. Las polticas de seguridad deben ser escritas, distribuidas y actualizadas para que los empleados estn totalmente conscientes de las expectativas y responsabilidades. Se debe monitorear: la cantidad de intentos de registro no satisfactorio de usuarios, inventario peridico y frecuente de equipo y software, sesiones extraamente largas, acceso despus de horas de trabajo no tpico al sistema.

1.2.7. MANTENIMIENTO.
Hace casi 30 aos, se esperaba que lo que era inmediatamente visible fuera de verdad lo que haba, pero sabamos que una enorme masa de posibles problemas y costos yaca por debajo de la superficie. El mantenimiento del software existente puede dar cuenta de ms del 60% de las inversiones efectuadas por una organizacin de desarrollo y sigue ascendiendo a medida que se produce ms software. Gran parte del software del que dependemos en la actualidad tiene por trmino medio entre diez y quince aos de antigedad.

An cuando estos programas se crearon empleando mejores tcnicas de diseo y codificacin conocidas en su poca, se crearon cuando el tamao de los programas y el espacio de almacenamiento eran las preocupaciones principales; a continuacin se trasladaron a las nuevas plataformas, se ajustaron para adecuarlos a cambios de mquina y de sistemas operativos y se mejoraron para satisfacer nuevas necesidades del usuario, sin tener en cuenta la arquitectura global; como resultado se obtuvieron estructuras mal diseadas, mala codificacin, lgica inadecuada y escasa documentacin que ahora piden mantenimiento. Modelo de procesos de reingeniera del software. Es una actividad que absorbe recursos de las tecnologas de la informacin durante muchos aos. Es una tarea de reconstruccin y se comprende mejor si se considera una actividad anloga: la reconstruccin. Se definen 6 actividades: 1. Anlisis de inventario de las aplicaciones activas. 2. Reestructuracin de documentos. 3. Ingeniera inversa. Es el proceso de anlisis de un programa con nivel de abstraccin ms elevado que el cdigo fuente, es un proceso de recuperacin tomando del programa informacin del diseo arquitectnico y de proceso, e informacin de los datos. 4. Reestructuracin de cdigo. 5. Reestructuracin de datos. 6. Ingeniera directa (forward engineering)

1.3. ANLISIS ESTRUCTURADO.

Utiliza la combinacin de texto y de diagramas para representar los requisitos de datos, funciones y comportamientos, que es relativamente fcil de entender y ms importante an, sencillo para revisar su correccin, completitud y consistencia. Para validar los requisitos del software se necesita examinarlos desde diferentes puntos de vista, representa los requisitos en sus tres dimensiones y por ello se incrementa la probabilidad de encontrar errores, descubrir inconsistencias y detectar omisiones.

El anlisis estructurado se centraba en aplicaciones de sistemas de informacin y no proporcionaba una notacin adecuada para los aspectos de control y comportamiento de los problemas de ingeniera de tiempo real. En la actualidad se est intentando desarrollar una notacin consistente y se estn publicando tratamientos modernos que permitan acomodar el uso de herramientas CASE. El hecho de que dos analistas examinen una situacin en forma independiente, sin lineamientos o herramientas y tcnicas preestablecidos, recopilan informacin diferente para describir el sistema; esto conduce a la determinacin de diferentes requerimientos y puede o no el sistema satisfacer las necesidades de los usuarios. El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conducen al desarrollo de especificaciones para sistemas nuevos o para efectuar cambios a los ya existentes. Permite al analista conocer un sistema o proceso en una forma lgica y manejable. El anlisis de flujo de datos examina el empleo de los datos para llevar a cabo procesos especficos de la empresa dentro del mbito de una investigacin de sistemas.

1.3.1. ELEMENTOS DEL ANLISIS ESTRUCTURADO.

El modelo de anlisis debe lograr tres objetivos primarios: 1. Describir lo que requiere el cliente 2. Establecer una base para la creacin de un diseo de software. 3. Definir un conjunto de requisitos que se pueda validar una vez que se construye el software. En el centro del modelo se encuentra el diccionario de datos (un almacn que contiene definiciones de todos los objetos de datos consumidos y producidos por el software); rodean al ncleo tres diagramas diferentes: El diagrama entidad-relacin (DER) que representa las relaciones entre los objetos de datos, es la notacin que se usa para realizar la actividad de modelado de datos; los atributos de dada objeto de datos sealados en el DER se puede describir mediante una descripcin de objetos de datos.

El diagrama de flujo de datos (DFD) sirve para dos propsitos: proporcionar una indicacin de cmo se transforman los datos a medida que se avanza en el sistema y representar las funciones (y subfunciones) que transforman el flujo de datos. El DFD proporciona informacin adicional que se usa durante el anlisis del dominio de informacin y sirve como base para el modelado de funcin. En una especificacin de procesos (EP) se encuentra una descripcin de cada funcin presentada en el DFD. El diagrama de transicin de estados (DTE) indica cmo se comporta el sistema como consecuencia de sucesos externos. Para lograr esto, el DTE representa los diferentes modos de comportamiento (llamados estados) del sistema y la manera en que se hacen las transiciones de estado a estado. El DTE sirve como la base del modelado de comportamiento. Dentro de la especificacin de control (EC) se encuentra ms informacin sobre los aspectos de control del software. El modelo de anlisis acompaa a cada diagrama, especificacin, descripcin y al diccionario.

Desc. objetos de datos EP DE R DD DF D DT E

EC

Componentes del anlisis estructurado. a) Smbolos grficos.- conos y convenciones para identificar y describir los componentes de un sistema junto con sus relaciones.

b) Diccionario de datos.- descripciones de todos los datos utilizados en el sistema. Puede ser manual o automatizado. c) Descripcin de procesos y procedimientos.- declaraciones formales que emplean tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. d) Reglas.- estndares para describir y documentar el sistema en forma correcta y completa.

1.4. TCNICAS PARA ENCONTRAR HECHOS.

Muestreo. Es el proceso de seleccionar sistemticamente elementos representativos de una poblacin; Al examinarse, los datos revelaran informacin a cerca de la poblacin como un todo. Razones para aplicar el muestreo. a) Costos contenidos.- Evita utilizar gran cantidad de copias, papel, tiempo, etc... evitando gastos innecesarios. b) Agilizacin en la recoleccin de datos.- Recolecta datos seleccionados evitando el problema de anlisis de toda una poblacin. c) Mejora de la efectividad .- Mejora la efectividad al obtener informacin mas precisa, por ejemplo: hablar con menos empleados preguntndoles cuestiones ms detalladas. d) Reduccin de la ascendencia.- Se reduce la ascendencia en la recoleccin de datos cuando el analista entrevista a un ejecutivo de la corporacin que est involucrado con el proyecto. Cuando el analista pide opinin acerca de una caracterstica permanente del sistema, el ejecutivo puede proporcionar una evaluacin ascendente debido a que hay poca posibilidad de cambiarla. Determinacin de los datos a ser recolectados o descritos. El analista debe identificar las variables, atributos y conceptos de datos asociados que necesitan ser recolectados en la muestra; se deben considerar los objetivos del estudio y el tipo

de mtodo de recoleccin de datos. Si se recolectan datos irrelevantes, se desperdicia tiempo en la recoleccin, almacenamiento y anlisis de datos intiles. Determinacin de la poblacin a ser muestreada. El analista debe determinar cul es la poblacin. En el caso de datos relevantes debe decidir si son suficientes los 2 ltimos meses o los reportes de todo el ao; en cuando al personal a entrevistar se debe determinar si la poblacin debe incluir un nivel de la organizacin o todos los niveles e incluso decidir si avanzar al exterior del sistema para incluir la reaccin de los clientes. Seleccin del tipo de muestra. El analista cuenta con 4 tipos principales de muestra: de conveniencia, intencionada, aleatoria simple y aleatorio compleja. La Tabla 3 muestra las caractersticas de cada una de ellas.

De conveniencia

Son muestras no restringidas, no probables, la ms fcil de recolectar y la menos confiable. Ejemplo: cuando se publica una noticia en el boletn de la compaa pidiendo a los interesados asistir a una reunin para evaluacin.

Intencionadas

Se basa en el juicio del analista para seleccionar a aquellos que parezcan tener conocimiento e inters en el sistema. Se considera moderadamente confiable.

Aleatoria simple

Se obtiene una lista numerada de la poblacin para asegurar de que cada documento o persona tenga la misma oportunidad de ser seleccionado. No se considera muy prctica.

Aleatoria compleja

a)Muestreo sistemtico Es el mtodo

b)Muestreo estratificado c)Muestreo aglomerado

ms La ms importante. Es Selecciona un grupo de proceso de documentos o personas de a estudiar. Ejemplo:

simple. Tiene alto grado el

de periodicidad. Permite identificacin elegir entrevistar cada subpoblaciones

o elegir 1 o 2 bodegas de

ensima persona de la estratos para seleccionar 20 repartidas por el lista de empleados. algunos elementos. de sus pas, bajo la hiptesis de que son tpicas de las restantes. Tabla 3. Caractersticas de diferentes tipos de muestras. Decidir el tamao de muestra. Si todos en la poblacin vieran el mundo de la misma forma o se tuviera exactamente la misma informacin, sera suficiente un tamao de muestra de uno. Como esto no es real, se debe tener una muestra mayor de uno y menor que el tamao de la poblacin. Es importante considerar que la cantidad absoluta es ms importante que el porcentaje, se pueden obtener datos satisfactorios muestreando 20 personas de 200 20 de 2,000,000. El tamao de la muestra puede depende del analista, de la misma poblacin, del costo involucrado en el tiempo requerido, el tiempo disponible de las personas de la organizacin, etc.

1.4.1. ENTREVISTA.
Es considerada una conversacin dirigida con un propsito especfico que usa un formato de preguntas y respuestas. Tipo de informacin buscada: Opiniones.- estas pueden ser ms reveladoras que los hechos dado que el entrevistado conoce la organizacin debido a que pueden presentar el problema principal que el propietario quiere ver resuelto.

 Sentimientos.- el entrevistado conoce la organizacin y puede comprenderse la cultura de la misma y el grado de optimismo existente escuchando los sentimientos de quienes responden. Objetivos.- son informacin importante, los hechos que se obtienen pueden explicar el desempeo pasado pero los objetivos proyectan el futuro de la organizacin. Procedimientos informales. Planeacin de la entrevista. La preparacin de la entrevista se incluye en un rango de 5 actividades: Lectura de material de fondo.- Leer y comprender tanto como sea posible al entrevistado y la organizacin le permite construir un vocabulario comn que eventualmente, permitir redactar las preguntas de la entrevista en forma comprensible para el entrevistado, as mismo, se evita el perder tiempo preguntando asuntos generales. El material de lectura se puede obtener mediante una llamada rpida a la persona de contacto para solicitar reportes anuales actuales, cartas corporativas o publicaciones sobre la organizacin; se puede acceder a la biblioteca para informacin corporativa. Establecimiento de los objetivos de la entrevista.- Utilice la informacin obtenida y la experiencia para establecer los objetivos de la entrevista. Las reas sobre las cuales se querr hacer preguntas son: fuentes de informacin, formatos de la informacin, frecuencia de la toma de decisiones, cualidades de la informacin y estilo de la toma de decisiones. Decidir a quin entrevistar.- Incluya a gentes clave de todos los niveles que sern afectadas por el sistema, esto permitir obtener un balance en las necesidades a tratar. El contacto con la organizacin permitir tener algunas ideas sobre quin debe ser entrevistado. Prepare al entrevistado.- Llmele con anticipacin a la persona a ser entrevistada. Las entrevistas deben durar de 45 minutos a 1 hora, debido a que si se supera este tiempo, es probable que los entrevistados resientan la intrusin debido a que gastan el tiempo en la entrevista y no en su trabajo. Decida sobre tipos de preguntas y estructuras.- Elaborar preguntas para tratar las reas principales de la toma de decisiones, una vez fijados los objetivos de la entrevista.

 Estas preguntas pueden ser abiertas o cerradas; en cuanto a su estructura se puede elaborar en 3 patrones diferentes: estructura de pirmide, estructura de embudo o estructura de rombo. Tipos de preguntas. a) Abiertas.- considera las opciones del entrevistado para responder y no tienen un lmite especfico. Ventajas Desventajas

Pone confortable al entrevistado El hacer preguntas que puedan dar como resultado y permite espontaneidad. muchos detalles relevantes.

Permite conocer el vocabulario La posibilidad de perder el control de la entrevista. del entrevistado. El permitir respuestas que pueden llevarse

Proporciona riqueza de detalles. demasiado tiempo para la cantidad de informacin til Revela caminos para preguntas obtenida. posteriores. Pueden mostrar potencialmente la no preparacin

Permite una construccin de frases del entrevistador. ms fcil para el entrevistado. Pueden dar la impresin de que el entrevistador est de pesca sin un objetivo real. Ventajas y desventajas de las preguntas abiertas. b) Cerradas.- las posibles respuestas estn cerradas al entrevistado, solo puede responder con un nmero finito, tal como: ninguno, uno, quince, etc. Ventajas c) Se ahorra tiempo. d) Se facilita la comparacin de Desventajas i) Son aburridas para el entrevistado. las j) No llegan a obtener grandes detalles. k) Se pierden ideas principales por la razn anterior. l) No se llega a establecer una relacin

entrevistas. e) Se llega al punto.

f) Se mantiene control sobre la entrevista. g) Se tratan muchos temas rpidamente. h) Se obtienen datos relevantes.

armoniosa

entre

el

entrevistado

entrevistador.

Ventajas y desventajas de las preguntas cerradas. Abiertas Bajo Bajo Bajo Mucho Mucho Difcil Confiabilidad de los datos Uso eficiente del tiempo Precisin de los datos Anchura y profundidad Aptitud del entrevistador requerida Facilidad de anlisis Cerradas Alto Alto Alto Poco Poco Fcil

Cuadro comparativo de preguntas abiertas y cerradas. c) Averiguacin.- permite ir ms all de la respuesta inicial para obtener un significado ms amplio, claro y obtener el punto de vista del entrevistado. Pueden ser formuladas con preguntas abiertas o cerradas y se construyen con preguntas como: por qu?, puede darme un ejemplo?. Fallas en las preguntas. Preguntas conducentes.- tienden a dirigir al entrevistado hacia la respuesta, es decir, se sugiere la respuesta. Como ejemplo: Ha de estar usted de acuerdo con los dems gerentes de que el control de inventario debe estar computarizado, no es as?. Preguntas dobles.- son aquellas en las que se usa una sola pregunta para lo que de hecho son dos preguntas separadas, esto provoca que los datos proporcionados sean difciles de comprender. Como ejemplo: Qu decisiones toma durante un da tpico y cmo las toma?

Organizacin de las entrevistas. La estructura en la organizacin de las entrevistas se refiere al orden en el cual se ubican las preguntas a elaborar, en base a esto, se clasifican en: a) Estructura de pirmide.- se inicia con preguntas muy detalladas y frecuentemente cerradas para continuar su expansin al tema permitiendo preguntas abiertas y respuestas ms generalizadas. Se considera su utilizacin si el entrevistador necesita ambientarse en el tema o cuando se quiere una determinacin final acerca del tema. Ejemplo: Ejemplo en la utilizacin de la estructura piramidal.

Cul es exactamente el problema en su modelo de pronsticos?

Ha considerado obtener informacin ms actualizada? pronsticos? Qu es lo que usted piensa que podra hacer aqu ms efectivo el pronstico? En trminos generales, cmo se siente acerca de los pronsticos?

b) Estructura de embudo.- se inicia con preguntas generales y abiertas, estrechando las respuestas posibles con preguntas cerradas. Proporciona una forma fcil y no intimidante para comenzar una entrevista, es til cuando el entrevistado se siente interesado acerca del tema y necesita libertad para expresar sus emociones. El organizar la entrevista de esta forma puede elucidar tanta informacin detallada que son innecesarias las secuencias largas de preguntas cerradas y averiguaciones.

Ejemplo en la utilizacin de la estructura de embudo.

Cules son sus reacciones ante el nuevo sistema de cmputo? Qu computadoras usa? Cul es el costo del nuevo sistema de computadora? El nuevo sistema de computadora vale el costo?

c) Estructura de rombo.- es la combinacin de las dos estructuras anteriores, conlleva el comenzar en una forma muy especfica (preguntas cerradas), posteriormente examinar temas generales (preguntas abiertas) y por ltimo llegar a una conclusin muy especfica (preguntas cerradas). Tiene la desventaja de llevarse ms tiempo. Su ventaja principal es conservar el inters preguntas. Ejemplo en la utilizacin de la estructura de rombo. Cmo toma usted la decisin de distribucin? Piensa usted que puede ensear a alguien ms a tomar esta decisin? y la atencin del entrevistado por medio de una diversidad de

Qu se necesita para establecer reglas de decisin a fin de que otros pudieran beneficiarse de su experiencia? Son tiles las computadoras para tomar una decisin? Puede una computadora tomar esta decisin de distribucin? Entrevistas estructuradas y no estructuradas. No estructurada Atributos a considerar cuando se decide un formato de entrevista Estructurada

Difcil Evaluacin Fcil Alto Cantidad de tiempo requerido Bajo Muy necesario Entrenamiento requerido Limitado Mucho Permite espontaneidad Pequeo Mucha oportunidad Proporciona perspicacia del entrevistado Muy pequeo Grande Flexibilidad Pequeo Bajo Control del entrevistado Alto Bajo Precisin Alto Bajo Confiabilidad Alto Alto Amplitud y profundidad Bajo Atributos considerados para elegir el tipo de entrevista.

Registro de la entrevista Grabacin en cinta de audio y/o video Ventajas Proporciona un registro completo y preciso de lo que se dijo. Libera al entrevistador para escuchar y responder ms rpido. Permite mejor contacto visual y un mejor desarrollo de una relacin armnica entre entrevistado y entrevistador. Permite la reproduccin de la entrevista para otros miembros del equipo. Toma de notas Mantiene alerta al entrevistador. Ayudan a recordar preguntas importantes. Ayudan a recordar las

ascendencias importantes de la entrevista. Muestran el inters del

entrevistador en la entrevista. Demuestran la preparacin del entrevistador.

Desventajas El

hacer

posiblemente

inquietante

la

La prdida de contacto visual vital entre el entrevistado y entrevistador. La perdida del hilo de la conversacin. Se hace que el entrevistador

entrevista y menos apta para responder libremente. Puede hacer que el entrevistado sea menos apto para escuchar por la confianza de la grabacin. La dificultad de localizar pasajes

tema hablar cuando se est tomando notas. Hace que se ponga excesiva atencin a los hechos y poca atencin a los sentimientos y opiniones.

importantes en una cinta larga. El incremento de costo de recoleccin de datos por la necesidad de transcripcin.

Comparacin entre las formas del registro de la entrevista.

Estructura del reporte de la entrevista. Es imperativo la escritura del reporte de la entrevista, esto permite asegurar la calidad de los datos logrados haciendo notar los puntos principales de la entrevista y las opiniones personales. Entrevistado: Sal Domask Entrevistador: S. Cabbot Fecha: 3 de marzo Tema: Uso de computadoras Objetivos de la entrevista: Encontrar la actitud acerca del uso de la computadora; obtener la estimacin del usuario sobre el uso; encontrar opiniones de un nuevo sistema propuesto.

Se lograron los objetivos? Objetivos para la entrevista de seguimiento: Saber de qu manera Sal [enfoca] el soporte del departamento de sistemas. Encontrar opiniones sobre con quin platicar despus. Puntos principales de la entrevista: Opiniones del entrevistador: Sal dijo: La computadora es mi amiga Esta interesado en aprender ms acerca Usa la computadora todo el tiempo de cmo puede el sistema ayudarle con su No puede esperar hasta que ponga mis manos trabajo. Se siente aburrido si no trabaja en un sistema nuevo con la computadora. Ser un apoyador/facilitador entusiasta para un nuevo sistema. Ejemplo del reporte de una entrevista.

1.4.2. CUESTIONARIO.
Es una tcnica de recopilacin de informacin mediante una serie de preguntas por escrito, una de sus ventajas es que el entrevistador puede cuantificar informacin. Se pueden aplicar a una gran muestra de usuarios a la vez. Tipos de informacin buscada. Actitudes.- son lo que la gente de la organizacin dice que quiere. Creencias.- son lo que la gente piensa que es, de hecho cierto. Comportamientos.- es lo que hacen los miembros de la organizacin. Caractersticas.- son propiedades de las personas o cosas.

Planeacin de cuestionarios. Lineamientos de apoyo para decidir el uso de cuestionarios: Las personas a quienes necesita preguntarles estn ampliamente dispersas. En el proyecto de sistema est involucrada gran cantidad de personas y tiene sentido saber qu proporcin de un grupo dado aprueba/desaprueba una caracterstica particular del sistema propuesto. Se est haciendo un estudio exploratorio y se quiere medir la opinin general antes de darle al proyecto de sistema una direccin especfica. Se desea asegurarse de que cualquier problema con el sistema actual est identificado y atacado en las entrevistas de averiguacin. Tipos de preguntas. Preguntas abiertas Se debe prever la respuesta que se va a Cuando obtener. Debe ser lo suficientemente estrecha para Preguntas cerradas se sea capaz las de listar

efectivamente posibles.

todas

repuestas

guiar al interlocutor a que responda en una Cuando se pretende investigar una gran forma especfica. Se puede sugerir algunas caractersticas del sistema para recordarlas al interlocutor. Son tiles en situaciones exploratorias, cuando el analista no es capaz para determinar con precisin qu problemas existen con el sistema actual. Permiten enfocarse a los problemas citados. muestra.

Caractersticas de los tipos de preguntas. Abiertas Lento Alto Alto Fcil Difcil Velocidad de llenado Naturaleza exploratoria Amplitud y profundidad Facilidad de preparacin Facilidad de anlisis Cerradas Rpido Bajo Bajo Difcil Fcil

Comparativo de las caractersticas de los tipos de preguntas. Seleccin de palabras. Use el lenguaje del interlocutor siempre que sea posible, mantenga simple la redaccin. Trate de ser especfico en la redaccin, evite preguntas extremadamente especficas. Mantenga preguntas cortas. No menosprecie a los interlocutores hablndoles por medio de selecciones de lenguaje de bajo nivel. Evite la ascendencia en la redaccin y preguntas objetables. Dirija las preguntas a los interlocutores adecuados, no suponga demasiado conocimiento. Asegrese de que las preguntas sean tcnicamente precisas antes de incluirlas. Razones para las escalas en cuestionarios. Medir las actitudes o caractersticas de las personas que responden. Hacer que los interlocutores juzguen los temas del cuestionario.

Medicin. a) Nominal.- para clasificar cosas, son la forma ms dbil de medicin y se obtiene solamente totales de cada clasificacin. Debe usarse si el analista de sistemas quiere clasificar cosas pero no pueden ser jerarquizadas. Ejemplo: Qu tipo de programa utiliza principalmente? 1=Un procesador de palabras 2=Una hoja de clculo 3=Una base de datos 4=Un programa de graficacin b) Ordinal.- permiten clasificacin pero tambin implica ordenamiento de rango. Debe usarse cuando es imposible suponer que los intervalos son iguales, pero las clases tienen jerarqua. Ejemplo: El personal de soporte del centro de informacin es: 1. Excesivamente til 2. Muy til 3. Moderadamente til 4. No muy til 5. Intil c) De intervalo.- poseen la caracterstica de que los intervalos entre cada uno de los nmeros son iguales y se pueden realizar operaciones matemticas sobre los datos del cuestionario dando como resultado un anlisis ms completo. Debe usarse cuando puede suponerse que los intervalos son iguales, pero no hay cero absoluto. Ejemplo: Intil 1 2 3 4 Extremadamente til 5

d) De relacin.- son similares a las de intervalo en que se supone que el intervalo entre los nmeros es igual, sin embargo, estas escalas poseen un cero absoluto. Debe usarse cuando los intervalos son iguales y hay un cero absoluto. Aproximadamente, qu tantas horas pasa en la computadora diariamente? 0 Validez y confiabilidad. Validez es el grado con el cual la pregunta mide lo que el analista trata de medir; por ejemplo, si el objetivo de un cuestionario es determinar si la organizacin se encuentra lista para un cambio mayor en las operaciones de computadora. Confiabilidad mide consistencia. Si el cuestionario se aplica en dos ocasiones bajo las mismas condiciones y se obtuvieron los mismos resultados, se dice que se tiene consistencia externa. Si el cuestionario contiene subpartes y estas partes tienen resultados equivalentes, el instrumento tiene consistencia interna. Problemas en la construccin de escalas. a) Lenidad (blandura).- problema causado por interlocutores que califican a la ligera, se evita moviendo la categora promedio a la izquierda o derecha del centro. b) Tendencia central.- sucede cuando los interlocutores califican todo como promedio, se puede mejorar la escala haciendo: que las diferencias sean ms pequeas a ambos extremos; ajustando la fuerza de los descriptores y/o creando una escala con ms puntos. c) Efecto de halo.- sucede cuando la impresin formada en una pregunta se transporta a la siguiente pregunta, se puede evitar colocando un rasgo y varios empleados en cada pgina en vez de un empleado y varios rasgos en una pgina. Formato del cuestionario. Deje bastante espacio en blanco. Deje suficiente espacio para las respuestas. Pida al interlocutor que encierre las respuestas con un crculo o marque un cuadro creado por corchetes o parntesis. 2 4 6 8

 Sea consistente en estilo. Elija un orden de las preguntas favorable a los objetivos. Las preguntas importantes para los interlocutores van primero. Agrupe conceptos de contenido similar. Emplee tendencias asociativas de los interlocutores. Ponga primero los conceptos menos controvertidos. Interlocutores. Con apoyo del muestreo se puede determinar qu tipo de representacin es necesaria y por consiguiente, qu tipo de interlocutores deben recibir el cuestionario. Mtodos para administracin del cuestionario. Reunir a todos los interlocutores involucrados a la vez. Manejar personalmente cuestionarios en blanco y recoger los llenos. Permitir que los interlocutores administren el cuestionario por s mismos en el trabajo y lo depositen en una caja ubicada en un punto central. Enviar por correo los cuestionarios a los empleados de sucursales o sitios alejados y proporcionar fecha lmite de envo, instrucciones y el porte para el retorno.

1.4.3. REVISIN DE LOS REGISTROS.

Se refiere a examinar la informacin asentada en los registros de la organizacin relacionada con el sistema y los usuarios. Puede efectuarse como introduccin y/o como base para comparar las operaciones actuales. Los registros incluyen manuales de polticas, reglamentos y procedimientos estndares de operacin utilizados por la mayor parte de las organizaciones como guas para los gerentes y empleados. Al revisar los registros, el analista examina la informacin asentada en ellos relacionada con el sistema y los usuarios.

La revisin de los registros puede efectuarse al comienzo del estudio, como introduccin, o tambin despus, y sirve de base para comparar las operaciones actuales, por lo tanto los registros pueden indicar qu est sucediendo. Los registros incluyen manuales de polticas, reglamentos y procedimientos estndares de operacin utilizados por la mayor parte de las organizaciones como gua para los gerentes o empleados. Estos registros no indican la forma en la que se desarrollan las actividades en la realidad, donde se encuentra todo el poder de la toma de decisiones, o cmo se realizan todas las tareas. Normas y polticas determinadas. Deben ser documentados y sealadas todas las normas y polticas de la empresa segn fueron interpretadas por los directivos. Las normas y polticas pueden ser an ms desconocida o mal entendidas que los objetivos, por ello debe documentarse toda discrepancia encontrada al respecto durante la investigacin. Anexos. Durante la investigacin se deber recopilar toda forma preimpresa o reporte utilizado en el sistema, los cuales debern documentarse en relacin con el DFD. Si es posible, sealar en dichos ejemplares la informacin con que se llenan.

1.4.4. OBSERVACIN.
Mediante la observacin de las actividades de los tomadores de decisiones, el analista busca obtener una percepcin de lo que realmente se hace y no slo de lo que est documentado o explicado. El analista intenta ver de primera mano las relaciones que existen entre stos y los dems miembros de la organizacin. Permite conocer la forma en que se manejan los documentos y se llevan acabo los procesos y si se siguen todos los pasos especificados.

Tipo de informacin buscada. Actividades Mensajes Relaciones Influencias. Busca el significado simblico del contexto de trabajo de los tomadores de decisiones, al analista examina los elementos fsicos del espacio de trabajo del tomador para ver su influencia sobre el comportamiento del mismo, adems de los elementos fsicos sobre los que el tomador de decisiones tiene control (vestimenta, posicin del escritorio, etc.), el analista trabaja para comprender qu mensaje est enviando este tomador. El analista trabaja para comprender la influencia del tomador sobre los dems en la organizacin. Observacin de las actividades de toma de decisiones del gerente tpico. Para que el analista de sistemas aprecie adecuadamente la forma en que los gerentes caracterizan su trabajo se usan las entrevistas y cuestionarios; sin embargo, la observacin permite que el analista aprecie cmo los gerentes recopilan, procesan, comparten y usan la informacin para hacer que el trabajo se realice. Existen algunos pasos que apoyan en la observacin de las actividades tpicas en la toma de decisiones de un gerente: a) Decidir lo que va a ser observado (actividades). b) Decidir a qu nivel se llevar dicha observacin, es decir, si se observar al gerente compartir libremente la informacin con los subordinados o har una observacin ms concreta, tal como si el gerente enva copia del mismo memorndum a x nmero de subordinados. El determinar este nivel de observacin indicar tambin la cantidad de injerencia en cada observacin y en consecuencia, la cantidad de interpretacin necesaria que se necesite una vez que hayan sido hechas las observaciones. c) Crear categoras que capturen adecuadamente las actividades principales. d) Preparar escalas, listas de verificacin y otros materiales adecuados para la observacin.

Muestreo de tiempos y eventos. Cada enfoque sobre cundo observar tiene sus propias ventajas y compromisos, el muestreo de tiempos permite al analista poner intervalos especficos en los cuales observar. Ejemplo: se puede especificar la observacin de un elemento durante 5 intervalos de 10 min. elegidos al azar a lo largo de 7 das de 8 hrs. El muestreo de eventos permite la observacin de eventos completos, tales como reuniones de consejo o sesiones de entrenamiento de usuarios. Proporciona observaciones sobre un comportamiento ntegro en su contexto natural. Es recomendable utilizar la combinacin de muestreos cuando se decida qu, cundo, porqu y cmo observar las actividades.

Muestreo de tiempos Ventajas Elimina la tendenciosidad con la aleatoriedad de observaciones. Permite una vista representativa de actividades frecuentes. Desventajas Recolecta datos en forma fragmentada que no da tiempo para que se desarrolle una decisin. Se pierden decisiones importantes que son poco frecuentes. Permite

Muestreo de eventos la observacin de

comportamientos conforme suceden. Permite la observacin de un evento considerado importante. Se lleva gran cantidad de tiempo de el analista. Se pierde una muestra representativa de decisiones frecuentes.

Ventajas y desventajas de los tipos de muestreos.

Observacin del lenguaje corporal. El analista observa inconscientemente el lenguaje corporal durante las entrevistas. Es importante que dicha observacin se realice de manera conciente debido a que permite que el analista comprenda mejor los requerimientos de informacin, sin embargo, aunque es importante observar el lenguaje corporal, la interpretacin precisa, movimiento por movimiento, es extremadamente difcil y vara entre culturas. a) Pares de adjetivos y categoras. Permiten registrar actitudes del elemento agrupando dichas acciones en base a pares de adjetivos o por medio de una lista de categoras (comportamiento) que indica la cantidad de veces que sucede.

b) El guin del analista. En esta tcnica, el actor es el tomador de decisiones que es observado actuando o tomando decisiones. Se registran todas las actividades, as como quin las realiza. Este guin es un enfoque organizado y sistemtico que demanda que el analista sea capaz de comprender y articular la accin tomada por cada elemento observado. Es importante al momento de observar tomas de decisiones importantes y/o frecuentes. Observacin del ambiente fsico La observacin del ambiente fsico donde trabaja el tomador de decisiones revela mucho acerca de sus requerimientos de informacin. Este tipo de observacin implica examinar los lugares donde se llevan a cabo las actividades. Se debe tomar en cuenta factores tales como: ubicacin de la oficina; ubicacin de los elementos de trabajo (mquinas, escritorios); equipo de oficina fijo (libreros, archiveros, cajones); propiedades (referencia todo el equipo pequeo que se usa para procesar informacin como calculadoras, pantallas de video, plumas, reglas, etc.); revistas y peridicos del negocio (revela el tipo de informacin utiliza el tomador de decisiones y si es externa o interna); iluminacin y color del lugar de trabajo (indica la tendencia hacia la comunicacin personal, informal, formal); vestimenta usada por el tomador de decisiones (refleja la credibilidad, autoridad, participacin que da la apariencia)

UNIDAD II. DISEO DE SISTEMAS. 2.1. HERRAMIENTAS PARA DESICIN.

Una herramienta es cualquier dispositivo, objeto u operacin utilizada para ejecutar una tarea especfica. Ayudan al analista a integrar los datos recopilados por los diversos mtodos de recopilacin de informacin. Las herramientas bsicas son rboles de decisin, tablas de decisin y espaol estructurado. Condiciones y variables de decisin y acciones. Condiciones son los posibles estados de una entidad (persona, lugar, objeto o evento). Las condiciones cambian y es por esto que el analista se refiere a ellas como variables de decisin. Solo deben incluirse las condiciones relevantes. Por ejemplo: el manejo de una factura est basado en una condicin que constituye una variable de decisin. Algunas organizaciones insisten en que todas las facturas lleven una firma como requisito para autorizar el pago. En tal caso, existen dos alternativas para la recepcin de facturas, con firma o sin ella; la misma factura tambin puede ser descrita por otras condiciones como autorizada o no autorizada, con el monto correcto o incorrecto. Las acciones son las opciones que comprenden pasos, actividades o procedimientos, que pueden elegir una persona cuando se enfrenta ante un conjunto de condiciones. Las acciones pueden estar relacionadas con condiciones cuantitativas (como descuentos).

DOCUMENTAR CONCEPTOS DE

2.1.1. CONCEPTOS DE DESICIN

En muchas reas de aplicacin del software, a menudo es ms rentable adquirir el software que desarrollarlo.

Los gestores de ingeniera se enfrentan con una decisin que se puede complicar an ms con las opciones de adquisicin: el software se puede comprar con licencia ya desarrollado y se pueden adquirir componentes de software total o parcialmente experimentado de tal forma que pueda modificarse e integrarse para cumplir las necesidades especficas; o el software puede ser construido de forma personalizada por una empresa externa para cumplir las especificaciones del comprador. Para esta toma de decisin se debe considerar: 1. Desarrollo de una especificacin para la funcin y rendimiento del software deseado. Definicin de las caractersticas medibles, siempre que sea posible. 2. Estimacin del costo interno de desarrollo y la fecha de entrega. 3. Seleccin de tres o cuatro aplicaciones candidatos que cumplan mejor las especificaciones. Seleccin de componentes de software reutilizables que ayudarn en la construccin de la aplicacin requerida. 4. Desarrollo de una matriz de comparacin que presente las comparaciones una a una de las funciones clave. Alternativamente, realizar el seguimiento de las pruebas de evaluacin para comprar el software candidato. 5. Evaluacin de cada paquete de software o componente segn la calidad de productos anteriores, soporte del vendedor, direccin del producto, reputacin, etc. 6. Contacto con otros usuarios de dicho software y peticin de opiniones.

2.1.2. ACCIONES
Se refiere a la especificacin de los procesos que va a realizar el sistema. Se establece un marco comn del proceso definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamao y complejidad. Un nmero de conjuntos de tareas (cada uno es una coleccin de tareas de trabajo de ingeniera del software, hitos de proyectos, productos de trabajo y puntos de garanta de calidad) que permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto del software y a los requisitos del equipo del proyecto.

Finalmente, las actividades de proteccin (tales como garantas de calidad, gestin de configuracin y medicin) abarcan el modelo de procesos. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

2.1.3. RBOLES DE DECISIN.

El rbol de decisin es un diagrama que representa en forma secuencial condiciones y acciones en que se presentan las condiciones. Caractersticas: Permite mostrar la relacin entre condiciones y acciones permisibles. Permite al analista a describir e identificar condiciones y acciones de manera formal y as evita el pasar por alto cualquier etapa del proceso de decisin sin importar que ste dependa de variables cuantitativas o cualitativas. Obligan a considerar la secuencia de las decisiones. El rbol de decisiones de un sistema complejo con muchas secuencias de pasos combinaciones de condiciones puede tener un tamao considerable y complejo.
Monto de la factura correcto Pedido preparado para compra vlida Pago autorizado

Factura con firma

Monto de la factura incorrecto

Rechazar

Autorizacin de compra disponible Pedido no preparado para compra vlida

Monto de la factura correcto

Pago autorizado

Monto de la factura incorrecto No existe autorizacin de compra

Rechazar

Rechazar

Factura sin firma firma

Se recibi la mercanca

Pedido preparado para compra vlida

Monto de la factura correcto

Pago autorizado

Monto de la factura incorrecto Pedido no preparado para compra vlida

Rechazar

No se recibi la mercanca

Rechazar

Pedido no preparado para compra vlida Ejemplo de un rbol de decisin.

Rechazar

2.1.4. TABLAS DE DECISIN.

Es una matriz de renglones y columnas que indican condiciones y acciones. Las reglas de decisin incluidas en una tabla de decisin, establecen el procedimiento a seguir cuando existen ciertas condiciones. Pueden volverse muy grandes y difciles de manejar. Secciones: Identificacin de condiciones.- sealan aquellas que son relevantes. Entradas de condiciones.- indican que valor se debe asociar para una determinada condicin. Identificacin de acciones.- enlista el conjunto de todos los pasos que se deben seguir cuando se presenta cierta condicin. Entradas de acciones. Muestran las condiciones especficas del conjunto que deben emprenderse cuando ciertas condiciones o combinaciones de stas son verdaderas.

Condicin 1 Condicin 1 (C1) El paciente tiene seguro mdico bsico Condicin 2 (C2) El paciente tiene seguro social Accin 1 (A1) Pagar la consulta Accin 2 (A2) Exento de pago Accin 3 (A3) Pagar todos los servicios

Reglas de decisin 2 3

No

Si

No

No X

Si

Si

No

X X

Ejemplo de una tabla de decisin. Cuando C1 y C2 son S y N (columna 1), la regla establece que se debe tomar A1, el paciente solo paga el costo de la consulta.

 Cuando C1 y C2 son N y S (columna 2), la regla 2 indica que debe emprenderse la accin A2, el paciente no necesita pagar ninguno de los cargos. Cuando C1 y C2 son S, se lleva a cabo A2. El valor de C1 no tiene relevancia para la accin A2 siempre y cuando el paciente tenga seguro social, sin importar qu otro tipo de seguro tenga. Cuando C1 y C2 son N, se lleva a cabo A3, el paciente debe pagar todos los cargos de la atencin mdica. ESPAOL ESTRUCTURADO. Es la utilizacin de declaraciones para describir un proceso. Permite evitar problemas de ambigedad al establecer condiciones y acciones tanto en procedimientos como en decisiones. Permite describir con rapidez los procedimientos en su totalidad. Utiliza tres tipos bsicos de declaraciones para describir un proceso: a) Estructuras de secuencia. Es un solo paso o accin incluido en un proceso. No depende de la existencia de ninguna condicin y cuando la encuentra la lleva a cabo. Ejemplo: 1. Escoger el libro deseado 2. Llevar el libro al mostrador de salida 3. Pagar el libro 4. Obtener el recibo 5. Abandonar la librera b) Estructuras de decisin. Se evala una condicin y despus se toma la decisin para emprender las acciones asociadas.

Utiliza fases como SI/ ENTONCES/ DE OTRO MODO (IF/ THEN/ ELSE). Ejemplo: Si se encuentra el libro deseado ENTONCES 1. Llevar el libro al mostrador de salida 2. Pagar el libro 3. Asegurarse de obtener el recibo de compra 4. Abandonar la librera. DE OTRO MODO 1. No llevar libros al mostrador de salida 2. Abandonar la librera. c) Estructuras de iteracin. En las actividades rutinarias de operacin, es comn encontrar algunas que se repiten MIENTRAS existen ciertas condiciones o HASTA que stas se presentan. Ejemplo: EJECUTAR MIENTRAS se examinan ms libros: 1. Leer el ttulo del libro 2. Si el ttulo suena interesante ENTONCES a) Tomar el libro y hojearlo b) Buscar el precio c) Si la decisin es llevar el libro ENTONCES i) Colocarlo en la pila de LIBROS PARA LLEVAR ii) OTRO regresar el libro al estante d) FIN DE SI 3. OTRO continuar 4. FIN DE SI FIN DE EJECUTAR

SI se encuentran los libros deseados ENTONCES: 1. Llevar los libros al mostrador de salida 2. Pagar los libros 3. Asegurarse de obtener el recibo 4. Abandonar la librera OTRO 1. No llevar libros al mostrador de salida 2. Abandonar la librera FIN DE SI

2.2. ELEMENTOS DEL DISEO.

Durante el diseo del sistema, el trabajo del analista consiste en elaborar una o ms opciones de automatizacin del sistema que va a cumplir con los requerimientos de informacin de la unidad usuaria. En la formulacin de opciones de un sistema propuesto se debe considerar muy importante la investigacin realizada, as como su evaluacin, ya que depende de la comprensin y del conocimiento de los procedimientos y problemas del sistema vigente para formular la opcin del sistema propuesto para su aprobacin. Cuando se disea un sistema de procesamiento de datos, se debe considerar sobre todo del perfeccionamiento de las operaciones y la reduccin de los costos, as como la oportunidad y calidad de los resultados. Un aspecto importante en el diseo de un sistema es aprovechar al mximo los recursos con que cuenta el computador por utilizar. Objetivos del diseo. a) Estandarizacin de procedimientos de las unidades b) Eliminacin de funciones innecesarias c) Eliminacin de reportes, registros y formas innecesarios d) Eliminacin de datos superfluos

e) Establecimiento de los controles necesarios y simplificacin de los excesivos. f) Eliminacin de duplicacin de funciones g) Eliminacin de duplicacin de objetivos h) Eliminacin de duplicacin de operaciones i) Eliminacin de duplicacin de informes y formatos j) Facilitacin del flujo de trabajo y eliminacin del desorden del mismo k) Oportunidad de los resultados l) Calidad de los resultados m) Utilizacin efectiva de los resultados Las especificaciones de diseo describen las caractersticas del sistema, los componentes o elementos del sistema y la forma en que stos aparecern ante los usuarios. para muchos usuarios, el xito de un sistema est relacionado con la creencia que tengan sobre si el sistema tiene las caractersticas adecuadas. Los componentes de un sistema de informacin descritos durante el anlisis de requerimientos, son el punto focal del diseo de sistemas y se deben disear los siguientes elementos: a) Flujos de datos. El flujo de datos4 son los movimientos de datos hacia, alrededor y desde el sistema. La estrategia de flujo de datos muestra el empleo y la interaccin de la informacin en la organizacin, as como la forma en que se ajustan y se utilizan en sistema. Puede ser difcil comprender en su totalidad un proceso de la empresa si se emplea para ello slo una descripcin verbal; las herramientas para el flujo de datos ayudan a ilustrar los componentes esenciales de un sistema junto con sus interacciones. b) Almacenes de datos. Los almacenes de datos5 son conjuntos temporales o permanentes de datos. Los flujos y almacenes de datos son estructuras de datos.

Si las estructuras de datos estn en movimiento reciben el nombre de flujos de datos, en contraste, las estructuras de datos que no estn en movimiento se denominan almacenes de datos. Todas las estructuras de datos estn definidas en una entrada del diccionario de datos. El volumen de detalles indica el nivel de actividad, as como el nmero de transacciones o la rapidez de cambio (para un dato durante un periodo determinado de tiempo). c) Procesos. Los procesos6 son actividades para aceptar, manejar y suministrar datos e informacin. Pueden ser manuales o basados en computadora. La definicin de cada proceso del sistema debe ser definida por separado debido a que cada proceso debe ser asociado a un procedimiento general. d) Procedimientos. Los procedimientos7 mtodos y rutinas para utilizar el sistema de informacin y lograr con ello los resultados esperados. e) Controles. Estndares y lineamientos para determinar si las actividades estn ocurriendo en la forma anticipada o aceptada, es decir si se encuentran bajo control. As mismo, debe especificar las acciones que tienen que emprenderse cuando ocurren problemas o se presentan circunstancias inesperadas. Puede incluirse un reporte sobre las excepciones o procedimientos para la correccin de los problemas. f) Funciones del personal. Las responsabilidades de todas las personas que tienen que ver con el nuevo sistema, incluyendo los usuarios, operadores de computadora y personal de apoyo. Abarca todo el espectro de componentes del sistema, incluso desde la entrada de datos hasta la distribucin de salidas o resultados. A menudo, las funciones del personal se establecen en forma de procedimientos.

2.2.1. FLUJO DE DATOS.

Se aplica cuando los datos de entrada son transformados a travs de una serie de componentes computacionales o manipulativos en los datos de salida.

El flujo de datos es el primer componente a ser definido, las entradas y salidas del sistema son determinadas a partir de entrevistas, observacin de usuarios y anlisis de documentos y otros sistemas existentes. La informacin capturada para cada flujo de datos deben ser sumarizada usando una forma que contenga la siguiente informacin: 1. Un nmero de identificacin opcional, a veces este es codificado usando un esquema para identificar el sistema y la aplicacin dentro del sistema. 2. Un nombre descriptivo nico para este flujo de datos. Este nombre es el texto que debe aparecer en el diagrama y que puede ser referenciado a todas las descripciones que usan el flujo de datos. 3. Una descripcin general del flujo de datos. 4. El origen del flujo de datos. Esto puede ser una entidad externa, un proceso o un flujo de datos que viene de un almacn de datos. 5. El destino del flujo de datos. 6. Una indicacin de si el flujo de datos es un registro que entra o sale de un archivo, o contiene un reporte, forma o pantalla. Si el flujo de datos contiene datos que son usados entre procesos, es designado como interno. 7. El nombre de la estructura de datos describiendo los elementos que se encuentran en este flujo de datos. Para un flujo de datos simple esto podra ser uno o varios elementos. 8. El volumen por unidad de tiempo. Esto puede ser registros por da o cualquier otra unidad de tiempo. 9. Un rea para comentarios adicionales y observaciones acerca del flujo de datos. Diagramas de flujo de informacin. Una herramienta grfica se emplea para describir y analizar el movimiento de datos a travs de un sistema ,y a sea que este fuera ,manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema . Los diagramas de flujo de datos son la herramienta mas importante de y la base sobre la cual se desarrollan otros componentes.

La transformacin de datos de entrada en salida por medio de procesos puede describirse en forma lgica e independiente de los componentes fsicos, asociados con el sistema. Estos diagramas reciben el nombre de diagramas lgicos de flujos de datos. En contraste , los diagramas fsicos de flujo de datos muestran la implantacin y movimiento real de datos entre las personas, departamentos y estaciones de trabajo. Los DFD utilizan smbolos bsicos para diagramar el movimiento de datos en los diagramas de flujo de datos. Notacin. Los diagramas lgicos de flujo de datos se pueden dibujar con solo cuatro notaciones sencillas, es decir con smbolos especiales o iconos y anotaciones que los asocian con un sistema especifico. Smbolo Significado Entidad Ejemplo Estudiante

Proceso

2.1. Crear registro de estudiantes

Almacn de datos

D3

Muestreo de estudiantes

Flujo de datos

Nueva informacin de estudiante

El cuadrado doble puede ser usado para representar una actividad externa (otro departamento, negocio, persona o mquina); la entidad externa se llama fuente destino de datos. Cada entidad externa debe ser etiquetada. El rectngulo se utiliza para mostrar la aparicin de un proceso de transformacin. Los procesos siempre denotan un cambio o transformacin de los datos y por lo tanto, el flujo de datos que sale de un proceso siempre es etiquetado en forma diferente al de una entrada.

Se les debe dar un nmero de identificacin nico, indicando el nivel del diagrama. Varios flujos de datos pueden entrar y salir de cada proceso. Representa el almacenamiento de datos en medios fsicos como cintas, discos flexibles, etc. Puede representar un almacenamiento manual o base de datos computarizado. No se consideran en el diagrama almacenamientos temporales, formas en blanco, etc. La flecha muestra el movimiento de datos de un punto a otro, seala hacia el destino de los datos; debido a que una flecha representa datos acerca de una persona, lugar o cosa, tambin debe ser descrita con un nombre. Estado de cada Indicador de comienzo/ parada
Control y activaci del robot

Alarma de movimiento

Bufer del estado de piezas

Cadena de bits

Activar Proces

Interfaz del monitor de fijacin y operador

Ajustes del operador

Procesar ordenes del robot

Ordenes de posicin

Ordenes del operador

Registro de movimientos del robot

Archivo de rdenes del robot

Creacin de un DFD.

2.2.2. ALMACENES DE DATOS.

Todos los elementos base deben ser guardados dentro del sistema as como los elementos derivados. Los almacenes de datos son creados para cada entidad de dato diferente que va a ser guardado. Esto es, cuando los elementos base del flujo de datos son agrupados para formar un registro estructural, se crea un almacn de datos para cada registro estructural nico. Debido a que el flujo de datos dado puede solamente mostrar parte de los datos colectivos que contiene, en un registro estructural se tendrn que examinar muchas estructuras de flujos de datos diferentes para llegar a una descripcin completa del almacn de datos. La informacin comn incluida en una forma del almacn de datos es: 1. El identificador del almacn de datos que evita la repeticin de informacin. 2. Nombre del almacn de datos, descriptivo y nico. 3. Un alias para el archivo. 4. Una breve descripcin del almacn de datos. 5. El tipo de archivo, manual o computarizado 6. Si el archivo es computarizado, el formato de archivo indica si es de base de datos o tiene el formato de un archivo plano tradicional. 7. La cantidad mxima y promedio de registros en el archivo, as como el crecimiento anual. 8. El nombre del juego de datos especifica el nombre de archivo, en caso de ser conocido. 9. La estructura de datos debe usar un nombre que se encuentre en el diccionario de datos. Diccionario de datos. Diccionario de datos, en informtica, base de datos acerca de la terminologa que se utilizar en un sistema de informacin. Para comprender mejor el significado de un diccionario de datos, puede considerarse su contenido como " datos acerca de los datos"; es decir, descripciones de todos los dems objetos (archivos, programas, informes, sinnimos...) existentes en el sistema.

Un diccionario de datos almacena la totalidad de los diversos esquemas y especificaciones de archivos, as como sus ubicaciones. Si es completo incluye tambin informacin acerca de qu programas utilizan qu datos, y qu usuarios estn interesados en unos u otros informes. Por lo general, el diccionario de datos est integrado en el sistema de informacin que describe. El diccionario de datos contiene las caractersticas de las entidades y atributos, que definen la estructura de la Base de Datos (Meta - Base de Datos). Objetivos del diccionario de datos. Facilitar el control de cada una de las entidades y atributos que forman parte de la estructura de Base de Datos del Sistema. Controlar dinmicamente. la estructura de la interface al usuario, para las diferentes pantallas del sistema. Ventajas de utilizar un Diccionario de Datos La posibilidad de generar automticamente todas las tablas que corresponden al estndar MARC, definidas para el Sistema. El permitir que el sistema reconfigure dinmicamente la interface al usuario, con respecto a cmo y cuales son los atributos que se deben presentar en las diferentes pantallas. El concentrar la informacin correspondiente a la Repetibilidad y Obligatoriedad de cada una de las Etiquetas y Subcampos del estndar MARC definidas para el SIV.

Modelo fsico de una BD.

Es una aplicacin especializada que referencia los datos utilizados por los analistas para guiarse a travs del anlisis y diseo. Como documento, el diccionario de datos recolecta, coordina y confirma lo que significa un trmino de datos especfico para diferentes personas de la organizacin. Contiene informacin acerca de los datos y procedimientos. Los diccionarios de datos automatizados son valiosos por su capacidad para hacer referencias cruzadas de conceptos de datos, permitiendo los cambios de programas necesarios para todos los programas que comparten un elemento comn. Puede ser usado para: validar el diagrama de flujo de datos y confirmar que est completo y preciso; proporcionar un punto inicial para el desarrollo de pantallas y reportes; determinar el contenido de datos almacenados en archivos; desarrollar la lgica para los diagramas de flujo de datos de procesos.

Las entradas del diccionario de datos pueden ser creadas despus de que ha sido terminado el diagrama de flujo de datos o construidas mientras se est desarrollando el diagrama de flujo. El uso de notacin algebraica y registros estructurales permite al analista desarrollar el diccionario de datos y los diagramas de flujo de datos usando un enfoque de arriba hacia abajo. En el DFD 0 se incluyen solamente formas, pantallas, reportes y registros, conforme se van creando los diagramas hijos, el flujo de datos que entra y sale de los procesos llega a ser cada vez ms detallado, incluyendo registros estructurales y elementos; por lo tanto, se necesita el diccionario de datos debido a que no se muestran registros y pantallas en un DFD hijo detallado, ni calificaciones de elementos en un DFD de alto nivel. Ejemplo: La Figura 15, ilustra una parte de dos niveles de DFD y sus entradas de diccionario de datos correspondientes para produccin de cheque de pago de empleados. El proceso 5, que se encuentra en el diagrama 0, es una vista panormica de la produccin de un cheque de pago de empleado. La entrada del diccionario de datos correspondiente para registro de empleado muestra el nmero de empleado y cuatro registros estructurales, la visin de los datos obtenida anteriormente en el anlisis. En forma similar, registro de archivo de tiempo y cheque de pago de empleado estn tambin definidos como una serie de estructuras. Parte de dos niveles de un DFD. Estructura de datos Registro de empleados = Nmero de empleado + Informacin personal + Informacin de pago + Informacin de pago actual + Informacin anual + Nmero de empleado + Nombre del empleado + Horas trabajadas Nmero de empleado + Nombre de empleado + Direccin + Cantidades del pago actual + Cifras anuales

Registro de archivo de tiempo =

Cheque de pago del empleado =

Flujo de datos Archivo de tiempos Del empleado Registro de tiempos Del empleado 5 Cheque de Pago del empleado Emplead o

D2

Registro de empleados D2 Archivo de tiempos Del empleado

Produce el cheque de pago del empleado Estructura de datos

Informacin de pago = Cantidades de pago actual =

Tasa de pago + Cantidad de dependientes Pago bruto + Retencin federal + Retencin estatal + Retencin de seguridad social + Pago neto

Flujo de datos Horas trabajadas

Informacin de pago

5.3

Cantidades de pago actual

Calcula las entidades de pago actual

Un paso importante en la creacin del diccionario de datos es identificar y categorizar el flujo de datos de entrada y salida del sistema. Se pueden usar formas para el anlisis de la entradas y salidas. Tablas del Diccionario de Datos a) Tabla Entity. Almacenar la informacin de todas las entidades que forman parte de la base de datos. En el caso de altas y modificaciones la informacin de Repetibilidad y Obligatoriedad con respecto a las etiquetas, servir para la validacin de entrada de datos. Es decir todos aquellas etiquetas que sean obligatorias debern ser capturadas. b) Tabla Attribute. Almacenar todos los atributos que pertenecen a entidades de la base de datos. La Obligatoriedad y Repetibilidad de los atributos es utilizado, como en el caso anterior de las entidades, para validar la entrada y modificacin de tem o recursos. Para el caso de los atributos, la informacin de Obligatoriedad y Repetibilidad es utilizada por un procedimiento almacenado para generar las expresiones de consultas y para generar el registro MARC (MARCMAKER). El tamao del atributo es utilizado para la validacin de entrada y modificacin de datos. c) Tabla Ent_Att. Almacenar la informacin de la relacin que existe entre los Entidades y Atributos, es decir los atributos que corresponden a cada entidad. d) Tabla Key. Almacenar la relacin de todas las llaves existentes dentro de todas las entidades de la base de datos. e) Tabla Link. Almacenar la informacin que sirve para identificar las relaciones entre las entidades de la Base de Datos del SIV f) Tabla Sceen_Grid. Almacenar la informacin que define el rea de criterios para especificar condiciones de bsqueda y mostrar un resumen de los resultados de bsqueda. g) Tabla User. Almacenar los datos de los usuarios incluyendo su contrasea o password y el tipo de usuario, as como la institucin a la que pertenece.

Tablas.

Una vez finalizado el diseo de una base de datos y escogido un SGBD para su implementacin, el primer paso consiste en especificar el esquema conceptual y el esquema interno de la base de datos, y la correspondencia entre ambos. En muchos SGBD no se mantiene una separacin estricta de niveles, por lo que el administrador de la base de datos y los diseadores utilizan el mismo lenguaje para definir ambos esquemas, es el lenguaje de definicin de datos (LDD). El SGBD posee un compilador de LDD cuya funcin consiste en procesar las sentencias del lenguaje para identificar las descripciones de los distintos elementos de los esquemas y almacenar la descripcin del esquema en el catlogo o diccionario de datos. Se dice que el diccionario contiene metadatos: describe los objetos de la base de datos. Cuando en un SGBD hay una clara separacin entre los niveles conceptual e interno, el LDD slo sirve para especificar el esquema conceptual. Para especificar el esquema interno se utiliza un lenguaje de definicin de almacenamiento (LDA). Las correspondencias entre ambos esquemas se pueden especificar en cualquiera de los dos lenguajes.

Para tener una verdadera arquitectura de tres niveles sera necesario disponer de un tercer lenguaje, el lenguaje de definicin de vistas (LDV), que se utilizara para especificar las vistas de los usuarios y su correspondencia con el esquema conceptual.

Entrada que ejemplifica el flujo de datos en un diccionario de datos. NOMBRE DEL FLUJO DE DATOS: DESCRIPCIN: Paquete de factura. Detalles de la factura firmada por el vendedor y autorizacin interna de compra no auditada para comprobar el monto total y de los impuestos. PROVENIENTE DE LOS PROCESOS: 1.3. Verificacin de la mercanca ordenada. 1.4. Recepcin de la autorizacin de la compra. PARA LOS PROCESOS: 1.5. Monto de la factura (en el lote de facturas retrasadas). ESTRUCTURAS DE DATOS: Paquete de factura: - Detalle de la factura - Acuse de recibo - Autorizacin de compra

Una actividad en la creacin del diccionario de datos es el desarrollo de almacenes de datos. La informacin que se analiza en las estructuras de datos puede ser guardada en numerosos lugares y en cada lugar el almacn de datos puede ser diferente; mientras los flujos de datos representan los datos en movimiento, los almacenes de datos representan a los datos en reposo. Por ejemplo: al llegar un pedido a una empresa, esta contiene informacin de naturaleza temporal la cual es necesaria para llevar ese pedido particular. Sin embargo, parte de la informacin de la forma de pedido puede ser guardada permanentemente, como la informacin acerca de los clientes (catlogo de clientes) e informacin acerca de los artculos. Los almacenes de datos son creados solamente para un reporte o pantalla (se le conocen como vistas de usuario), debido a que representan la forma en que el usuario quiere ver la informacin. Un diseador de sistemas tiene que determinar si hace varios archivos individuales que representen vistas de usuarios o hace una base de datos que represente las vistas de muchos usuarios.

Entrada que ejemplifica el almacn de datos en un diccionario de datos. ALMACEN DE DATOS: DESCRIPCIN: Facturas autorizadas. Solicitudes por parte del vendedor para procesamiento. Detalla la mercanca recibida, costo de cada artculo y contiene la firma del empleado que recibe la mercanca. FLUJO DE DATOS RECIBIDOS: 2.1. Factura con firma 2.2. Factura con firma cuando la firma es necesaria FLUJO DE DATOS Detalles de los artculos asentados en el lote de PROPORCIONADOS: facturas. DESCRIPCIN DE DATOS: Detalles del vendedor Detalles de los artculos Nmero de factura Cantidad adeudada Fecha de expedicin de la factura Referencia de la orden de compra VOLUMEN: 200 al da, crecimiento anual 10%; la mayor carga de trabajo se presenta al inicio de cada mes. ACCESO: Retrasado hasta completar el lote; una vez completado se tiene acceso a cualquiera de ellas; el procesamiento dentro del lote es secuencial.

Entrada que muestra el diccionario de datos para un determinado proceso. PROCESO: DESCRIPCIN: ENTRADA: Verificar la mercanca ordenada. Asociar toda factura que se reciba con un nmero vlido de orden de compra o autorizacin. Detalles de la factura Detalles de la orden de compra Paquete de factura Paquete no verificado. Asociar cada factura recibida con una autorizacin vlida de compra. Agregar la informacin de la orden de compra para completar el paquete de la factura. Si no existe ninguna orden de compra vlida, obtener la aprobacin del gerente. Si es aprobada por el gerente, asentar la aprobacin y completar el paquete de la factura. Si no es aprobada por el gerente, regresar la factura al proveedor indicando que no se

SALIDA: RESUMEN DE LA LGICA:

autoriza el pago.

Uso del diccionario de datos. El diccionario de datos ideal es automatizado, interactivo, en lnea y evolucionario. Conforme el analista de sistemas aprende acerca de los sistemas de la organizacin, son aadidos conceptos de datos al diccionario. El diccionario debe estar enlazado con una cantidad de programas de sistema, para que cuando sea actualizado o borrado un concepto del diccionario sea actualizada automticamente la base de datos. Puede tambin ser usado para crear pantallas, reportes y formas. La estructura de datos y elementos para un almacn de datos son usados comnmente para generar el cdigo de lenguaje fuente de computadora y puede ser usado en conjuncin con un diagrama de flujo de datos para analizar el diseo de sistema, detectar fallas y reas que necesiten aclaracin.

2.2.3. PROCESOS.
Los procesos proporcionan estabilidad, control y organizacin a una actividad que puede, si no se controla, volverse catica. El proceso del software es un marco de trabajo de las tareas que se requieren para construir software de alta calidad, define el enfoque que se toma cuando el software es tratado por la ingeniera. El fundamento de la ingeniera del software es el proceso. El proceso de la ingeniera del software es la unin que mantiene juntas las capas de tecnologa y que permite un desarrollo racional y oportuno de la ingeniera de software. El proceso define un marco de trabajo para un conjunto de reas clave de proceso que se deben establecer para la entrega efectiva de la tecnologa de la ingeniera del software. Las reas claves del proceso forman la base del control de gestin de proyectos del software y establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos del trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. Los mtodos de la ingeniera del software indican como construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento.

Los mtodos de la ingeniera del software dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. Las herramientas de la ingeniera del software proporciona un enfoque automtico o semiautomtico para el proceso y los mtodos. Cuando se integran herramientas para que la informacin creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniera del software asistida por computadora (CASE). Las fases genricas que caracterizan el proceso de software (definicin, desarrollo y soporte) son aplicables a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniera del software que debe aplicar el equipo del proyecto. El gestor del proyecto debe decidir qu modelo de proceso es el ms adecuado para: a) Los clientes que han solicitado el producto y la gente que realizar el trabajo. b) Las caractersticas del producto en s. c) El entorno del proyecto en el que trabaja el equipo de software. Las especificaciones de procesos, llamadas tambin miniespecificaciones debido a que son una parte pequea del total de especificaciones del proyecto, son creadas para procesos primitivos en los DFD, as como para algunos procesos de ms alto nivel que explotan hacia un diagrama hijo. Estas especificaciones explican la lgica para la toma de decisiones y las frmulas que transformarn los datos de entrada al proceso en datos de salida. Cada elemento derivado debe tener lgica de proceso para mostrar cmo es producido a partir de elementos bsicos, o de otros elementos derivados previamente creados, que son entrada para el proceso primitivo. Objetivos de la produccin de especificaciones del proceso. a) Reducir la ambigedad del proceso. Esto conlleva a aprender detalles acerca de la manera en que trabajan los procesos. Cualquier rea vaga debe ser anotada, puesta por escrito y consolidada para todas las especificaciones del proceso. Estas observaciones forman una

base y proporcionan las preguntas para entrevistas de averiguacin con la comunidad de usuarios. b) Obtener una descripcin precisa de lo que se logra. c) Validar el diseo del sistema, esto incluye asegurarse que un proceso tenga todos los flujos de datos necesarios para producir la salida. Toda entrada y salida debe estar representada en el DFD. Existen casos donde las especificaciones de procesos no estn creadas, en otras el proceso es muy simple o ya existe el cdigo de computadora; todo esto debe ser anotado en la descripcin de procesos y no se requerir ms diseo. Algunos procesos que no requieren especificaciones son: a) Procesos que representan entradas o salidas tpicas como lectura, escritura, etc. b) Procesos que representan validacin de datos simple y que es por lo general fcil de lograr. Los criterios de edicin estn incluidos en el diccionario de datos y son incorporados en el cdigo fuente de computadora. c) Procesos que usen cdigo preescrito; estn generalmente incluidos en un sistema como subprogramas y funciones. Los subprogramas son programas que son escritos, probados y guardados en el sistema de computadora. Por lo general ejecutan una funcin general del sistema tal como la validacin de una fecha o de un dgito verificador. Estos programas de propsito general son escritos y documentados una sola vez y forman una serie de bloques de construccin que pueden ser usados por muchos sistemas de la organizacin. Estos subprogramas aparecen como procesos en muchos DFD. Las funciones son similares a los subprogramas, pero estn codificadas en forma diferente. Por ejemplo: una biblioteca de funciones para ser usada en un determinado lenguaje de programacin o en un ambiente de base de datos. Las especificaciones de proceso enlazan los procesos con los DFD y el diccionario de datos; cada especificacin de proceso debe ser dada en forma separada.

2.2.4. PROCEDIMIENTOS.
Son los pasos que definen el empleo especfico de cada elemento del sistema o el contexto procedimental en que reside el sistema. El procedimiento del software se centra en el procesamiento de cada mdulo individualmente. El procedimiento debe proporcionar una especificacin precisa de procesamiento, incluyendo la secuencia de sucesos, los puntos de decisin exactos, las operaciones repetitivas e incluso la estructura/organizacin de datos. Existe una relacin entre la estructura y el procedimiento. El procesamiento indicado para cada mdulo debe incluir una referencia a todos los mdulos subordinados al mdulo que se est describiendo. Es decir, una representacin procedimental del software se distribuye en capas: a) Procedimiento para el mdulo superior b) Procedimiento para el mdulo subordinado c) Procedimiento para el ltimo mdulo subordinado

2.2.5. FUNCIONES DEL PERSONAL.

La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado es tan importante que el Instituto de Ingeniera del Software ha desarrollado un modelo de madurez de la capacidad de gestin de personal (MMCGP) para aumentar la preparacin de organizaciones del software para llevar a cabo las cada vez mas complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software. Este modelo define las reas clave prcticas para el personal que desarrolla software: reclutamiento, seleccin, gestin de rendimiento, entrenamiento, retribucin, desarrollo de la carrera, diseo de la organizacin y del trabajo y desarrollo cultural y de espritu de equipo.

Los participantes que componen el proceso del software se pueden clasificar en: a) Gestores superiores. Definen los aspectos de negocios que a menudo tienen una significativa influencia del proyecto. b) Gestores (tcnicos) del proyecto. Deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software. c) Profesionales. Proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o aplicacin. d) Clientes. Especifican los requisitos para la ingeniera del software y otros elementos que tienen menor influencia en el resultado. e) Usuarios finales. Interaccionan con el software una vez que se ha entregado para la produccin. f) Jefes de equipo. Organiza al equipo del proyecto de manera que maximiza las habilidades y capacidades de cada persona.

UNIDAD III. MODELADO DE SISTEMAS ORIENTADO A OBJETOS 3.1. CONCEPTOS.

La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los sesenta. Las tecnologas de objetos han necesitado casi veinte aos para llegar a ser ampliamente usadas. Durante los noventas, la ingeniera de software orientada a objetos se convirti en el paradigma de eleccin para muchos productores de software y para un creciente nmero de sistemas de informacin y profesionales de la ingeniera. Las tecnologas de objetos llevan a reutilizar y la reutilizacin (de componentes de software) lleva a un desarrollo de software ms rpido y a programas de mejor calidad. El software OO (orientado a objetos) es ms fcil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios y provoca menos frustracin en el ingeniero de software y el cliente. Los sistemas OO son ms fciles de adaptar y escalar. Un simple uso de POO (programacin orientada a objetos) no brinda los mejores resultados, los ingenieros del software y sus directores deben considerar tales elementos el anlisis y requisitos orientado a objetos (AROO), el diseo orientado a objetos (DOO), el anlisis del dominio orientado a objetos (ADOO), sistemas de gestin de bases de datos orientadas a objetos (SGBDOO) y la ingeniera del software orientado a objetos asistida por computadora (ISOOAC). El proceso OO se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es aqu donde se define el dominio del problema y se identifican las clases bsicas del problema. La planificacin y el anlisis de riesgos establecen una base para el plan del proyecto OO. La ingeniera del software OO hace hincapi en la reutilizacin; por lo tanto, las clases se buscan en una biblioteca (de clases OO existentes) antes de construirse. Cuando una clase no puede encontrarse en la biblioteca, el desarrollador de software aplica AOO, DOO, POO y pruebas orientadas a objetos (PROO) para crear la clase y los objetos derivados de la clase. La nueva clase se pone en la biblioteca de tal manera que pueda ser reutilizada a futuro. Beneficios de una arquitectura OO.

 Los detalles de implementacin interna de datos y procedimientos estn ocultos al mundo exterior y reduce la propagacin de efectos colaterales cuando ocurren cambios. Las estructuras de datos y operaciones que las manipulan estn mezcladas en una entidad sencilla: la clase, esto facilita la reutilizacin de componentes. Las interfaces entre objetos encapsulados estn simplificadas. Un objeto que enva un mensaje no tiene que preocuparse de los detalles de las estructuras de datos internas en el objeto receptor, lo que simplifica la interaccin y hace que el acoplamiento del sistema tienda a reducirse.

3.1.1. MODELADO.
Los modelos se crean para entender mejor la entidad que se va a construir. Cuando la entidad es algo fsico podemos construir un modelo idntico en forma pero ms pequeo. Sin embargo, cuando la entidad que se va a construir es software, nuestro modelo debe tomar una forma diferente. Debe ser capaz de modelar la informacin que transforma el software, las funciones y subfunciones que permiten que ocurran las transformaciones y el comportamiento del sistema cuando ocurren estas transformaciones.

3.1.2. MODELADO DE OBJETOS.

El modelo de objetos asegura que los componentes desarrollados en distintos lenguajes de programacin que residan en distintas plataformas pueden ser interoperables. Esto es, los objetos deben ser capaces de comunicarse en una red. Para lograr esto, el modelo de objetos define un estndar para la interoperabilidad de los componentes.

3.1.3. MODELO DINMICO.

Tratan los aspectos de comportamiento de la arquitectura del programa, indicando como puede cambiar la estructura o la configuracin del sistema en funcin de los acontecimientos externos.

Aqu se modela el comportamiento durante el proceso de explotacin del sistema, consistiendo en identificar y modelar los estados por los que pasan los diferentes elementos/clases que forman el modelo, as como los flujos de datos existentes entre ellos. La naturaleza un proceso de simulacin dirigida por eventos, es de carcter totalmente secuencial. Esto disminuye este modelado, ya que en la metodologa UML, el modelo dinmico est orientado al modelado de sistemas concurrentes y/o interactivos. Las clases modeladas no poseen gran cantidad de estados, como ejemplo, en la Figura 27 se muestra el diagrama de estados de la clase transicin en la que se observa la existencia nicamente dos estados. Por este motivo no se ha considera necesario presentar los diagramas de estado del resto de la clases.

3.1.4. MODELO FUNCIONAL.

El modelo funcional se utiliza para representar la jerarqua funcional de un sistema. Permite la descripcin de las actividades o procesos, que son realizados dentro del negocio y que sern automatizados con el sistema. Un Diagrama Conceptual de Usuario (DCU) es una herramienta por medio de la cual se integra del modelo funcional, el modelo funcional permite representar un sistema completo o una funcin de negocio como un conjunto de procesos de negocio (o actividades) conectados entre s a travs de informacin compartida, los cuales interactan con miembros de la organizacin a travs de flujos de entrada o salida de informacin.

3.2. DESCRIPCIN DEL MODELO DE OBJETOS.

Conceptos de orientacin a objetos. Para entender la visin OO, consideremos un ejemplo de un objeto del mundo real (una silla). Silla es un miembro de una clase ms grande de objetos llamado mobiliario. Un conjunto de atributos genricos pueden asociarse con cada objeto en la clase mobiliario por ejemplo, costo, dimensiones, peso, localizacin, color, etc.

Estos son aplicables a cualquier elemento sobre el que se hable. Como silla es un miembro de la clase mobiliario, hereda todos los atributos definidos para dicha clase. Una vez definida la clase, los atributos pueden reutilizarse al crear nuevas instancias de la clase por ejemplo, vamos a suponer que debemos definir un nuevo objeto llamado sillesa que es un miembro de la clase mobiliario, esta hereda todos los atributos de mobiliario. OO = objetos + clasificacin + herencia + comunicacin.

3.2.1. SIMBOLOGA
El Modelo de Objetos utiliza un Diagrama de Configuracin de Clases (DCC) para definir y mostrar la estructura y comportamiento de todas las clases identificadas en el dominio del problema, as como sus relaciones. Una clase se representa grficamente como una caja dividida en tres: 1. Cabecera: contiene la declaracin del nombre de la clase. 2. Parte Esttica: contiene la definicin de los atributos que representan el estado de los objetos de la clase. Los atributos podran ser constantes, variables y derivados. Aquellos atributos utilizados para identificar objetos se subrayan. 3. Parte Dinmica: contiene la declaracin de los servicios de la clase. Cada servicio se declara especificando su nombre y argumentos (con sus tipos respectivos). Se distinguir grficamente entre los eventos de creacin, borrado y los eventos compartidos con otras clases. Las acciones son servicios que un objeto puede activar (actuando como agente) para consultar o modificar el estado de otro objeto. Se muestra en la siguiente figura una Clase elemental:

Clase elemental

Las relaciones estructurales que podemos modelar son la agregacin (parte-de) y la herencia (es-un). En el Figura 24 se presenta la relacin de Agregacin entre clases, incluyendo informacin sobre cardinalidades (mximas y mnimas) que determinan cuntos objetos componentes forman parte de un objeto compuesto e inversamente, cuntos objetos compuestos pueden estar compuestos de un objeto en particular.

Relacin de agregacin entre clases.

La Herencia se define grficamente trazando una flecha desde la subclase hacia la superclase correspondiente. Esta flecha de especializacin puede etiquetarse con una condicin de especializacin; o con los eventos correspondientes de activacin-cancelacin la especializacin temporal (rol). En la Figura 25 se ejemplifica una clase compleja (especializacin temporal).

Clase compleja (especializacin temporal)

En el modelo de objetos, una clase estara completamente definida por un conjunto de funciones que cubren el resto de propiedades como son las: Restricciones de integridad. Establecen condiciones que el estado de los objetos debe satisfacer siempre (estticas) o durante un determinado periodo de su existencia (dinmicas). Derivaciones. Sirven para calcular el valor de los atributos derivados. Dicho valor se determina con funciones de otros que ya fueron definidos.

3.2.2. IDENTIFICACIN DE OBJETOS Y CLASES.

Clase: Es un concepto OO que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real. Los atributos que describen la clase estn encerradas por una muralla de abstracciones procedimentales (operaciones, mtodos o servicios) capaces de manipular los datos de alguna manera. La forma de alcanzar los atributos y operar sobre ellos es a travs de alguno de los mtodos que forman la muralla, por lo tanto, la clase encapsula datos (dentro de la muralla) y el proceso que manipula los datos (los mtodos que componen la muralla). Todo esto permite ocultar informacin y reduce el impacto de efectos colaterales asociados a cambios.

Todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulacin de los atributos. Una superclase es una coleccin de clases y una subclase es una instancia de una clase. Esto implica el manejo de jerarquas de clases en las cuales los atributos y operaciones de la superclase son heredados por subclases que pueden aadir, cada una de ellas, atributos privados y mtodos. Atributos. Los atributos estn asociados a clases y objetos y describen la clase u objeto de alguna manera. Los atributos son las caractersticas que definen al objeto, puede verse como una relacin binaria entre una clase y cierto dominio, por lo tanto, un atributo puede tomar un valor definido por un dominio enumerado. Las caractersticas (valores del dominio) pueden aumentarse asignando un valor por defecto (caracterstica) a un atributo. Para identificar los elementos de un modelo de objetos (clases y objetos, atributos, operaciones y mensajes) en un problema real, podran seguirse algunas directrices informales que nos pueden ayudar a este fin. Los objetos se manifiestan de alguna de las siguientes formas: Entidades externas (otros sistemas, dispositivos, personas) que producen o consumen informacin a usar por un sistema computacional. Cosas (informes, presentaciones, cartas, seales) que son parte del dominio de informacin del problema. Ocurrencias o sucesos (una transferencia de propiedad o la terminacin de una serie de movimientos en un robot) que ocurren dentro del contexto de una operacin del sistema. Papeles o roles (director, ingeniero, vendedor) desempeados por personas que interactan con el sistema. Unidades organizacionales (divisin, grupo, equipo) que son relevantes en una aplicacin.

 Lugares (planta de produccin o muelle de carga) que establecen el contexto del problema y la funcin general del sistema. Estructuras (sensores, vehculos de cuatro ruedas o computadoras) que definen una clase de objetos o en casos extremos, clases relacionadas de objetos. Coad y Yourdon sugieren 6 caractersticas de seleccin a usar cada vez que se considere incluir o no un objeto potencial en el modelo de anlisis: Informacin retenida. El objeto potencial ser de utilidad durante el anlisis solamente si la informacin acerca de l debe recordarse para que el sistema funcione. Servicios necesarios. El objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambar de alguna manera el valor de sus atributos. Atributos mltiples. Durante el anlisis de requisitos, se debe centrar la atencin en la informacin principal (un objeto con un solo atributo puede ser til durante el diseo, pero seguramente ser mejor presentado como un atributo de otro objeto durante la actividad de anlisis). Atributos comunes. Puede definirse un conjunto de atributos para el objeto potencial, los cuales son aplicables a todas las ocurrencias del objeto. Operaciones comunes. Puede definirse un conjunto de operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto. Requisitos esenciales. Entidades externas que aparecen en el espacio del problema y producen o consumen informacin esencial para la produccin de cualquier solucin para el sistema, sern case siempre definidas como objetos en el modelo de requisitos. Adicionalmente, los objetos y clases pueden clarificarse por un conjunto de caractersticas: Tangibilidad. Representa la clase algo tangible o palpable (por ejemplo, un teclado o sensor), o representa informacin ms abstracta (por ejemplo: una salida prevista)? Inclusividad. Es la clase atmica (es decir, no incluye otras clases) o es agregada (incluye al menos un objeto anidado)?

 Secuencia. Es la clase concurrente (es decir posee su propio hilo de control) o secuencial (es controlada por recursos externos)? Persistencia. La clase es temporal (se crea durante la ejecucin del programa y es eliminada una vez que sta termina), o permanente (es almacenada en una base de datos)? Integridad. Es la clase corrompible (es decir, no protege sus recursos de influencias externas) o es segura (la clase refuerza los controles de accesos a sus recursos)? Se sugieren cinco pautas para especificar responsabilidades para las clases: La inteligencia del sistema debe distribuirse de manera igualitaria. Toda aplicacin encierra un cierto grado de inteligencia, lo que sabe el sistema y lo que puede hacer. Las clases tontas (aquellas con pocas responsabilidades) pueden modelarse de manera que acten como sirvientes de unas pocas clases listas (aquellas con muchas responsabilidades). Cada responsabilidad debe establecerse lo ms general posible. Las responsabilidades generales deben residir en la parte alta de la jerarqua de clases. Debe usarse el polimorfismo para definir las operaciones que generalmente se aplica a la superclase, pero que se implementan de manera diferente en cada una de las subclases. La informacin y el comportamiento asociado a ella, debe encontrarse dentro de la misma clase. Esto implementa el principio OO de encapsulamiento, los datos y procesos que manipulan estos datos deben empaquetarse como una unidad cohesionada. La informacin sobre un elemento debe estar localizada dentro de una clase, no distribuida a travs de varias clases. Una clase simple debe asumir la responsabilidad de almacenamiento y manipulacin de un tipo especfico de informacin. Esta responsabilidad no debe compartirse entre varias clases; si la informacin est distribuida, el software se torna ms difcil de mantener y probar. Compartir responsabilidades entre clases relacionadas cuando sea apropiado. Existen gran variedad de objetos que tienen el mismo comportamiento al mismo tiempo con atributos propios y todos deben actualizarse y visualizarse al ser utilizado el objeto.

3.2.3.

OPERACIONES,

MTODOS,

ASOCIACIONES

MULTIPLICIDAD.
Operaciones, mtodos y servicios. Un objeto encapsula datos (coleccin de atributos) y los algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, mtodos o servicios y pueden ser vistos como mdulos en un sentido convencional. Siempre que un objeto es estimulado por un mensaje, inicia algn comportamiento ejecutando una operacin. Cada una de las operaciones encapsuladas por un objeto proporciona una representacin de uno de los comportamientos del objeto. Por ejemplo: la operacin determinarcolor para el objeto coche extraer el color almacenado en el atributo color. La consecuencia de la existencia de esta operacin es que la clase coche ha sido diseada para recibir un estmulo (mensaje) que requiere el color de una instancia particular de una clase. Cada vez que un objeto recibe un estmulo, ste inicia un cierto comportamiento que puede ser tan simple como determinar el color del coche o tan complejo como la iniciacin de una cadena de estmulos que se pasan entre una variedad de objetos diferentes. Mensajes. Los mensajes son el medio a travs del cual interactan los objetos. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operacin. El siguiente esquema ilustra la interaccin entre objetos; una operacin dentro de un objeto emisor genera un mensaje (destino.operacin[parmetros]), donde destino define el objeto receptor el cual es estimulado por el mensaje, operacin se refiere al mtodo que recibe el mensaje y parmetros proporciona informacin requerida para el xito de la operacin. Los metodos son los procedimientos invocados cuando un objeto recibe un mensaje. El paso de mensajes mantiene comunicado un sistema OO. Los mensajes proporcionan una visin interna del comportamiento de objetos individuales y del sistema OO como un todo.

Encapsulamiento, herencia, polimorfismo. Los objetos encapsulan datos (los valores de los atributos que definen los objetos), operaciones (acciones que se aplican para cambiar los atributos de los objetos), constantes y otra informacin relacionada. Encapsulamiento significa que toda la informacin se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificacin o componente de programa, esto evita que un programa sea tan interdependiente que el ms mnimo cambio provoca efectos devastadores. Herencia significa que todas las estructuras de datos y algoritmos originalmente diseados e implementados para una superclase estn inmediatamente disponibles para una subclase. Cualquier cambio en los datos u operaciones en una superclase es heredado inmediatamente por todas las subclases que se derivan de la superclase. Por lo tanto, la jerarqua de clases se convierte en un mecanismo a travs del cual los cambios a altos niveles pueden propagarse inmediatamente a travs de todo el sistema. Es importante sealar que en cada nivel de jerarqua de clases, pueden aadirse nuevos atributos y operaciones a aquellos que han sido heredados de niveles superiores de la jerarqua. Mientras que un objeto es una entidad que existe en el tiempo y espacio, una clase representa una abstraccin, la esencia del objeto. Polimorfismo es una caracterstica que reduce el esfuerzo necesario para extender un sistema OO. El polimorfismo permite que un nmero de operaciones diferentes tengan el mismo nombre y esto reduce el acoplamiento entre objetos, haciendo a cada uno ms independiente.

3.2.4. ATRIBUTO DE ENLACE, CLASIFICACIN Y AGREGACIN.

Especificacin de atributos. Si tratramos de construir un sistema de estadsticas para jugadores profesionales de bisbol, los atributos del objeto jugador seran diferentes de los del mismo objeto cuando se use dentro del contexto de un sistema de pensiones para jugadores profesionales.

En el primer caso los atributos relevantes seran: nombre, posicin, promedio de bateo, porcentaje de estancia en el campo, aos jugados, partidos jugados. En el segundo caso algunos datos anteriores son importantes pero otros seran reemplazados por atributos como salario medio, crdito total, opcin elegida para la pensin, direccin postal, etc. Para desarrollar un conjunto significativo de atributos de un objeto, se debe estudiar la narrativa del proceso para el problema y seleccionar aquellos elementos que razonablemente pertenecen al objeto. Definicin de operaciones. Una operacin cambia valores de uno o ms atributos contenidos en el objeto, por lo tanto, debe tener conocimiento de la naturaleza de los atributos de los objetos y deben ser implementadas de manera que permita manipular las estructuras de datos derivadas de los atributos. Las operaciones se clasifican en 3 grandes categoras: 1. Operaciones que manipulan de alguna manera datos (aadir, eliminar reformatear, seleccionar). 2. Operaciones que realizan algn clculo. 3. Operaciones que monitorizan un objeto frente a la ocurrencia de un suceso de control. Categorizar las operaciones de un objeto. Para realizar esto, se estudia de nuevo el anlisis gramatical y se aslan los verbos, algunos de ellos sern operaciones legtimas y pueden conectarse fcilmente a un objeto especfico. Por ejemplo, a un sensor se le puede asignar un nmero y un tipo o que se programe una contrasea maestra para activar y desactivar el sistema; estas dos fases indican: a) Que una operacin de asignacin es relevante para el objeto Sensor. b) Que una operacin de programar se le aplicar al objeto Sistema. c) Que activar y desactivar son operaciones aplicables al Sistema (o sea que el estado del sistema puede en ltima instancia definirse usando notacin del diccionario de datos) como: estado del sistema = [ activado | desactivado ]

d) Es probable que haya que dividir la operacin programar en varias suboperaciones ms especficas requeridas para configurar el sistema. Programar implica configurar caractersticas del sistema, introducir datos, etc. La historia de la vida genrica de un objeto puede definirse reconociendo que dicho objeto debe ser creado, modificado, manipulado o ledo de manera diferente, y posiblemente

borrado. Para el objeto Sistema, esto puede expandirse para reflejar actividades conocidas que ocurren durante su vida, algunas de las operaciones pueden determinarse a partir de comunicaciones semejantes entre objetos tales como: mostrar, localizar, reiniciar, consultar modificar, llamar, etc. Agregacin. Un ordenador se construye a partir de una serie de componentes y en un sistema OO utilizado para dar soporte al proceso de fabricacin, existir una relacin de agregacin entre la clase utilizada para describir el producto fabricado y cada uno de sus componentes. Producto Manufacturado Agregacin.

Componente

La lnea con un rombo en un extremo indica que la clase describe objetos que agregan otros objetos, la clase con el rombo unido a ella describe objetos que contiene objetos definidos por la otra clase. Composicin. Es una forma especial de agregacin; se usa cuando se tiene una situacin en la que un objeto contiene un nmero de otros objetos y cuando el objeto contenedor se elimina todas las instancias de los objetos que estn contenidos desaparecen.

Por ejemplo, una clase Cliente que representa clientes en un banco tendr una relacin de composicin con las cuentas que el cliente posee, porque si el cliente se elimina, por ejemplo, se mueve a otro banco, todas sus cuentas son eliminadas; esta forma de relacin se indica de manera muy similar a la agregacin, pero en esta ocasin el rombo est relleno en lugar de hueco. Asociaciones. La agregacin y la composicin son ejemplo especficos de una relacin entre dos clases. Una relacin ocurre entre dos clases cuando existe alguna conexin entre ellas. Ejemplo de una relacin de asociacin: una clase administrador se relaciona con la clase empleado en virtud de que un administrador dirige a un nmero de empleados. Ejemplo de una relacin de agregacin: una clase InformeBancario se relaciona con la clase Transaccin en virtud de que el informe contiene detalles de cada transaccin. Las asociaciones entre clases se documentan en trminos de la multiplicidad de la asociacin y del nombre de la asociacin. Colaboraciones. Durante la ejecucin de un sistema OO, los objetos interactuarn con cada uno de los otros. Por ejemplo, en un sistema bancario, un objeto Cuenta puede enviar un mensaje a un objeto transaccin para crear una transaccin que ha ocurrido en una cuenta, por ejemplo, una cuenta de cargo. Este tipo de informacin es importante para el DOO durante el proceso de la identificacin y validacin de clases.

3.3. DESCRIPCIN DEL MODELO DINMICO.

Tratan los aspectos de comportamiento de la arquitectura del programa, indicando como puede cambiar la estructura o la configuracin del sistema en funcin de los acontecimientos externos. Aqu se modela el comportamiento durante el proceso de explotacin del sistema, consistiendo en identificar y modelar los estados por los que pasan los diferentes elementos/clases que forman el modelo, as como los flujos de datos existentes entre ellos.

La naturaleza un proceso de simulacin dirigida por eventos, es de carcter totalmente secuencial. Esto disminuye este modelado, ya que en la metodologa UML, el modelo dinmico est orientado al modelado de sistemas concurrentes y/o interactivos. Las clases modeladas no poseen gran cantidad de estados, como ejemplo, en la Figura 27 se muestra el diagrama de estados de la clase transicin en la que se observa la existencia nicamente dos estados. Por este motivo no se ha considera necesario presentar los diagramas de estado del resto de la clases.

Diagrama de estados de la clase transicin

En el Modelo Dinmico se representan aspectos relacionados con las secuencias posibles de eventos (vidas posibles) y la interaccin entre objetos. Para representar estos aspectos, tenemos dos tipos de diagramas: Diagrama de Transicin de Estados (DTE) Diagrama de Interaccin de Objetos (DIO) Modelos Dinmicos para Proyectos de Desarrollo de Software. A continuacin, se presentan algunos modelos dinmicos cuyas aportaciones fundamentales se centran en aadir nuevas capacidades y aplicaciones al Modelo de Abdel-Hamid y Madnick. Estos modelos se pueden dividir en dos grandes grupos: 1. Los de carcter general creados para simular entornos especficos de desarrollo dentro de una determinada organizacin. Entre estos modelos destacan:

El Modelo SEPS (Software Engineering Process Simulation). Elaborado en el laboratorio JPL (Jet Propulsion Laboratory). Diseado para simular el comportamiento de proyectos grandes considerando la existencia de un doble ciclo

de vida: el proceso de desarrollo propiamente dicho y el proceso de toma de decisiones. Adems, introduce sistemas expertos con lgica fuzzy en la interfaz del modelo.

El Modelo de Draper Laboratory. El Modelo de Draper constituye una ampliacin del Modelo de Abdel-Hamid y Madnick. Presenta como novedad la incorporacin de la etapa de Anlisis de Requisitos (no tratada en el Modelo de Abdel-Hamid y Madnick) contemplando la posibilidad de que estos requisitos puedan cambiar a lo largo del proyecto e incorpora tambin una serie de variables y relaciones para analizar la influencia que puede tener en el proyecto las relaciones con el cliente.

2. Los de carcter especfico para analizar problemas concretos presentados en la gestin de PDS. Entre estos modelos destacan:

El Modelo de Chichacly. Este modelo realizado para estudiar el impacto de un cambio de tecnologa, concretamente el cambio de C a C++, dentro de una empresa de desarrollo de aplicaciones para Macintosh poniendo de manifiesto la reaccin de oposicin o resistencia por parte de los tcnicos ante la implantacin de cualquier tipo de cambio en las tcnicas o mtodos de trabajo empleados normalmente.

El Modelo Aranda/Friddaman/Oliva. Este modelo aade aspectos nuevos al modelo de Abdel-Hamid y Madnick como son los efectos del empleo de las tcnicas TQM (Total Quality Management) para el control de calidad, la ampliacin del horizonte temporal del proyecto con el fin de recoger las diferentes versiones del software producido y el estudio del impacto comercial del producto final.

El modelo Multiproyecto. Este modelo estudia las transferencias netas de personal que se producen cuando interactuan dos proyectos por los mismos recursos.

3.3.1. SIMBOLOGIA.

3.3.2. SUCESOS Y ESTADOS.

Suceso: estmulo individual de un objeto a otro. Ocurre en un determinado instante y no tiene duracin. Estado: valores de los atributos y enlaces de un objeto en un instante dado. Diagrama de Estado: patrn de sucesos, estados y transiciones entre estados para una clase determinada. El Modelo Dinmico consiste en mltiples diagramas de estado, uno por cada clase con comportamiento dinmico significativo. La definicin de sucesos y estados depende del nivel de abstraccin que se utilice. Sucesos. Dos sucesos pueden darse consecutivamente de forma lgica (causa- efecto) o no (concurrentes). Son un medio de transmisin de informacin de un objeto a otro, unidireccional. Clase de sucesos: indica estructura y comportamiento comunes. Pueden contener atributos para expresar la informacin que manejan. Ejemplos: Pulsacin de un botn del ratn(botn, posicin). Salida de un vuelo(avin, nmero vuelo, ciudad)

 3.3.3. ESCENARIOS. Escenario: secuencia de sucesos que tienen lugar durante una ejecucin particular del sistema. Ejemplo: 1. el llamador descuelga el telfono 2. comienza el tono de marcado 3. el llamador pulsa dgito(1) 4. finaliza el tono de marcado 5. el llamador pulsa dgito(1) 6. el llamador pulsa dgito(2) 7. el telfono destino comienza a sonar 8. el tono de llamada aparece en el telfono llamador Escenarios y trazas de sucesos. Pueden enviarse sucesos concurrentes. La descripcin de escenarios es el primer paso del modelo dinmico, al que debe seguir la identificacin de los objetos emisores y receptores de sucesos. Diagrama de traza de sucesos (DTS): especifican la secuencia de sucesos en el tiempo. En la etapa de diseo hay que refinar los DTSs. 9. el destinatario descuelga 10. el telfono receptor deja de sonar 11. el tono de llamada desaparece en el telfono llamador. 12. los telfonos se conectan. 13. el destinatario cuelga 14. los telfonos se desconectan 15. el llamador cuelga

3.3.4. DIAGRAMA DE ESTADOS.

Estados. Abstraccin de los valores de los atributos y enlaces de un objeto. Especifica la respuesta de un objeto a los sucesos que llegan (accin/cambio de estado). Representan intervalos de tiempo.

 En su definicin, se ignoran los atributos que no intervienen en el comportamiento del objeto. Diagrama de estado. Relaciona Sucesos y Estados. El siguiente Estado depende del Suceso recibido y del Estado actual. Las transiciones para abandonar un Estado deben corresponder a sucesos diferentes. Si un Suceso no genera una transicin que abandone el Estado, se ignora. Los Estados no definen por completo todos los valores del objeto. Pueden representar bucles continuos o ejecuciones no repetitivas. Los diagramas que representan ejecuciones no repetitivas: Tienen estados iniciales y finales

Se utilizan como subrutinas referenciadas desde diversos diagramas de ms alto nivel.

Diagramas de Transicin de Estados. Los DTE se utilizan para describir el comportamiento de los objetos estableciendo las sus vidas posibles. Una vida de un objeto, es una secuencia de eventos que caracteriza un comportamiento correcto para todos los objetos de la clase. En este contexto, los estados del DTE denotan situaciones en las que pueden encontrarse los objetos durante su existencia como consecuencia de la ocurrencia de eventos relevantes. Las transiciones representan cambios de estado permitidos que pueden restringirse introduciendo condiciones. La especificacin de una transicin es la sintaxis siguiente: evento | accin transaccin if precondicin [when condicin de control ] Una precondicin es una condicin definida sobre atributos del objeto que debe satisfacerse en el estado de partida para que el servicio pueda ocurrir. Una condicin de control es una condicin que sirve para evitar el posible no-determinismo entre dos o ms transiciones que partiendo del mismo estado van a estados diferentes, estando etiquetadas con la misma accin.

DTE para la clase COCHE.

Diagrama de Interaccin de Objetos. La interaccin entre objetos se modela grficamente mediante un Diagrama de Interaccin entre Objetos (DIO). En el DIO podemos especificar dos interacciones bsicas: Disparos: son servicios de una clase que se activan de forma automtica cuando se satisface una condicin un objeto dicha clase. Interacciones Globales: son transacciones compuestas por servicios de clases diferentes. Los disparos se definir dibujando una flecha que vaya de la cabecera de una clase a la accin disparada y etiquetada con la condicin de disparo.

Coche con renovacin automtica de su pliza de seguro.

Las interacciones globales se introducen conectando los servicios que componen la interaccin nominndola mediante un identificador de interaccin global comn.

Interaccin global que involucra a objetos de tres clases.

3.3.5. CONDICIONES Y OPERACIONES.

Condiciones. Funciones lgicas sobre los valores de los objetos. Se indican entre corchetes. Vlidas durante un intervalo de tiempo. Se pueden utilizar como guardas sobre las transiciones: se disparan slo si se cumple la condicin.

Condiciones.

Operaciones. Estn asociadas a las transiciones entre Estados. Tipos: Acciones: operacin instantnea asociada a un suceso. Tambin pueden representar operaciones de control interno. Actividades: operacin con duracin en el tiempo, asociada a un Estado. Notacin:

Operaciones.

3.3.6. FUNDAMENTOS DE ESTADO.

Diagramas de Estado Anidados. Los diagramas de estado se pueden estructurar de forma similar a la de los objetos: Generalizacin: actividades de anidamiento que permiten organizar los Estados y Sucesos de forma jerrquica Agregacin: permite la descomposicin de un Estado en componentes ortogonales, siendo equivalente a la concurrencia de los Estados. Anidamiento de Estados. Una actividad en un Estado puede expandirse como un Diagrama de Estado de nivel inferior, en el que cada Estado representa una etapa de la actividad.

 Los Sucesos tambin pueden expandirse en Diagramas de Estados subordinados.

Anidamiento de estados.

Generalizacin. En general, los Estados en un Diagrama anidado pueden interactuar con otros Estados. Los Estados pueden tener subestados que heredan sus transiciones, a menos que las reemplacen por otras equivalentes.

Estados en un diagrama anidado que interactan con otros estados.

Concurrencia. Un Diagrama de Estados para un sistema compuesto es una coleccin de diagramas, uno por cada componente. La agregacin implica Concurrencia.

Los Diagramas de Estado de los componentes suelen ser independientes, pero pueden interactuar (las guardas de las transiciones para un objeto en un determinado estado pueden depender de otro objeto). Concurrencia dentro de un objeto: Podemos dividir un objeto en subconjuntos de atributos y enlaces, cada uno con su propio diagrama.

Concurrencia.

Acciones de Entrada y Salida. Acciones que se ejecutan cuando se entra o se sale de un Estado por cualquier suceso. Estas acciones se simplifican cuando todas las transiciones impliquen esas mismas acciones para la entrada o la salida. Orden de ejecucin de las acciones: Acciones en la transicin que llega. Acciones de Entrada. Actividades. Acciones de Salida. Acciones en la transicin de Salida.

Acciones de entrada y salida.

Acciones internas. Un Suceso puede provocar que se ejecute una accin sin cambiar de Estado. En la notacin se refleja como suceso / accin.

Acciones internas

Transiciones automticas y envos de sucesos. Transiciones automticas: Se dispara siempre que la actividad asociada con el Estado fuente ha terminado, y se cumplen las condiciones de las guardas (transiciones lambda). Envo de Sucesos: Los sucesos pueden dirigirse a un solo objeto o a un conjunto de ellos. La recepcin concurrente de Sucesos de denomina condicin de carrera (race condition). No es un error de diseo pero en general no deseadas:

Envo de sucesos a un objeto.

Sincronizacin de actividades concurrentes. A veces, un objeto puede realizar actividades de forma concurrente.

Actividades sincronizadas de un objeto.

Los pasos internos de las actividades no han de estar sincronizados, pero todas ellas han de completarse para poder pasar al siguiente Estado: Divisin del control (split) Fusin del control (merge) Relacin entre modelo de objetos y modelo dinmico. El Diagrama de Estados describe toda o una parte del comportamiento de un objeto de una clase. Los Estados son los equivalentes a los valores de los atributos y enlaces de las clases. Los Sucesos se pueden representar como operaciones en el Modelo de Objetos. La estructura del Modelo Dinmico est relacionada y restringida por la del Modelo de Objetos (generalizacin por restriccin). Un Estado Compuesto es el agregado de ms de un subestado concurrente.

En el Modelo de Objetos hay tres fuentes de concurrencia:

1. Concurrencia entre componentes: cada componente tiene su propio Estado independiente. 2. Concurrencia entre partes de un componente: agregacin dentro de un objeto. 3. Concurrencia del objeto: comportamiento concurrente de un objeto. El Modelo Dinmico de una clase lo heredan sus subclases. La jerarqua de Sucesos es independiente de la jerarqua de clases (pueden definirse a travs de diferentes clases de objetos, y son ms expresivos que las operaciones). Consejos prcticos. Construir Diagramas de Estado slo para las clases con comportamiento dinmico significativo. Utilizar escenarios. Considerar slo los atributos relevantes. Verificar la consistencia de los diferentes Diagramas de Estado. Considerar las necesidades de la aplicacin a la hora de decidir el grado de granularidad de los Sucesos y Estados. Distinguir entre actividades y acciones. Poner acciones de entrada cuando todas las transiciones entrantes generen la misma accin. Idem para las de Salida. Utilizar Estados anidados cuando las mismas transiciones se apliquen a varios Estados. Intentar mantener los Diagramas de estados de las subclases independientes de los de las superclases. Tener cuidado con las posibles condiciones de carrera en los Diagramas de Estado.

3.4. DESCRIPCIN DEL MODELO FUNCIONAL.

El modelo funcional se utiliza para representar la jerarqua funcional de un sistema. Permite la descripcin de las actividades o procesos, que son realizados dentro del negocio y que sern automatizados con el sistema. Un Diagrama Conceptual de Usuario (DCU) es una herramienta por medio de la cual se integra del modelo funcional, el modelo funcional permite representar un sistema completo o una funcin de negocio como un conjunto de procesos de negocio (o actividades) conectados entre s a travs de informacin compartida, los cuales interactan con miembros de la organizacin a travs de flujos de entrada o salida de informacin.

Esquema de un DCU.

Dentro del DCU se describe: Un conjunto de componentes funcionales (funciones o procesos) que resultan de descomponer a la funcin diagramada en actividades ms particulares. Un conjunto de elementos de informacin de entrada o salida (entradas, salidas, agregados de entradas y agregados de salidas) asociados a los componentes funcionales definidos dentro del diagrama. Un conjunto de informacin almacenada (agregados de informacin y entidades) requerida por los componentes funcionales dentro del diagrama. Un conjunto de flujos de informacin (representados por ligas en el diagrama) entre los elementos funcionales y los elementos de entrada, salida o informacin almacenada. Caractersticas generales. El modelo funcional especifica lo que sucede, el modelo dinmico cundo sucede, y el modelo de objetos sobre qu entidades sucede. Define el significado de: a) Las operaciones y restricciones del Modelo de Objetos. b) Las acciones del Modelo Dinmico. Slo expresa qu valores de salida se derivan de qu valores de entrada.

Consta de mltiples DFD s que muestran el flujo de valores desde las entradas externas, pasando por las operaciones y almacenes internos, hasta las salidas externas.

3.4.1. SIMBOLOGA.
Este modelo utiliza los diagramas de flujo de datos (DFD) para describir la transformacin de entradas a salidas. Aunque el DFD proporciona una visin global bastante conveniente de los componentes funcionales del sistema, no da detalles de stos.

Proceso

Actores

Nombre del actor

Flujo de datos

Almacenes de datos

Nombre del almacn

3.4.2. DIAGRAMA DE FLUJO DE DATOS.

Notacin clsica para definir el Modelo Funcional a travs de mltiples DFDs. Un DFD muestra la relacin funcional de los valores que calcula el sistema. Sus elementos fundamentales son: a) Procesos. b) Flujos de Datos (y en ocasiones, de control). c) Entidades Externas (Actores). d) Almacenes de Datos.

Ejemplo de un DFD.

3.4.3. FLUJO DE DATOS, ACTORES Y ALMACN DE DATOS.

El proceso. Un proceso es una transformacin de datos, los procesos de ms bajo nivel son funciones puras sin efectos laterales. Pueden especificarse matemticamente o en lenguaje natural. Un DFD entero puede verse como un proceso de ms alto nivel. El sistema puede verse como un proceso que se va descomponiendo por niveles donde los procesos definen patrones de entradas y salidas. Se corresponden con operaciones de clases. El objeto destino suele ser uno de los objetos de entrada, sobre todo si esa misma clase es tambin un flujo de salida; se representan mediante elipses que contienen una descripcin de la transformacin (normalmente su nombre). El flujo. Se representa grficamente por medio de una flecha que entra o sale de un proceso, se usa para describir el movimiento de bloques o paquetes de informacin de una parte del sistema a otra; mientras que los almacenes representan datos en reposo. Los flujos muestran una direccin (cabeza de la flecha) uni o bidireccional que indica si los datos se estn moviendo hacia adentro o afuera de un proceso.

Los datos que se mueven a lo largo del flujo viajarn ya sea a otro proceso (como entrada), a un almacn o a un terminador. Representan valores o conjuntos de valores que se transmiten de un clculo a otro. Conectan la salida de un actor o proceso con la entrada de otro. Pueden descomponerse o duplicarse para ser entrada de diferentes procesos. Varios flujos de datos pueden unirse en uno para convertirse en un dato agregado.

Flujo de un DFD. El almacn. Se utiliza para modelar una coleccin de paquetes de datos en reposo, se refieren a los archivos o bases de datos, independientemente de la forma fsica que tome8. Los almacenes se conectan por flujos de procesos desde o hacia l. Son objetos pasivos que almacenan datos y solo responden a peticiones de obtener, eliminar o actualizar datos. Suelen ser conjuntos de datos heterogneos a los que se les puede acceder en orden diferente al de insercin. Se representan por un par de lneas paralelas que contienen el nombre del almacn.

Almacn de datos. Es un entorno de datos separado que no est directamente integrado con las aplicaciones del da a da, pero abarca todos los datos utilizados por una empresa. En cierto sentido, es una gran base de datos independiente que contienen algunos, pero no todos los datos almacenados en la base de datos que sirven al conjunto de aplicaciones requeridas en un negocio, esta tiene ciertas diferencias con la base de datos:

Orientacin por materia. Un almacn de datos est organizado por las materias importantes del negocio, ms que por los procesos o funciones del negocio, ms que por los procesos o funciones del negocio. Esto nos lleva a una exclusin de datos que podran ser necesarios para una funcin particular del negocio, pero que generalmente no son necesarios para la minera de datos.

Integracin. Sin tener en cuenta la fuente de datos, da consistencia nombrar convenciones, unidades y medidas, estructuras de codificacin y atributos fsicos incluso cuando la inconsistencia existe a travs de las diferentes bases de datos orientadas a aplicaciones.

Restricciones de tiempo. Para un entorno de aplicacin orientada a transaccin, los datos son precisos en el momento del acceso y por un periodo de tiempo relativamente pequeo antes del acceso. Sin embargo, en un almacn de datos, se accede a los datos en un momento especfico del tiempo.

No volatilidad. A diferencia de las tpicas bases de datos de aplicaciones de negocios que atraviesan una continua corriente de cambios (insertar, borrar, actualizar), en el almacn de datos se cargan, pero despus de la primera transferencia cambian los datos.

Actores. Son objetos activos que conducen el DFD produciendo o consumiendo sus valores (terminadores). Definen los lmites (el contexto) del sistema, pueden ser usuarios del sistema o elementos hardware en sistemas de TR. Representados por un cuadrado con el nombre del actor.

Actores.

Los requisitos permiten crear un conjunto de escenarios que identifiquen una lnea de utilizacin para el sistema que va a ser construido. Los escenarios (casos de usos) facilitan una descripcin de cmo se usar el sistema. Para crear un caso de uso, el analista debe identificar los diferentes tipos de personas o dispositivos que utiliza el sistema o producto. Estos actores actualmente representan papales que la gente o dispositivos juegan como impulsores del sistema. Un actor es algo que comunica con el sistema o producto y que es externo al sistema en s mismo. Un actor y un usuario no son la misma cosa; un usuario normal puede jugar un nmero de papeles diferentes cuando utiliza un sistema y un actor representa una clase de entidades externas que lleva a cabo un papel. Se pueden definir cuatro actores: programador, probador, supervisor e investigador, no todos se identifican en la primera iteracin. Los actores iniciales interactan para conseguir funciones del sistema y derivar el beneficio deseado del sistema, ellos trabajan directa y frecuentemente con el software; los actores secundarios existen para dar soporte al sistema que los actores iniciales han dado forma con su trabajo.

3.4.4. FLUJO DE CONTROL.

Para los sistemas de tiempo real se requiere modelar flujos de control, es decir seales o interrupciones, se requiere una manera de mostrar procesos de control cuya nica labor es coordinar y sincronizar las actividades de otros procesos. Un flujo de control puede imaginarse como un conducto que porta una seal binaria, no porta datos con valores, se manda de un proceso a otro (o de algn terminador externo a un proceso).

Un proceso de control puede considerarse como un proceso supervisor o ejecutivo, cuya labor es coordinar las actividades de otros procesos en el diagrama; sus entradas y salidas consisten solo de flujos de control. Los flujos de control salientes del proceso de control se utilizan para despertar a otros procesos, los flujos de control entrantes generalmente indican que uno de los procesos ha terminado su labor o que se ha presentado alguna situacin extraordinaria, de la cual necesita informarse al proceso de control. Cuando el flujo de control despierta un proceso normal, este procede a llevar a cabo su labor como lo describe la especificacin del proceso. Sin embargo, el comportamiento interno de un proceso de control es diferente, aqu es donde el comportamiento dependiente del tiempo del sistema se modela con detalle. El interior del proceso de control se modela con un diagrama de transicin de estados que muestra los varios estados en los que se puede encontrar todo el sistema y las circunstancias que lo llevan a cambiar de estado.

Un DFD no expresa relaciones temporales, de control, ni orden de ejecucin. Slo muestra los posibles caminos de cmputo.

Existen funciones de decisin que no proporcionan datos pero s son desencadenantes de otro proceso.

Un flujo de control es un valor lgico que expresa un evento necesario para un clculo. Slo debemos usarlos cuando sean tiles, ya que duplican informacin del Modelo Dinmico.

Existen Mtodos basados en DFDs con notaciones extendidas para denotar el control, como CODARTS, para diseo de sistemas de TR distribuidos.

DFD CODARTS para el diseo de sistemas de TR distribuidos.

Niveles de descomposicin de un DFD. El proceso de definicin del Modelo Funcional es usualmente descendente (topdown). Cualquier proceso puede descomponerse como un nuevo DFD que detalla su funcionamiento. Cada entrada o salida del proceso debe existir en el nuevo DFD. El nuevo DFD puede contener Almacenes que no se mostraban en el DFD de nivel superior. Podemos estudiar separadamente cada DFD en cualquier nivel del rbol. Restricciones de un DFD. Muestran relaciones en un instante de tiempo: a) Entre dos objetos (Ej.: frecuencia y longitud de onda). b) Entre valores de un mismo objeto.

Estas relaciones pueden ser: a) Funciones totales: un valor se calcula a partir del otro. b) Funciones parciales: un valor impone restricciones al otro. Una restriccin sobre los valores (estado) de un objeto a lo largo del tiempo es un invariante. Ejemplo: una transformacin de coordenadas podra especificar que el factor de escala para las coordenadas x e y sea el mismo. Especificacin de Operaciones. Cada proceso de bajo nivel es una operacin en un objeto. Un proceso de ms alto nivel puede tambin ser una operacin. Las implementaciones pueden organizarse de otras maneras por motivos de optimizacin. La especificacin de una operacin incluye: a) Signatura (interfaz): Parmetros y valores de retorno. b) Transformacin: Efectos de la operacin. Formas de Especificar Operaciones:

Funciones matemticas o lenguajes funcionales. Tablas de valores de E/S (si sus rangos son finitos y reducidos). Pre y postcondiciones de un sistema axiomtico. Tablas de decisin. Pseudocdigo. Lenguaje natural.

Consistencias con otros Modelos. Muchas veces, hay una correspondencia por niveles. Un proceso de alto nivel se corresponde con una operacin en un objeto compuesto, y sus procesos de segundo nivel corresponden con operaciones sobre los objetos contenidos. Los Procesos indican relaciones funcionales entre clases.

De entre los flujos de datos entrantes a un Proceso, suele haber uno que es el objeto destino de la operacin, y los dems son parmetros, es decir, objetos que son utilizados por el objeto destino. Se dice entonces que el objeto destino es un cliente de los dems, que son proveedores. Los almacenes de datos son clases de objetos pasivos. Si la entrada de un proceso viene de un almacn de datos, ste suele ser el destinatario de la operacin. Si la salida de un proceso es un almacn de datos, el almacn es el objeto destino. Los actores son clases del Modelo de Objetos, y sus flujos de datos, operaciones. Por su carcter activo, suelen necesitar una definicin dinmica. Los flujos de datos son valores del M.O. Bien sean datos bsicos: nmeros, cadenas, etc. Bien objetos, que pueden ser los responsables de las operaciones que representan los procesos o parmetros de operaciones sobre otros objetos