Análisis y Diseño Estructurado

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Análisis y Diseño Estructurado"

Transcripción

1 Capítulo 5 Análisis y Diseño Estructurado 5.1 Metodología AS/DS Que tipo de Modelo debemos construir? 1. Construir un modelo de la implantación del sistema actual? 2. Construir uno de la implantación nueva que se propone? 3. Un modeloindependientede latecnología deimplantación? 4. Las tres cosas? El enfoque del Modelo Clásico Siempre se considero la construcción de cuatro modelos distintos a desarrollar, ellos son: Físico Actual: el que esta actualmente empleando el usuario (manual, automatizado o mezcla). Lógico Nuevo: requerimientos puros o esenciales del sistema nuevo que el usuario quiere. Lógico Actual: es el modelo de los requerimientos puros o esenciales que realiza el sistema actual del usuario. Físico nuevo: un modelo que muestre las limitaciones impuestas por el usuario, una de estas limitaciones es la frontera de automatización (es decir cuales funciones se automatizaran y cuales se desarrollaran manualmente). El modelo físicoes loque llamamos modelo de implementación del usuario. El enfoque clásico supone que: ² El analista puede no estar familiarizado con el área de aplicación o del negocio, por ello es importante que comience con un modelo físico actual, luego transformar el modelofísicoen modelológico. ² El usuario puede estar renuente o imposibilitado para trabajar con el nuevo modelo lógico al principio. Ejemplo 5.1 Desconfía de la capacidad del analista, o no estar de acuerdo con él. 159

2 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 160 Programa del proyecto FISICO ACTUAL Módelo físico actual LOGICO ACTUAL Módelo lógico actual LOGICO NUEVO Módelo lógico nuevo FISICO NUEVO Módelo físico nuevo Figura~5.1: Los cuatro modelos de SA/SD ² La transformación deun modelológicoactual en un modelo lógiconuevo norequiere de mucho trabajo. Estas apreciaciones son correctas, pero normalmente se ignora el peligro de que desarrollar un modelodel sistema actual puede requerir de bastante tiempo y esfuerzoy hace que el usuario se frustre y termine cancelando el proyecto. No se tiene que modelar el Sistema Actual como un n en si mismo, sino como un medio para lograr el sistema de implementación del usuario. Si existelaposibilidad deevitarel modelodel sistemaactual, hayqueevitarlo (perdida de tiempo, esfuerzo, etc). El nuevo sistema conocido como el nuevo sistema lógico, lo conocemos aquí como el modelo esencial del Sistema. El modelo esencial, es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mínimo posibledecomo se harála implementación.- Esto signi ca que en la construcción del modelo se tiene disponible una tecnología perfecta y que se puede obtener fácilmente y sin costo. De ninguna manera habría que asociarlo a la implementación Di cultad en su construcción Resulta muy difícil eliminar todos los detalles de implementación en el modelo esencial, algunos ejemplos de esos detalles son: ² Secuenciado arbitrario de las actividades de un modelo de ujo de datos. El único secuenciado en el diagrama de ujo de datos debe ser el que requieren los datos. ² Archivos innecesarios, es decir, los almacenes de datos que no se requerirían de existir unatecnologíaperfecta. Los archivostemporales serequieren en un modelo

3 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 161 de implantación porque los procesos están programados para hacer su trabajo en distintos tiempos; también seintroducen parapropósitos derespaldoyrecuperación, porque la ² Tecnología de implantación es propensa a errores, así como las personas que operan las computadoras. ² Revisión de errores y validación innecesarias de datos y proceso dentro del sistema.. Dichas actividades de validación senecesitan en un modelo de implantación, porque sedebe trabajar con procesospropensos aerrores y canales ruidososdedatos entre procesos. ² Datos redundantes oderivados. Estos se incluyen aveces en los almacenesdedatos para propósitos de e ciencia; aunque esto usualmente es razonable, debe hacerse durante la fase de diseño del proyecto, y no durante el modelado de las funciones y datos esenciales. También, sin darsecuenta, sepueden incluir datos derivables. El modelo esencial posee dos componente 1. Modelo ambiental (frontera entre el sistema y el resto del mundo) 2. Modelo de comportamiento. Describe el comportamiento para que interactúe de manera exitosa en el ambiente (DFD, D-E-R., D.D, DTE, EP, etc). Existen circunstancias que es necesario desarrollar un modelo de implantación (del sistema actual) antes de construir el modelo esencial (se puede deber a que el usuario no este convencido de que se entienda completamente su negocio, o simplemente que el analista necesita estudiar el ambiente actual antes de proponer un sistema nuevo). Una vezdesarrolladoel modelode laimplementación actual, su tareasiguiente es de - nir en términos lógicos, (eliminar detallesde implantación) usualmente tienelos siguientes pasos: 1. Buscary separar ujosesenciales quehayan sidoempaquetadosdemaneraarbitraria en el mismo medio. 2. Buscar ujos empaquetadosoagregados que seenvían aburbujas que norequieren de todos los datos que hay en dichos ujos. 3. Distinguir entre el trabajo esencial realizado por un proceso y la identi cación del procesador que aparece en el modelo de implantación. 4. Eliminarprocesoscuyoúnicatareaseatransportardatos de un lugar aotrodentro del sistema. 5. Eliminar proceso cuya labor sea veri car datos que se producen y usan dentro del sistema. 6. Buscar situaciones donde los almacenes esenciales se hayan empaquetadoen el mismo almacén.

4 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Eliminardatos delosalmacenes si ningún procesolos utiliza. Eliminar datosde los almacenes quesean derivables ocalcular. 8. Eliminaralmacenesde datos quesoloexistan comoseparadoresde tiempoentre procesos y que sean dependientes delaimplantación. Esto incluyearchivosintermedios, archivos de reportes, archivos de impresión y otros similares. 5.2 El Modelo Ambiental Cualquier sistema que se desarrolle será siempre parte de un sistema mayor, por ello, el primer modelo importante que se debe desarrollar es uno que de na la interfaz entre el Sistema y el resto del Universo (el ambiente), este modelo es lo que conocemos como modelo ambiental., modelo exterior del sistema. EL AMBIENTE EL SISTEMA Figura~5.2: Frontera entre el Sistema y el ambiente Así, el primer modelo importante que se debe desarrollar es uno que no haga más que de nir las interfases entre el sistema y el resto del universo, es decir, el ambiente (modela el exterior del sistema). El modelo del interior de sistema se conoce como modelo de comportamiento. Los sistemas que construimos son racionales y tienen propósito; especí camente, producen salidas como respuestas a algún acontecimiento, o estimulo, en el ambiente. Así, otro aspecto critico del modelo ambiental consiste en identi car los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. Solonosdebepreocuparaquellos acontecimientosqueocurran en el ambienteexterior y requieren una respuesta del Sistema. La frontera entre el Sistema y su ambiente es arbitraria. A menudo existe una área gris que esta abierta a negociaciones, un área sobre el cual el usuario no esta seguro, no había pensado, tenia algunas idea ya hechas al respecto, o todas las anteriores. Factores a tener en cuenta cuando se escoja la perspectiva del proyecto: ² El deseo del usuario de lograr una ciertaparticipación en el mercado para el producto o incrementarlas a mas desu nivel actual. Estopuedehacerseofreciendo un nuevo producto o una mayor funcionalidad de uno existente ofreciendo un servicio mas rápido y e ciente.

5 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 163 ² La legislación establecida por el Gobierno Federal, Estatal o de la Ciudad. ² El deseo del usuario por minimizar gastos operativos de algún área de su negocio. ² Deseo del usuario por lograr alguna ventaja estratégica para la línea de productos o área de negocios que opera. El áreadentro delafrontera del sistemaaveces se conocecomoel dominio decambios. Herramientas para de nir el ambiente 1. Declaración de propósitos 2. Diagrama de contexto 3. Lista de acontecimientos Declaración de Propósitos Es una declaración textual breve y concisa del propósito del Sistema, dirigida al administrativo superior.- También algún analista sugieren que la declaración de propósito debe incluir un resumen de bene cios tangibles y cuanti cables a tal vez un análisis decostobene cios El diagrama de contexto En una solo burbuja se debe representar todo el sistema. pedido-inmueble LOCATARIO INMOBILIARIA pedido-recepcionado LOCADOR inmueble-otorgado inmueble_ofertado Enfatiza las siguientes características: Figura~5.3: Diagrama de Contexto ² Las personas, organizaciones y sistemas con los que se comunica nuestro sistema, se conoce como terminadores. ² Los datos que recibe del mundo exterior. ² Los datos que el sistema produce y que se envían al mundo exterior. ² Los almacenes de datos que el sistema comparte con los terminadores. ² La frontera entre el sistema y el resto del mundo.

6 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Lista de acontecimientos Es una lista narrativa de los estímulos que ocurren en el mundo exterior a los cuales el sistema debe responder. En lalistaespeci camoscon las letra: F: ujo T: temporal C: Control El orientado a ujos es el que se asocia con un ujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algún dato (o varios). No existe una correspondencia uno a uno entre los ujos de datos del diagrama de contexto y los acontecimientos de la lista de acontecimientos. En general, cada ujo de datos es un acontecimiento (o, más precisamente, laindicación de queha ocurrido), obien es requerido por el sistema para poder procesar un acontecimiento. Los acontecimientos temporales, como su nombre lo indica, arrancan con lallegada de un momento dado en el tiempo. Algunos ejemplos de acontecimientos temporales pudieran ser: Ejemplo 5.2 A las 10:00Hs de lamañanas se requiere que elresguardo de lainformación este completo Ejemplo 5.3 La emisión de chequeras de pago debe estar completo para la semana entrante Los acontecimientos temporales no se inician con ujos de datos de entrada; podria imaginarse que el sistema tiene un reloj interno con el cual puede determinar el paso del tiempo. Estos acontecimientos pueden requerir que el, sistema solicite entradas de uno o mas terminadores. Por ello podrían asociarse uno o más ujos de datos con un acontecimiento temporal, aunque los ujos dedatos, en si, no representan el acontecimiento mismo. Los acontecimientos decontrol deben considerarse un caso especial del acontecimiento temporal. Un estimuloexterno que ocurreen algún momentoimpredecible. A diferencia de un acontecimiento temporal normal, el acontecimiento de control no se asocia con el paso regular del tiempo, por lo que el sistema no puede anticiparlo utilizando un reloj interno. Y a diferencia de un acontecimiento de ujo normal, el de control noindica su presencia con el arribo de datos. El ujo de control puede considerarse como un ujo de datos binario (on-o ). Los sistemas de información de negocios nosuelen tener ujos de control en sus diagramas de contexto. Como componentes adicionales del modelo ambiental tenemos: ² Los DD iniciales, que de ne todos los ujos y almacenes externos ² Los D E-R de los almacenes externos

7 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Construcción del modelo ambiental A pesar de que el desarrollo del modelo ambiental parezca simple y directa, a menudo resulta que requiere de una gran cantidad de trabajo; además; usualmente se desarrolla comounaseriedere namientositerativos, con datos adicionalesqueseañaden yre nan. Una razón importante por lacual muchos re namientos y revisiones suelen ser necesarios es que normalmente una sola persona no puede comprender la perspectiva completa del sistema como se de nió inicialmente. SI el proyecto involucra un nuevo sistema que remplazara a uno existente, es posible hablar con los usuarios que actualmente llevan a cabo sus funciones. Es importante dedicar una buena cantidad de tiempo y energía al modelo ambiental, pues a menudo es el punto focal de juntas y presentaciones importantes al comienzo de la vida de un proyecto de desarrollo de sistemas. De echo, a veces es la únicaparte del modelo global del sistema que muchos usuarios y administradores de alto nivel llegaran a ver (los que tienen la decisión de continuar o no con el proyecto). El diagrama de contexto consiste en terminadores, ujos de datos y ujos de control, almacenes de datos y un solo proceso que representa a todo el sistema. La parte más fácil del diagrama de contexto es el proceso, el nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido. Losterminadoressecomunican directamentecon el sistemaatravés de ujosdedatoso decontrol, otravésdealmacenesexternos. Losterminadoresnosecomunican directamente entre si. Algunos terminadores tienen un gran número deentradas y salidas, paraevitar un diagrama innecesariamente atiborrado conviene dibujar el terminador mas de unavez, en este caso los terminadores duplicados se los identi ca con asteriscos. Cuando el terminador es una persona conviene o es preferible indicar el rol que desempeña, más que su identidad. Es indispensabledistinguirlasfuentesy manejadorescuandosedibujan terminadores en el, diagramadecontexto. Un manejador es un mecanismo, dispositivo, o medio físico usado paratransportar datos hacia dentroo fuera del sistema. La tendencia es mostrar al manejador en lugar de la verdadera fuente de los datos. Tendríamos que evitar mostrar los manejadores, puesto queel nuevo sistemageneralmente tendrá opción de cambiar la tecnología mediante la cual los datos se introducen y sacan del sistema. Los ujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema, además de las señales de control que recibe o genera. Los ujos de datos se incluyen en el diagrama de contexto si se ocupan para detectar un acontecimiento en el ambiente al que deba responder el sistema, o si se ocupan para producir una respuesta. También estos ujos pueden aparecer parailustrarlos datos que son transportados entre los terminadores por el sistema. Finalmente, los ujos de datos se muestran en el diagrama de contexto cuando el sistema produce datos para responder a un acontecimiento. Se debe dibujar el diagrama de contexto bajo el supuesto de que las entradas son causadas e iniciadas por los terminadores, y que las salidas son causadas e iniciadas por el sistema. En los casos que el terminador no inicie las entradas (el terminador no sabe que el sistema requiere sus entradas) y que el sistema no inicie la generación de salidas debe mostrarse el mensaje como una parte esencial del sistema. La lista de acontecimiento es un listado sencillo de los acontecimientos del ambiente

8 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 166 a los cuales debe responder el sistema. Al crear esta lista se debe distinguir entre un acontecimientoy un ujorelacionadocon un acontecimiento. La manera más fácil de identi car los acontecimientos relevantes para un sistema es visualizarlo en acción: examinar cada terminador y preguntar que efecto pueden tener sus acciones sobre el sistema. Debe distinguirse entre acontecimientos discretos que se han empaquetado accidentalmente como si fueran uno solo; esto sucede a menudo con acontecimientos de tipo ujo. Debe examinarse el terminador candidato y preguntar si todas susinstanciasinvolucran los mismos datos, si en algunas instancias están presentes los datos, y ausentes en otras, podria en realidad haber dos acontecimientos distintos. La lista de acontecimientos debe incluir no solo las interacciones normales entre el sistema y sus terminadores sino también situaciones de falla. Dado que se esta creando un modelo esencial, no hay que preocuparse por fallas del sistema; pero se deben tomar en cuentaposiblesfallas oerrores causadas por los terminadores. Cabría preguntarnos Que se hace primero, el diagrama de contexto o la lista de acontecimientos?, larespuesta es NOIMPORTA mientras se produzcan ambos componentes del modelo ambiental y se revisen para asegurar que sean consistentes. Cuando se termine con ambos componentes del modelo ambiental será posible con rmar lo siguiente: ² El sistema necesita cada ujo de entrada del diagrama de contexto para reconocer que ha ocurrido un acontecimiento; debe necesitarlo para producir una respuesta a un acontecimiento, o ambas cosas. ² Cada ujodesalida debeser respuestaaun acontecimiento. ² Cada acontecimientonotemporal de la lista de acontecimientos debe tener entradas a partir de las cuales el sistema puede detectarlo. ² Cadaacontecimientodebeproducir salidas inmediatascomorespuestaobien almacenar losdatosque luegoserán salidas, odebieraocasionar un cambioen el estado del sistema. 5.3 El Modelo preliminar de comportamiento Una vez nalizado la consistencia del modelo ambiental y veri cado por todos los integrantes del grupo de análisis, se comienza a construir el modelo de comportamiento o modelo exterior del sistema. Se debe construir el modelo de comportamiento del sistema, es decir el modelo de comportamiento nal que el sistema debe tener para manejar con éxito el ambiente, esto involucra el desarrollo de un diagrama de ujo de datos y un diagrama de E-R preliminares, además de la elaboración de entradas iniciales del diccionario. Existen tres enfoques en el desarrollo del modelo de comportamiento: 1. El enfoque descendente clásico 2. El ascendente 3. El medio

9 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO El enfoque clásico Se procede la única burbuja del diagrama de contexto a un DFD de nivel Superior (Nivel 0), en donde cada burbuja representa un Subsistema Principal, cada burbuja del nivel 0, se parte a continuación en guras denivel inferior u cada burbuja de nivel inferior se parten aun mas, etc, hasta llegar a un nivel de burbujas atómicas (no requiere de mayor descomposición). Problemas en el presente enfoque: ² Parálisis del análisis ² El fenómenodeun ax -cantidad deanalistas ² Partición físicaarbitraria El enfoque medio Este requiere (después de desarrollar DFD inicial) una nivelación ascendente y también podríanecesitarse algunapartición descendente. El enfoque es el siguiente: 1. Se dibuja una burbuja o proceso por cada acontecimiento de la lista. 2. La burbuja se nombra describiendo la respuesta que el sistema debe dar al acontecimiento asociado. 3. Se dibujan las entradas y salidas apropiadas de tal forma que la burbuja pueda dar repuesta requerida y se dibujan los almacenes, como sea apropiado, para la comunicación entreburbujas. 4. El borrador de DFD que resultasecompara con el diagrama decontexto ylalista de acontecimientos para asegurar que este completo y sea consistente. El primer paso es directo, si existieran 30 acontecimientos en la lista, se deben dibujar 30 burbujas. El segundo paso también es directo: a cada burbuja se la da un nombre apropiado, basado en la respuestarequerida. Estosigni ca que se debe examinar el acontecimiento y preguntarnos que respuesta debe dar el sistema a este acontecimiento?. El tercer paso no es mecánico, pero usualmente es bastante directo, para cada burbuja dibujada, identi que las entradas que requiere para efectuar su trabajo. Identi que las salidas (si las hay) que cadaunaproduceeidenti quelos almacenesalosquecadaburbuja debe tener acceso. Esto se logra entrevistando a los usuarios. En muchos casos el acontecimiento esta determinado por el ujo; esto signi ca que el sistema detecta la ocurrencia de un acontecimiento por la llegada de algún dato de un terminador externo. Obviamente, esto signi ca que el ujo de datos apropiado debe estar conectado al proceso requerido para responder a tal acontecimiento. De manera similar, como parte de la respuesta dibuje las salidas adecuadas producidas por el proceso. Esto implicaradevolver salidas a los terminadores fuera del sistema, sin

10 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 168 embargo, puede también involucrar salidas que se envían a los almacenes de datos, para ser usadas como entradas de otros procesos. El cuarto paso es una actividad de veri cación de consistencia, similar a los pasos de balanceo de modelos. Veri que que cada entrada del diagrama de contexto para ver se estaasociadacon algunaentradadealgunodelos procesos del DFD preliminar; y veri que también que cada salida producida por algún proceso en el DFD preliminar se envié a un almacén oseaunasalidaexternaincluidaen el diagramadecontexto. Existen dos casos especiales: ² Acontecimientos únicosquecausan respuestas múltiples ² Acontecimientos múltiples que causan la mismarespuesta. En todosestoscasosningunodelosprocesos en el diagramade ujodedatospreliminar está conectado con otro: las burbujas no se comunican directamente con otras. En lugar de ello se comunican entre si a través de otros almacenes de datos. Esto es debido a que las burbujas en el diagrama preliminar representan respuestas a acontecimientos, y los acontecimientos queocurren en el ambiente externo son no sincronizados y dado que la respuesta a un acontecimiento puede requerir datos producidos por algún otro y, no hay forma de saber cuando ocurrirán los acontecimientos, y debe suponerse, en un modelo esencial, que cada proceso realizara su labor de manera in nitamente rápida, y cada ujo de datos actúa como conducto que puede transmitir datos con rapidez in nita, se sigue que la única forma de sincronizar múltiples acontecimientos interdependientes es mediante un almacén Desarrollo del Modelo Inicial de Datos Como el D E-R y DFD se desarrollan en paralelo, pueden usarse para revisarse entre si. Además la lista de acontecimientos es muy útil para crear del D E-R y el DFD inicial. El modelo de comportamiento inicial, una vez terminado, no se lo puede presentar al usuario debido a su complejidad (DFD, DER, etc), muchas burbujas, etc, lo que implica quenecesitaraun re namiento paraeliminary/oañadir objetos. Además presenta un segundo inconveniente, que el modelo de comportamiento inicial son grá cos casi sin ningún apoyo de textos. 5.4 El Modelo de Comportamiento Terminado del Modelo de Comportamiento El modelo inicial de comportamiento no puede ser presentado al usuario debido a su complejidad (DFD con 40 o mas burbujas, el DER con de niciones muy gruesas, compuesto básicamente de gra cas y poco apoyo de texto, etc) Terminado del Modelo de Proceso Nivelación del DFD preliminar Reorganizar el DFD (posee muchas burbujas), necesita de nivelación ascendente, es decir, agrupar procesos relacionadosen agregados con signi cado.

11 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 169 Existen tres reglas al hacer esto: 1. Con la agrupación de procesos deben involucrar respuestas relacionadas cercanamente. 2. Busque oportunidad de esconder o enterrar datos almacenados que aparecen en nivel inferior. Si ve un grupo de procesos en los DFD preliminares que se re eren a un almacén común, y no hay otros procesos en los DFD preliminares que sere eren a este almacén, entonces puede crear una burbuja de nivel superior para esconderlo. 3. Tenga presente que la personaque ve sus DFD, seaun usuario u otroanalista, no quiere ver demasiadoa lavez. Por ello, creeagregados ogrupos del DFD preliminar que consistan en aproximadamente. Muchas vecesnecesitan deunanivelación descendente. Cuandolosprocesos descriptos en el DFD son muy complejos para describirlos en una especi cación de proceso, tal vez sea necesario una nivelación descendente, es decir, construir un DFD de nivel inferior. Pasos para llevar a cabo una nivelación descendente En algunos casos es apropiado un enfoque de descomposición funcional pura, es decir, si encuentra una burbuja de proceso que realiza una función compleja, trate de identi car subfunciones, cada una de las cuales puede se hecha por una burbuja de nivel inferior. En otros casos, los ujos de datos de entradas y salidas proporcionaran la mejor guía paralanivelación descendente Como completar el DD En esta etapa (terminado del modelo) es necesario llenar la descripción del signi cado de cadadato, también sehacenecesario dividir los datos complejos en elementos menores. Hay que veri car que este completo y sea consistente (que ninguna parte contradiga a la otra), que este balanceado con los DFD, DER y las EP Como completarlas especi caciones de procesos No inicie la escritura de las especi caciones de proceso antes de concluir con el DFD preliminar. Cuando el DFD comience a estabilizarse, cuado ha pasado la prueba de la nivelación ascendente, entonces puede comenzar a escribir las especi caciones de proceso. Por ultimo, recuerde que las EP deben balancear con los DD y el DER Terminado del modelo de datos De la misma forma que los DFD, se empieza con un DER tosco y luego se re na y se mejora. Tenga en mente quela mayoríade las veces el DER sedesarrollaal mismo tiempo que el DFD.

12 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO El Modelo de Implementación Terminamos dedesarrollar el Modeloesencial de un sistemadeinformación, este tieneuna descripción completa de lo que el sistema debe hacer, especí camente describe: ² La política o lógica esencial de las funciones que se requiere realizar. ² El contenido esencial de los datos que almacenael Sistema y quese mueven a través de él. ² El comportamiento esencial dependientedel tiempoqueel sistema debeexhibirpara manejar señales e interrupciones del ambiente exterior. Con esta información seria su ciente para los diseñadores y programadores: se les daría el modelo esencial y se les permitiría escoger el mejor HARD, sistema operativo, sistema de administración de base de datos y el lenguaje de programación, dentro de las restricciones globales del proyecto, en tiempo, dinero y recursos humanos. No obstante seria necesario información adicional sobre cuestiones de implementación. El asunto de implementación de interés para el usuario es lafrontera de automatización, es decir, cuales parte del modeloesencial se van a implementar con la computadora y cuales se van a realizar manualmente por personal de la Organización. Es de interés para el usuario, mas que las funciones de Sistema, las entradas y salidas del mismo, este interés se va acrecentando por varias opciones y posibilidades que han aumentado la importancia de estas cuestiones de implantación. Algunas de ellas son: ² Los usuarios nales tienen oportunidades de usar computadoras personales como parte deuna red distribuidade computadoras. Cabríapreguntarnos Que parte del modelo esencial se asignaran las PC? Cuales se compartirán?. ² Losusuarios nalestienen oportunidad deescribirsuspropiosprogramasen lenguajes de cuarta generación. Se podria construir un prototipo de porciones del sistema utilizando un lenguaje de cuartageneración oun paquete degeneración deaplicaciones. Otra opción es la elección y compra de un paquete de software. Que parte de las funciones esenciales las implementará el paquete y cuales tendrá que hacer el usuario?. Todas estas cuestiones deben tratarse como parte del modelo de implementación del usuario. De manera generalizada, este cubre cuatro puntos: 1. Distribución del modelo esencial entre personas y maquinas. 2. Detalledela interacción humano-maquina. 3. Actividadesmanuales quesepodrían requerir. 4. Restricciones operativas que el usuario desea imponer al Sistema.

13 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Determinación de lafrontera de automatización Que funciones y que datos se manejaran manualmente y cuales se automatizaran. Esta es la cuestión. Aunque el usuario quiere que se desarrolleun sistema automatizado, también necesita unadeclaración bien hechadelos requerimientos delas funciones ydatos quequeden fuera de la frontera de automatización. Existen tres casos: 1. Al usuario no le importa donde esta la frontera de automatización. 2. El usuario escoge un sistema totalmente automatizado. 3. El usuario escoge un sistema completamente manual Determinación de lainterfaz humana Eslaactividad queconsumemas tiempoyloquemasinteresaal usuario. Involucracuatro partes. 1. Elección delos tipos deentradasy salidas. 2. El formato de las entradas. 3. El formato de las salidas. 4. Lasecuenciay los tiemposde I/Oen un sistemaen línea. Nota 5.1 Sobre este tema en particular se lo desarrolla completamente en el capitulo Identi cación de las actividades de apoyo manual adicional El usuario puede o no aceptar la existencia de una tecnología perfectaen el modelo esencial opuededecidir que ciertas porcionesdel sistemaautomatizadoestén bajosu propiocontrol operacional, opueden existir normaslegales que aseguren la integridad de los datos. Cualquierasea el caso, estas actividades de apoyoadicional se representaran por medios denuevos procesosen el DFD del modelode comportamiento. Generalmente tenemos que preocuparnospor laposibilidad delatecnologíadefectuosaen algunas áreas principales: ² Ingreso de datos al sistema ² Realización deloscálculos ² Almacenamiento a largo plazo ² Salida de datos del sistema ² Entrada o salidas redundante ² Tecnología de procesador redundante ² Redundancia interna ² Controles por lote ² Veri caciones secuenciales

14 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Especi caciones de restricciones operacionales El equipo de implantación tendrá que decidir lacombinación de Hardware, sistema operativo, equipodetelecomunicaciones, lenguajes deprogramación yestrategiasdediseñopara implementar mejor los requerimientos. A continuación se describen algunas cuestiones típicas de las restricciones operativas, restricciones que el modelo esencial evita: ² Volumen dedatos ² Tiempo de respuesta a las diversas entradas ² Restricciones políticas sobre modalidades de implantación ² Restricciones ambientales ² Restricciones de con abilidad ² Restricciones de seguridad

15 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Preguntas y Ejercicios de Revisión 1. Enumere y describa las cuatro modelos que propone el SA/SD. 2. Describa los problemas que se presentan en la construcción de los cuatro modelos del SA/SD. 3. De na Modelo Ambiental. Sus componentes. 4. Enumerey describa losrequerimientospara laconstrucción del ModeloAmbiental. 5. De na el Modelo Preliminar. Sus enfoques. 6. De na el Modelo de Comportamiento. Herramientas. 7. Como se debe complementar el Diccionario de Datos en el Modelo de Comportamiento. 8. Comosedebe complementar las Especi caciones de Proceso en el ModelodeComportamiento. 9. Que entiende por Terminado del Modelo de Datos. 10. De na el Modelo de Implementaión. 11. Que entiende poor Frontera de Automatización. 12. Queentioendepor Determinación de lainterfacehumana. 13. Queentiende por laidenti cación deloasactividades deapoyo Manual.

16 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 174 Referencia Bibliográ cas [7] E. Yourdon. Análisis y Diseño Estructurado. Yourden Press, 1980.

17 Parte III Análisis y Diseño Orientado a Objetos 175

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Modelo de Proceso: Ciclo de Vida Estructurado

Modelo de Proceso: Ciclo de Vida Estructurado Modelo de Proceso: Ciclo de Vida Estructurado Edward Yourdon (1999) Análisis Estructurado Moderno EL CICLO DE VIDA ESTRUCTURADO DEL PROYECTO Es importante verlo como un diagrama de flujo de datos. No es

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Capítulo 1 Sistemas de gestión de contenidos

Capítulo 1 Sistemas de gestión de contenidos Capítulo 1 Sistemas de gestión de contenidos Si hoy en día una persona se encuentra en Internet careciendo de una extensa funcionalidad o de un contenido actualizado, se encontrará en clara desventaja

Más detalles

Tema VII: Herramientas del Análisis Estructurado Diagramas de Flujos de Datos (DFD s)

Tema VII: Herramientas del Análisis Estructurado Diagramas de Flujos de Datos (DFD s) Tema VII: Herramientas del Análisis Estructurado Diagramas de Flujos de Datos (DFD s) Diana Marcela Sánchez Fúquene Índice Herramientas para el Análisis Estructurado Diagrama de Flujo de Datos Diccionario

Más detalles

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

Más detalles

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION UNIDAD V ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION Contenido: 5.1 Introducción 5.2 Principios del Análisis 5.3 Construcción de Prototipos del Software 5.4 Métodos de Análisis de Requisitos 5.5 La Especificación

Más detalles

En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información, por otro

En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información, por otro CAPITULO 5 TEORIA SOBRE ANALISIS Y DISEÑO DE SISTEMAS DE INFORMACION En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información,

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Diseño. Diseño. Implementación. Implementación. Fig. 1: Modelo de Ciclo de Vida en Cascada

Diseño. Diseño. Implementación. Implementación. Fig. 1: Modelo de Ciclo de Vida en Cascada Herramientas y Metodologías de Análisis y Diseño Estructurado Apunte de la Cátedra Metodologías de Desarrollo de Software I Claudia Marcos Edgardo Belloni Revisión Abril 1999: Carlos Rodríguez, Marcos

Más detalles

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS Existen diversos métodos para desarrollar un sistema de información o un microsistema, pero en esencia todos parten de los mismos principios

Más detalles

Introducción. Entre los modelos de análisis y diseño esta el estructurado.

Introducción. Entre los modelos de análisis y diseño esta el estructurado. Análisis y Diseño Orientado a Procesos Sección: 5T2_Co. Grupo: N 2 Docente: Ing. Magda Luna. Asignatura: Ingeniería De Software II Integrantes: Yessenia Del Carmen Meléndez Morales 2001-10007. Tania Margarita

Más detalles

Proceso de desarrollo del software modelo en cascada

Proceso de desarrollo del software modelo en cascada Proceso de desarrollo del software modelo en cascada Análisis: Necesidades del usuario especificaciones Diseño: Descomposición en elementos que puedan desarrollarse por separado especificaciones de cada

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Ingeniería de Negocios y Desarrollo de Sistemas de Información

Ingeniería de Negocios y Desarrollo de Sistemas de Información Ingeniería de Negocios y Desarrollo de Sistemas de Información Procesos de Negocios Modelos de negocio Ingeniería de Negocios: Notaciones Procedimientos Patrones Proceso de desarrollo de sistemas Metodologías

Más detalles

Elementos del modelo de análisis. Modelado del análisis

Elementos del modelo de análisis. Modelado del análisis Mecanismos del anál. Ingeniería del Software 1 Elementos del modelo de análisis Objetivos Describir lo que requiere el cliente Establecer base para la creación de un diseño SW Definir conjunto de requisitos

Más detalles

Análisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007

Análisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007 Análisis de Sistemas M.Sc. Lic. Aidee Vargas C. C. octubre 2007 Metodologías de Desarrollo de Software Las metodologías existentes se dividen en dos grandes grupos: Metodologías estructuradas Metodologías

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

1. Cuál es el objetivo del proceso de Análisis del Sistema de Información? del sistema. a. 10. b. 12. c. 9. d. 11. Análisis

1. Cuál es el objetivo del proceso de Análisis del Sistema de Información? del sistema. a. 10. b. 12. c. 9. d. 11. Análisis 1. Cuál es el objetivo del proceso de del Sistema de Información? a. La obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios

Más detalles

CAPITULO III DESARROLLO DEL APLICATIVO WEB (MONITOREO DE UN SERVIDOR LINUX).

CAPITULO III DESARROLLO DEL APLICATIVO WEB (MONITOREO DE UN SERVIDOR LINUX). CAPITULO III DESARROLLO DEL APLICATIVO WEB (MONITOREO DE UN SERVIDOR LINUX). Para el desarrollo de la aplicación Web se ha basado en el Ciclo de Vida Clásico y en el Modelo de Construcción de Prototipos,

Más detalles

Técnica para reusar artefactos de análisis y diseño en el modelamiento de software

Técnica para reusar artefactos de análisis y diseño en el modelamiento de software Revista de Investigación ULASALLE, Rev Inv ULASALLE, Número 1, 2012 (67-78) Universidad La Salle Arequipa, Perú Técnica para reusar artefactos de análisis y diseño en el modelamiento de software 1 Percy

Más detalles

METODOLOGIA ESTRUCTURADA DE DESARROLLO DE SISTEMAS

METODOLOGIA ESTRUCTURADA DE DESARROLLO DE SISTEMAS METODOLOGIA ESTRUCTURADA DE DESARROLLO DE CAMBIOS EN EL ANALISIS DE...2 EL MOVIMIENTO HACIA EL ANALISIS ESTRUCUTRADO...2 EL SURGIMIENTO DE LAS HERRAMIENTAS AUTOMATIZADAS DE ANALISIS...3 EL USO DE PROTOTIPOS...3

Más detalles

11 knúmero de publicación: 2 102 229. 51 kint. Cl. 6 : A61N 1/372

11 knúmero de publicación: 2 102 229. 51 kint. Cl. 6 : A61N 1/372 k 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 knúmero de publicación: 2 2 229 1 kint. Cl. 6 : A61N 1/372 k 12 TRADUCCION DE PATENTE EUROPEA T3 k k k k 86 Número de solicitud europea: 949182.6 86

Más detalles

Tema 3 Metodologías de Desarrollo de Software

Tema 3 Metodologías de Desarrollo de Software Ingeniería del Software Ingeniería del Software de Gestión Tema 3 Metodologías de Desarrollo de Software Félix Óscar García Rubio Crescencio Bravo Santos Índice 1. Definiciones 2. Objetivos 3. Conceptos

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

4 Diagramas de Flujo de Datos

4 Diagramas de Flujo de Datos 4 Diagramas de Flujo de Datos 4.1 Concepto Los diagramas de flujos de datos (DFD), es una técnica de modelización, que nos muestra un sistema como una red de procesos conectados entre ellos por flujos

Más detalles

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte AUDITORIA DE SISTEMAS Jorge Alberto Blanco Duarte QUE ES LA AUDITORIA DE SISTEMAS? La auditoria en informática es la revisión y la evaluación de los controles, sistemas, procedimientos de informática;

Más detalles

ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS

ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS 1 ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS INTRODUCCIÓN La realización de trabajos utilizando los medios informáticos de una empresa requiere una cierta organización y destreza relativa tanto a los equipos,

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Weitzenfeld: Capítulo 6 1

Weitzenfeld: Capítulo 6 1 Weitzenfeld: Capítulo 6 Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema para los eventos enviados o recibidos por los actores. En esta etapa

Más detalles

Manual de Proyectos. Documentación Intelisis. Derechos Reservados. Publicado en http://docs.intelisis.com

Manual de Proyectos. Documentación Intelisis. Derechos Reservados. Publicado en http://docs.intelisis.com Manual de Proyectos Documentación Intelisis. Derechos Reservados. Manual de Proyectos 1 Introducción 1.1 1.2 1.3 Objetivos y relación con el ERP 4 Diagrama de Integración 5 Diagrama de Proceso 6 2 Con

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

PROGRAMACIÓN BÁSICA DE LA COMPUTADORA. 1 Introducción. Tabla 1: Instrucciones MIPS

PROGRAMACIÓN BÁSICA DE LA COMPUTADORA. 1 Introducción. Tabla 1: Instrucciones MIPS PROGRAMACIÓN BÁSICA DE LA COMPUTADORA 1 Introducción Un sistema de computadora total incluye tanto circuitería (hardware) como programación (software). El hardware consta de los componentes físicos y todo

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

Más detalles

Introducción a las bases de datos

Introducción a las bases de datos Introducción a las bases de datos Juan Ignacio Rodríguez de León Abstract Aplicaciones de los sistemas de bases de datos. Sistemas de bases de datos frente a sistemas de archivos. Visión de los datos.

Más detalles

No se requiere que los discos sean del mismo tamaño ya que el objetivo es solamente adjuntar discos.

No se requiere que los discos sean del mismo tamaño ya que el objetivo es solamente adjuntar discos. RAIDS MODO LINEAL Es un tipo de raid que muestra lógicamente un disco pero se compone de 2 o más discos. Solamente llena el disco 0 y cuando este está lleno sigue con el disco 1 y así sucesivamente. Este

Más detalles

POLÍTICAS, NORMAS Y PROCEDIMIENTOS PARA LA ELABORACIÓN DE SISTEMAS

POLÍTICAS, NORMAS Y PROCEDIMIENTOS PARA LA ELABORACIÓN DE SISTEMAS APÉNDICE A ORGANIZACIÓN Y ADMINISTRACIÓN DE CENTROS DE CÓMPUTO!316" POLÍTICAS, NORMAS Y PROCEDIMIENTOS PARA LA ELABORACIÓN DE SISTEMAS 1. Objetivo Establecer las políticas, normas y procedimientos que

Más detalles

Diseño orientado al flujo de datos

Diseño orientado al flujo de datos Diseño orientado al flujo de datos Recordemos que el diseño es una actividad que consta de una serie de pasos, en los que partiendo de la especificación del sistema (de los propios requerimientos), obtenemos

Más detalles

3. EL PROCESO DEL DISEÑO ARQUITECTÓNICO

3. EL PROCESO DEL DISEÑO ARQUITECTÓNICO EMA - DISEÑO ESRUCURADO 1. INRODUCCIÓN Los métodos de diseño del software se obtienen del estudio de cada uno de los tres dominios del modelo de análisis. El dominio de los datos, el funcional y el de

Más detalles

Auditoria de Sistemas

Auditoria de Sistemas Sistemas de Información I Página1 1. Introducción La naturaleza especializada de la auditoria de los sistemas de información y las habilidades necesarias para llevar a cabo este tipo de auditorias, requieren

Más detalles

MANUAL 02 DE AUDITORIA

MANUAL 02 DE AUDITORIA MANUAL 02 DE AUDITORIA INDICE 1. Introducción 2. Evaluación de los Sistemas 3. Evaluación de los equipos 4. Controles administrativos en un ambiente de Procesamiento de Datos 5. Revisión de Centros de

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

PROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0

PROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0 Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. PROYECTO

Más detalles

1. Cuál es el objetivo del Diseño del Sistema de Información? del sistema. información. a. 5. b. 4. c. 3. d. 2. c. Diseño de. b.

1. Cuál es el objetivo del Diseño del Sistema de Información? del sistema. información. a. 5. b. 4. c. 3. d. 2. c. Diseño de. b. 1. Cuál es el objetivo del Diseño del Sistema de Información? a. La definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte junto con la especificación detallada de

Más detalles

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 14 Metodología Estructurada El Diccionario de datos Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar]

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

4. Programación Paralela

4. Programación Paralela 4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios

Más detalles

rg.o El l c i c c i l c o l o de d vi v d i a d a cm a l@ rza e de d u n u n si s s i t s e t ma m a de d in i f n or o ma m c a i c ó i n ó b

rg.o El l c i c c i l c o l o de d vi v d i a d a cm a l@ rza e de d u n u n si s s i t s e t ma m a de d in i f n or o ma m c a i c ó i n ó b El ciclo de vida de un sistema de información El ciclo de vida de un sistema de información El proceso de desarrollo de software Modelos de ciclo de vida El ciclo de vida de una base de datos El proceso

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

DISEÑO DE FUNCIONES (TRATAMIENTOS)

DISEÑO DE FUNCIONES (TRATAMIENTOS) DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se

Más detalles

Unidad 4: Vectores. 4.1 Introducción. 4.2 Vectores: enfoque geométrico

Unidad 4: Vectores. 4.1 Introducción. 4.2 Vectores: enfoque geométrico Unidad 4: Vectores 4.1 Introducción En este capítulo daremos el concepto de vector, el cual es una herramienta fundamental tanto para la física como para la matemática. La historia de los vectores se remonta

Más detalles

Unidad 1. Introducción a los conceptos de Bases de Datos

Unidad 1. Introducción a los conceptos de Bases de Datos Unidad 1 Introducción a los conceptos de Bases de Datos 1.1 Definición de Base de Datos Dato: Conjunto de caracteres con algún significado, pueden ser numéricos, alfabéticos, o alfanuméricos. Información:

Más detalles

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño.

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño. Definición de diseño Proceso para la definición detallada de un sistema con el fin de su realización física. Ingeniería del Software 1 Ingeniería del Software 2 Modelo de diseño vs. Paradigma de IS 3 actividades

Más detalles

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

Más detalles

Unidad 2 Modelos de optimización

Unidad 2 Modelos de optimización Unidad 2 Modelos de optimización Objetivos Al nalizar la unidad, el alumno: Construirá modelos matemáticos de optimización. Resolverá problemas prácticos con el método gráfico. Matemáticas para negocios

Más detalles

GESTIÓN DE PROYECTOS DE SOFTWARE

GESTIÓN DE PROYECTOS DE SOFTWARE GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de

Más detalles

Segunda Parte. Las Herramientas de Análisis y Diseño

Segunda Parte. Las Herramientas de Análisis y Diseño Segunda Parte Las Herramientas de Análisis y Diseño Capitulo IV 50 Diagramas de flujo de datos Capítulo IV Diagramas de Flujo de Datos 51 Capitulo IV Diagramas de flujo de datos Tabla de contenido 1.-

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

DE VIDA PARA EL DESARROLLO DE SISTEMAS

DE VIDA PARA EL DESARROLLO DE SISTEMAS MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS 1. METODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS. El desarrollo de Sistemas, un proceso

Más detalles

INTRODUCCIÓN AL DESARROLLO DEL SOFTWARE

INTRODUCCIÓN AL DESARROLLO DEL SOFTWARE INTRODUCCIÓN AL DESARROLLO DEL SOFTWARE 2.1.- CONCEPTO DE CICLO DE VIDA El problema más importante en cualquier departamento de sistemas de información de una empresa es definir un marco de eferencia común

Más detalles

Construcción de sistemas de soporte a la toma de decisiones

Construcción de sistemas de soporte a la toma de decisiones INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE CÓMPUTO Construcción de sistemas de soporte a la toma de decisiones M. En C. Eduardo Bustos Farías 1 Desarrolla en Sistemas de Apoyo de Decisión Como

Más detalles

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A. Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software SLC -ERS Relator: Sr. Eduardo Leyton G Ingeniería de Software (IS) Es una disciplina

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Metodologías de Desarrollo de Sistemas de Información

Metodologías de Desarrollo de Sistemas de Información Metodologías de Desarrollo de Sistemas de Información Metodología para el Desarrollo de SI Las metodologías son sistemas completos de técnicas que incluyen procedimientos paso a paso, productos resultante,

Más detalles

UNIDAD No. 6 Auditoria de Aplicaciones

UNIDAD No. 6 Auditoria de Aplicaciones Auditoria V UNIDAD No. 6 Auditoria de Aplicaciones Definiciones SOFTWARE/ PROGRAMA: Conjunto de instrucciones que dirigen al Hardware. Software/Programas del Sistema Llamados Programas Supervisorios, realizan

Más detalles

Ejercicios de Macroeconomía Avanzada

Ejercicios de Macroeconomía Avanzada Ejercicios de Macroeconomía Avanzada José L Torres Chacón Departamento de Teoría e Historia Económica Universidad de Málaga Septiembre 200 ii Indice I Sistemas dinámicos básicos 5 Introducción a la dinámica

Más detalles

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

Más detalles

Introducción a Bases de Datos

Introducción a Bases de Datos de a M. -Tastets Universidad de Concepción,Chile www.inf.udec.cl\ andrea andrea@udec.cl II Semestre - 2007 y del s: Sistemas de y del s: de y del s: Objetivos de la Unidad Dar a conocer las características,

Más detalles

NOTAS SOBRE DIAGRAMAS DE FLUJOS DE DATOS

NOTAS SOBRE DIAGRAMAS DE FLUJOS DE DATOS NOTAS SOBRE DIAGRAMAS DE FLUJOS DE DATOS Diagrama de Flujo de Datos: Diagrama en forma de red que representa el flujo de datos y las transformaciones que se aplican sobre ellos al moverse desde la entrada

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

Universidad de Colima Facultad de Ingeniería Mecánica y Eléctrica. Base de Datos I. Maestra: Martha E. Evangelista Salazar

Universidad de Colima Facultad de Ingeniería Mecánica y Eléctrica. Base de Datos I. Maestra: Martha E. Evangelista Salazar Universidad de Colima Facultad de Ingeniería Mecánica y Eléctrica Base de Datos I Maestra: Martha E. Evangelista Salazar Introducción a los conceptos de Bases de Datos a).- Definiciones básicas sobre bases

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Modelado de Procesos

Modelado de Procesos Modelado de Procesos Material desarrollado por -An. Miguel Brunnello y Cr. Marcelo Rocha Vargas (1ra.versión 2010) -Cr. Marcelo Rocha Vargas (Actualización 2011) Introducción En los orígenes de las TICs,

Más detalles

ANÁLISIS DE REQUISITOS

ANÁLISIS DE REQUISITOS ANÁLISIS DE REQUISITOS 3.1.- INTRODUCCIÓN AL ANALISIS DE REQUISITOS Como se dijo en capítulos anteriores, el término análisis aplicado a sistemas significa descomponer el sistema en sus componentes para

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

ACP07. Que es un erp.

ACP07. Que es un erp. UNIVERSIDAD AUTONOMA DE GUADALAJARA ACP07. Que es un erp. JOSE DE JESUS CISNEROS PEREZ REG. 1996632 TECNOLOGIAS DE LA INFORMACION Los sistemas de planificación de recursos empresariales (en inglés ERP,

Más detalles

Metodologías de diseño de hardware

Metodologías de diseño de hardware Capítulo 2 Metodologías de diseño de hardware Las metodologías de diseño de hardware denominadas Top-Down, basadas en la utilización de lenguajes de descripción de hardware, han posibilitado la reducción

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Unidad 6 Modelo de redes

Unidad 6 Modelo de redes Unidad 6 Modelo de redes Objetivos: Al nalizar la unidad, el alumno: Resolverá problemas utilizando el algoritmo de la ruta más corta. Resolverá problemas de flujo máimo. Resolverá problemas de flujo restringido

Más detalles

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica.

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica. RAID Como se dijo anteriormente, el ritmo de mejora de prestaciones en memoria secundaria ha sido considerablemente menor que en procesadores y en memoria principal. Esta desigualdad ha hecho, quizás,

Más detalles

Capitulo 2: (PMBOK guide) Ciclo de Vida del Proyecto y Organización

Capitulo 2: (PMBOK guide) Ciclo de Vida del Proyecto y Organización Capitulo 2: (PMBOK guide) Ciclo de Vida del Proyecto y Organización Los proyectos y la dirección de proyectos se llevan a cabo en un entorno más amplio que el atribuible al propio proyecto. El equipo de

Más detalles

Manual Conciliaciones_200214_V1.0

Manual Conciliaciones_200214_V1.0 Manual Conciliaciones_200214_V1.0 Documentación Intelisis.Derechos Reservados. Publicado en http://docs.intelisis.com Manual Conciliaciones_200214_V1.0 1 Introducción 1.1 1.2 1.3 Objetivos generales y

Más detalles

Listado de comprobación para informes de Evaluación de Tecnologías Sanitarias. Introducción

Listado de comprobación para informes de Evaluación de Tecnologías Sanitarias. Introducción Listado de comprobación para informes de Evaluación de Tecnologías Sanitarias Introducción Objetivo INAHTA ha diseñado este listado de comprobación con el propósito de facilitar la obtención de información

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles

13º Unidad Didáctica. RAID (Redundant Array of Independent Disks) Eduard Lara

13º Unidad Didáctica. RAID (Redundant Array of Independent Disks) Eduard Lara 13º Unidad Didáctica RAID (Redundant Array of Independent Disks) Eduard Lara 1 RAID: INTRODUCCIÓN Sistema de almacenamiento que usa múltiples discos duros entre los que distribuye o replica los datos.

Más detalles