Administración Herramientas Case
De Computacion
Introducción al Tema de las Herramientas CASE
Más que una disciplina o una parte del conocimiento, la ingeniería es un verbo, una palabra de acción, un modo de enfocar el problema [1]. El presente documento no pretende ser una fuente de consulta acerca de “Administración de Herramientas CASE”, pretender ser una guía que encamine al estudiante hacia la consecución de conocimientos relacionados con el tema referido. Para lograrlo el documento pretende coordinar las lecturas necesarias del texto base con los ejercicios correspondientes, de tal forma que haya un equilibrio entre lo que se lee y se practica. El texto base seleccionado se titula “Análisis y diseño de sistemas” de los autores E. Kendall, Kenneth y E. Kendall, Kenneth, Julie. El texto en su sexta edición presenta una relación coherente y asimilable de la teoría de análisis y diseño de sistemas y la práctica necesaria para que el futuro profesional de sistemas gane las habilidades necesarias para el desempeño correcto de su actividad profesional. En este sentido, el documento, sigue el caso de estudio, “Caso de la CPU”, propuesto por los autores en el texto base, no de forma pasiva, sino de forma activa proponiendo soluciones a los problemas planteados en el texto e invitando al estudiante a la reflexión y contextualización. El objetivo final del documento es transmitir la idea de que toda la teoría relacionada al análisis y diseño de sistemas es reflejable en las herramientas software especializadas para el efecto, esto no significa que las herramientas CASE sean la panacea del analista de sistemas..
Referencias
1 Scott Whitmire. Citado en Pressman 2001
[editar] Objetivo General
-
Dotar a los profesionales en formación de los conocimientos teórico-prácticos relacionados con la gestión de herramientas CASE, desde una perspectiva sistémica, estableciendo una adecuada vinculación entre los conceptos relacionados y las herramientas software especializadas para gestionar el ciclo de vida del desarrollo de sistemas.
[editar] Objetivos Especificos
1. Contextualizar los conceptos básicos del ciclo de vida del desarrollo de sistemas con el uso de herramientas software especializadas.
2. Comprender la función de las herramientas CASE y cómo ayudan al analista de sistemas.
3. Planear un proyecto identificando actividades y programándolas.
4. Reconocer el valor de los métodos interactivos para la recopilación de información.
5. Usar la elaboración de prototipos para la recopilación de los requerimientos de información.
6. Comprender el concepto de RAD para usarlo en la recopilación de requerimientos de información y el diseño de interfaces.
7. Comprender la importancia de usar diagramas de flujo de datos (DFDs, por sus siglas en inglés) lógicos y físicos para representar gráficamente el movimiento de los datos en una organización.
8. Entender los objetivos para el diseño eficaz de la salida.
9. Relacionar el contenido de la salida con los métodos de salida.
[editar] Bibliografia
Texto Base
[KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6
Bibliografía complementaria.
- [ROGER 2001] ROGER, JENNINGS. Microsoft Access 2000. Edición especial. Prentice Hall. 2001.
[editar] Desarrollo del Aprendizaje
[editar] Capitulo 1-A: CICLO DE VIDA DEL DESARROLLO DE SISTEMAS
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 1. Fundamentos del análisis de sistemas. |
| Páginas | 1 - 14 |
| Horas de estudio empleadas para el desarrollo del contenido | 4 horas |
[editar] Propósito
El propósito de este capítulo es de facilitar al estudiante la comprensión de los conceptos básicos relacionados al ciclo de desarrollo de sistemas.
[editar] Conceptos Clave
El ciclo de vida del desarrollo de sistemas comprende siete fases: identificación de problemas, oportunidades y objetivos; determinación de los requerimientos de información; análisis de las necesidades del sistema, diseño de sistema recomendado, desarrollo y documentación del software, pruebas y mantenimiento del sistema, implementación y evaluación del sistema.
Estas fases son secuenciales, lo que significa que para asegurar el éxito de un proyecto de software es imprescindible tener en mente y cumplir cada una de las fases2. Ej.: Incluso en los problemas más sencillo es necesario seguir estos pasos; piense en un juego de dados.
- Analicemos cada una de las fases mencionadas relacionadas a este problema.
- 2 El capítulo 1 del texto base hace una descripción más detallada del ciclo de vida del desarrollo de sistemas.
1. Identificación de problemas, oportunidades y objetivos: Aunque el problema resulte trivial, jugar a los dados en el computador, es necesario tener claro que es lo que se busca simular del juego de dados. Pregúntese: ¿Cuántos jugadores pueden participar?, ¿Cómo se asignan los turnos?, ¿Se permitirá jugar a los dados a través de una red?, ¿Cuáles son la reglas para proclamar al ganador?, ¿Se recibirán apuestas?
2. Determinación de los requerimientos de información: Las respuestas a las preguntas anteriormente planteadas, producirán los requerimientos de información. Medite estas respuestas. Un buen ejercicio, es que plantee tales preguntas a una tercera persona, si esta gusta de los juegos de azar, seguramente recolectará muy buena información.
3. Análisis de las necesidades del sistema: seguramente el entrevistado no le dirá exactamente si se requiere que varias personas estén conectadas al mismo tiempo a través de una red, o que todos los participantes en el juego, tengan un mando a distancia donde puedan presionar un botón y lanzar los dados. Usted debe estar en la capacidad de abstraer las necesidades del sistema. Esto se logra al hacer un análisis del contexto del problema, de los usuarios a quienes va dirigido, etc. Por ejemplo, si quien nos contrata para desarrollar el juego de dados, es un club internacional de juegos de azar, imagine que una necesidad del sistema es ser multilenguaje y ser accesible por red, entre otras.
4. Diseño de sistema recomendado: en base a las tres fases de análisis anterior, se construyen los modelos (diagramas escritos en alguna notación, para un paradigma de diseño específico) y se construye, si se requiere, un prototipo.
5. Desarrollo y documentación del software: con los modelos bien diseñados, es sencillo escribir código que implemente esos modelos, en algún lenguaje de programación que responda al paradigma seleccionado para el diseño. Las herramientas modernas para escribir código, tienen sistemas de documentación inline, es decir permiten documentar el código mientras de escribe.
6. Pruebas y evaluación del sistema: el código escrito y compilado produce un programa que refleja nuestro diseño, o por lo menos debería. Antes de mostrar nuestros avances a nuestros clientes. Es necesario probar el software, esto lo puede hacer el programador, pero se recomienda que lo haga otra persona, por eso de la paja en el ojo ajeno. Seguramente, las primeras versiones presentar inconformidades con los requerimientos, habrá que corregir estos defectos. Esta fase es recursiva, es decir probamos, corregimos y volvemos a probar.
7. Implementación y evaluación del sistema: Cuando el software tiene un alto porcentaje de conformidad con los requerimientos, esta listo para ser implementado y evaluado. Esto significa que pondremos el software en funcionamiento y evaluaremos la incidencia de este su contexto. Para nuestro ejemplo, del juego de dados, un buen indicador sería, la media de jugadores participantes en intervalos de tiempo.
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| Tipos de sistemas | En esta sección se describe la clasificación de los sistemas de información en función de su utilidad en el contexto organizacional. | Piense que instancias específicas de estos sistemas conoce usted. | |||
| Integración de las tecnologías de sistemas | Una visión general del estado del arte de los sistemas de información y lo que vendrá. | ||||
| Roles del analista de sistemas | Nosotros en la organización | Visualícese en cada uno de estos roles y plantéese la pregunta ¿Qué haría yo? |
[editar] Capitulo 1-B: HERRAMIENTA CASE
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 1. Fundamentos del análisis de sistemas. |
| Páginas | 14 - 25 |
| Horas de estudio empleadas para el desarrollo del contenido | 4 horas |
[editar] Propósito
El propósito de este capítulo es comprender la función de las herramientas CASE y cómo ayudan al analista de sistemas.
[editar] Conceptos Clave
Como usted lo habrá leído ya, existen dos tipos de herramientas CASE o por lo menos se trata de encasillar a estas en dos categorías: de bajo y alto nivel. Es importante que usted tenga claro esta diferenciación. Pero en la practica la gran mayoría de herramientas CASE modernas implementan funcionalidades de alto y bajo nivel.
- Ejemplos de herramientas CASE son:
- Microsoft ® Visio
- Magic Draw UML
- Visible Analyst
- Rational Rose
- Power Designer
- Oracle Designer
- Visual Architect
Los problemas propuestos en el texto para el caso de la CPU requieren Visual Analyst. Usted podría descargar una versión demo para un período de 7 días, que no es suficiente para nuestros fines académicos. Las otras herramientas listadas tienen un problema similar, aunque el período de prueba es más extenso, de 30 días. Con estos antecedentes y previendo los inconvenientes que una buena mayoría de ustedes tendría al no conseguir las herramientas, utilizaremos Microsoft ® Visio como principal herramienta para construir los diagramas requeridos para las soluciones a los problemas que se plantea.
Aclarando que Microsoft ® Visio no es una herramienta CASE en el todo el sentido de la palabra, ya que esta limitada a la construcción de diagramas, pero considero que ese es el principal objetivo de esta asignatura: construir diagramas e interpretarlos. El entrenamiento en Microsoft ® Visio no es una pérdida de tiempo, por que las herramientas CASE propiamente dichas, utilizan los mismo símbolos, para construir los diagramas; esto reducirá la curva de aprendizaje de herramientas más avanzadas. Pero independientemente de la herramienta CASE, es importante que el estudiante pueda contextualizar los símbolos y su significado en el ciclo de vida de desarrollo de sistemas.
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| Uso de herramientas CASE | Definición de herramientas CASE y algunas de sus características | Consulte en la Internet acerca de herramientas CASE. Obtenga un listado de los productos comerciales y de distribución libre; revise las características y realice un cuadro comparativo.
CASO DE LA CPU – Episodio 1 A partir de aquí empezamos a desarrollar el CASO DE LA CPU, como se menciona en la introducción de este documento iremos desarrollando este caso de estudio y paralelamente relacionaremos los conceptos del análisis y diseño de sistemas. Como la materia que nos ocupa son las herramientas CASE, referiremos los conceptos, pero pondremos mayor énfasis en las soluciones al caso de estudio. |
[editar] Capitulo 2 :EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 2. El estilo organizacional y su impacto en los sistemas de información. |
| Páginas | 27-47 |
| Horas de estudio empleadas para el desarrollo del contenido | 8 horas |
[editar] Propósito
Entender que las organizaciones son sistemas y que el analista debe analizarlas desde una perspectiva sistémica.
Emplear herramientas CASE para describir las entidades y relaciones que forman la organización.
[editar] Conceptos Clave
Recuerde, como profesionales de las tecnologías de la información, no adaptamos la organización a nuestros sistemas; son nuestros sistemas los que se adaptan a la organización. Es importante mirar a los sistemas bajo un enfoque sistémico, que significa que todo sistema es parte de otro sistema; donde la frontera es la globalidad de relaciones que puedan existir en el contexto endógeno y exógeno de la organización.
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| El estilo organizacional y su impacto en los sistemas de información. | Recuerde, como profesionales de las tecnologías de la información, no adaptamos la organización a nuestros sistemas; son nuestros sistemas los que se adaptan a la organización. Es importante mirar a los sistemas bajo un enfoque sistémico, que significa que todo sistema es parte de otro sistema; donde la frontera es la globalidad de relaciones que puedan existir en el contexto endógeno y exógeno de la organización. | CASO DE LA CPU – EPISODIO 2
Para emprender en la solución de la interrogantes planteadas para este episodio del caso de la CPU es necesario que lea el capitulo 2 del texto, base donde se aborda el impacto de la estructura organizacional en los sistemas informáticos. En el texto se menciona que puede descargar de la Internet los archivos ya confeccionados para Visual Analyst, puede descargarlos, pero necesitara Visual Analyst para poder verlos. Recomiendo construir los diagramas en Microsoft ® Visio y luego contrastarlos con los disponibles en la Web. Para contestar las preguntas E-4 y E-5, debe reflexionar un poco y volver a leer el capítulo II. Le anticipo que debe identificar claramente el contexto del sistema en la organización y tener presente que una entidad puede aportar entradas y recibir salidas |
[editar] Capitulo 3 :DETERMINACIÓN DE LA VIABILIDAD Y ADMINISTRACIÓN DE LAS ACTIVIDADES DE ANÁLISIS, DISEÑO Y MÉTODOS DE RECOPILACIÓN DE INFORMACIÓN
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 3. Determinación de la viabilidad y administración de las actividades de análisis, diseño y métodos de recopilación de información. |
| Páginas | 49 - 85 |
| Horas de estudio empleadas para el desarrollo del contenido | 8 horas |
[editar] Propósito
Planear un proyecto identificando actividades y programándolas.
Reconocer el valor de los métodos interactivos para la recopilación de información
[editar] Conceptos Clave
Determinar la viabilidad y administrar las actividades de análisis y diseño no es una tarea fácil. Recuerde que la fase de análisis nos encargamos de conocer en detalle el contexto del problema y para esto nos valemos de técnicas de recolección de información como entrevistas, cuestionarios, encuestas, etc. Claro antes de empezar a recabar información debemos determinar la viabilidad del proyecto.
El texto base propone una cuadrilla de impacto; donde se contrasta las funcionalidades del sistema o componentes de este, con los objetivos de la organización. En resumen un proyecto sólo es viable si se logra el involucramiento de toda la organización, en todos los niveles jerárquicos de la organización. Si a nadie le sirve, a nadie le interesa; y la recuerde que sin participación no hay compromiso Una vez demostrada la viabilidad, debemos organizar el equipo de trabajo, delimitar tareas y asignarlas y establecer tiempos prudenciales para su ejecución. Las actividades en un proyecto de sistemas no son siempre secuenciales, a veces será posible realizar actividades de forma paralela. Para identificar que actividades son secuenciales y cuales son paralelas, pregúntese ¿puedo empezar la actividad B, sino he terminado la actividad A? La respuesta guiara el camino. Los diagramas de Gantt y los diagramas Pert permiten mostrar al equipo de trabajo la planeación de las actividades, su asignación y su distribución en el tiempo. En el capítulo 3, se explica en detalle ambos tipos de diagramas.
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| Determinación de la viabilidad y administración de las actividades de análisis y diseño y métodos de recopilación de información. | El texto expone una cuadrilla de impacto, que representa una herramienta útil para visualizar el ¿por qué si? ó ¿por qué no? De un sistema. | CASO DE LA CPU – EPISODIO 3, 4 y 5
En el texto se sugiere Visible Analyst para construir diagramas PERT [1], una opción interesante es dibujarlos en Microsoft ® Word o Microsoft ® Visio o a mano. Lo interesante de los diagramas PERT es que permiten ver la ruta crítica y el tiempo de holgura, que es la información necesaria para controlar con eficiencia un proyecto. En la página se describe el procedimiento para dibujar un diagrama PERT y como identificar la ruta critica. En el trabajo a distancia se plantea solucionar el problema 7 de la página. Debe solucionar los problemas [2] E-3, E-4 y E-5 del episodio III del Caso de la CPU. Luego de completar estas tareas, imprima los diagramas resultantes y téngalos a mano, serán de gran utilidad para solucionar posteriores episodios del caso de la CPU. Para el problema E-4 una de las rutas es: 10-20-30-40-70-80, existen 5 más identifíquelas y calcule el tiempo de duración; para la ruta de ejemplo el tiempo de duración es 10 días. De la comparación del tiempo de duración de las seis rutas, de identificara la ruta crítica, esta indica al analista las actividades susceptibles de mayor cuidado. En el episodio IV y V se refiere a la elaboración de encuestas y cuestionarios. Vamos a plantear el desarrollo de estos ejercicios como opcional. Pero es necesario que se lea la conversación entre Anna y Chip, esto permitirá mantener la continuidad en el caso. También es necesario que lea los capítulos correspondientes. Tome en cuenta que estamos analizando un caso de estudio, esto es mejor que resolver problemas aislados en contexto diferentes |
[editar] Capitulo 6 ELABORACIÓN DE PROTOTIPOS Y RAD
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 6. Elaboración de prototipos y RAD. |
| Páginas | 151 - 184 |
| Horas de estudio empleadas para el desarrollo del contenido | 8 horas |
[editar] Propósito
Usar la elaboración de prototipos para la recopilación de los requerimientos de información.
Comprender el concepto de RAD para usarlo en la recopilación de requerimientos de información y el diseño de interfaces.
[editar] Conceptos Clave
La elaboración de prototipos es una técnica de recopilación de información para complementar el ciclo de vida del desarrollo tradicional de sistemas. Cuando los analistas de sistemas usan la elaboración de prototipos, están buscando las reacciones del usuario, sugerencias, innovaciones y la revisión planeada para mejorar el prototipo, y por consiguiente modificar los planes del sistema con un gasto e interrupción mínimos.
El término elaboración de prototipos acepta varios significados diferentes, de los cuales cuatro se usan comúnmente. La primera definición de la elaboración de prototipos es la de construir un prototipo como un sistema corregido. Una segunda definición es la de un prototipo no funcional que se usa para probar ciertos aspectos de diseño. Como tercera definición esta la de crear el primer prototipo de una serie que es totalmente funcional. Esta clase de prototipo es útil cuando se planean muchas instalaciones del mismo sistema de información (bajo condiciones similares). La cuarta clase de la elaboración de prototipos es un prototipo con características seleccionadas que tiene algunas, pero no todas, las características principales del sistema [KENDALL 2005].
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| Elaboración de prototipos y RAD | En este capítulo se a borda la elaboración de prototipos de sistemas de información, que representa una técnica valiosa para recopilar rápidamente datos específicos sobre los requerimientos de información de los usuarios. | CASO DE LA CPU – EPISODIO 6
¿Cree usted que con toda la información recabada en los episodios III, IV y V será posible empezar a construir la solución para la CPU? Si su respuesta es sí, le auguro la escritura de miles y miles de líneas de código y muchos dolores de cabeza. Lea el capitulo 4 para hacerse de los concepto relacionados a la elaboración de prototipos, concentre su atención en las ventajas y desventajas y en el papel del usuario en la elaboración de prototipos. Con estos conceptos en mente analicemos el episodio VI del caso de la CPU. En este episodio se pide elaborar prototipos del sistema, específicamente de posibles reportes, pantallas de entrada y pantallas de salida. Para esto se emplea Microsoft ® Access, por varias razones, entre otras la facilidad de uso ya que esta basado en el paradigma visual. Pruebe resolver los problemas planteados [3]. No será tiempo perdido. Lo que ha de tener claro en este punto, es que el prototipo no es el sistema. Un prototipo es un medio para incrementar la participación del usuario en el desarrollo del proyecto. También representa, para el analista, una aproximación a lo que quiere el usuario. Para ver el prototipo para el caso de estudio de la CPU, se requiere Microsoft ® Access, el archivo se llama KK6CPUStnt.mdb y contiene un conjunto de entidades, formularios y reportes que en su conjunto representan el prototipo del sistema para el caso de la CPU. Si necesita más información acerca de Microsoft Access vea [ROGER 2001]. Usted podría hacer la versión en español del prototipo del sistema para el caso de la CPU. Debe solucionar los problemas E-3, E-4 y E-5 del episodio III del Caso de la CPU. Luego de completar estas tareas, imprima los diagramas resultantes y téngalos a mano, serán de gran utilidad para solucionar posteriores episodios del caso de la CPU. Para el problema E-4 una de las rutas es: 10-20-30-40-70-80, existen 5 más identifíquelas y calcule el tiempo de duración; para la ruta de ejemplo el tiempo de duración es 10 días. De la comparación del tiempo de duración de las seis rutas, de identificara la ruta crítica, esta indica al analista las actividades susceptibles de mayor cuidado. En el episodio IV y V se refiere a la elaboración de encuestas y cuestionarios. Vamos a plantear el desarrollo de estos ejercicios como opcional. Pero es necesario que se lea la conversación entre Anna y Chip, esto permitirá mantener la continuidad en el caso. También es necesario que lea los capítulos correspondientes. Tome en cuenta que estamos analizando un caso de estudio, esto es mejor que resolver problemas aislados en contexto diferentes |
[editar] Capitulo 7 : USO DE DIAGRAMAS DE FLUJO DE DATOS
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 7. Uso de diagramas de flujo de datos. |
| Páginas | 191 - 230 |
| Horas de estudio empleadas para el desarrollo del contenido | 12 horas |
[editar] Propósito
Comprender la importancia de usar diagramas de flujo de datos (DFDs, por sus siglas en inglés) lógicos y físicos para representar gráficamente el movimiento de los datos en una organización.
[editar] Conceptos Clave
Los diagramas de flujo son artefactos centrales en el ciclo de vida del análisis y diseño de sistemas. Para entender mejor el movimiento lógico de los datos a través de una empresa, el analista se sistemas dibuja diagramas de flujo de datos (DFDs). Estos diagramas son herramientas estructuradas de análisis y diseño que le permiten al analista comprender visualmente el sistema y en los subsistemas como un conjunto de flujos de datos interrelacionados El analista de sistemas extrae procesos de datos, orígenes, almacenes y flujos de los primeros relatos de la organización y utiliza un enfoque jerárquico hacia abajo para dibujar primero un diagrama de flujo de datos de contexto del sistema a un nivel muy general. A continuación dibuja un diagrama de flujo de datos lógico de nivel 0. Se muestran los procesos y se agregan almacenes de datos. En seguida, el analista crea un diagrama hijo para cada uno de los procesos del diagrama 0. Las entradas y salidas permanecen constantes, pero los almacenes y orígenes de datos cambian La ampliación del diagrama de flujo de datos original permite al analista de sistemas enfocarse en descripciones cada vez más detalladas del movimiento de los datos en el sistema. El analista desarrolla entonces un diagrama de flujo de datos físicos a partir del diagrama de flujo de datos lógico, y lo particiona para facilitar la programación. Cada proceso se analiza para determinar si se trata de un procedimiento manual o uno automatizado. Seis consideraciones para particionar diagramas de flujo de datos incluyen si los procesos son realizados por diferentes grupos de usuarios, si se ejecutan al mismo tiempo, si desempeñan tareas similares, si se pueden combinar para realizar un procesamiento eficiente, si se pueden combinar en un programa para mantener la consistencia de los datos, o si se pueden particionar en diferentes programas por razones de seguridad [KENDALL 2005].
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| Diagramas de Flujo de Datos | Los diagramas de flujos de datos describen, de forma más amplia, el panorama general de las entradas, procesos y salidas del sistema. | El texto desarrolla varios ejemplos de diagramas de flujo de datos en el capítulo 7 página 208. Grafique los diagramas empleando Microsoft ® Visio.
CASO DE LA CPU EPISODIO 7 Las soluciones a los problemas planteados en este caso de estudio, requieren que usted dibuje en Microsoft ® Visio los diagramas de contexto de la Figura E7.1, el diagrama 0 distribuido en la Figura E7.2 y E7.3 y el diagrama 1 de la Figura E7.4. No se desanime por las referencias que se muestran hacia Visible Analyst. Lo importante en este ejercicio no es el uso de la herramienta CASE, sino la construcción del diagrama. Los problemas E7, E8 y E9 hacen referencia a características especificas de Visible Analyst que no se encuentran en Microsoft ® Visio, ignore estos ítems. Las soluciones para E7, E8 y E9, permiten crear entradas para la construcción del diccionario de datos, este comportamiento es propio de las herramientas CASE, sino no tendrían sentido y por eso son tan costosas. Con el diccionario de datos, las herramientas CASE son capaces de generar código, esto las haces tan interesantes. Pero note la importancia de un buen diagrama de flujo de datos como la base para el desarrollo de toda la capacidad de la herramienta CASE. |
[editar] Capitulo 14 : DISEÑO DE UNA SALIDAD EFICAZ
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 14. Diseño de una salida eficaz. |
| Páginas | 359 - 396 |
| Horas de estudio empleadas para el desarrollo del contenido | 12 horas |
[editar] Propósito
Entender la importancia de diseñar y producir una buena salida en los sistema de información.
[editar] Conceptos Clave
Los usuarios dependen de la salida de un sistema para realizar sus tareas y con frecuencia juzgan el valor de un sistema sólo por su salida. Para crear la salida más útil posible, el analista de sistemas trabaja de cerca con el usuario en un proceso interactivo hasta que el resultado se considera satisfactorio [KENDALL 2005]. Ponga mucha atención en la lectura del capítulo 11, el comprender estos conceptos y el como aplicarlos en el ciclo de vida del desarrollo de sistemas le darán un valor agregado a usted como profesional de tecnologías de la información. Aunque la mayoría del trabajo propuesto en el caso de estudio se orienta al diseño de reportes. La salida no son solo los reportes para impresión, incluyen las vistas que se muestran al usuario, por ejemplo: un grafico, un documento generado en formato de solo lectura como PDF o HMTL o POSTSCRIP, etc. Cualquiera que sea el caso, tenga siempre en mente los conceptos descritos a los largo del capítulo. Pero sobre todo aplique el sentido común y trate de guiarse, si le es posible, en otras salidas de otros sistemas ya en funcionamiento, aunque estos no sean en el mismo contexto, siempre habrá cosas que podemos rescatar y adaptar al contexto propio de nuestro sistema.
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| Diseño de una salida eficaz | Los usuarios dependen de la salida de un sistema para realizar sus tareas y con frecuencia juzgan el valor de un sistema sólo por su salida. Para crear la salida más útil posible, el analista de sistemas trabaja de cerca con el usuario en un proceso interactivo hasta que el resultado se considera satisfactorio [KENDALL 2005] | CASO DE LA CPU EPISODIO 11
En este episodio del caso de la CPU, hay mucho trabajo por hacer, aparentemente. Para poder solucionar estos problemas, asegúrese de haber descargado el archivo KK6CPUStnt.mdb del sitio Web del libro [4]. Todo el trabajo se desarrolla con Microsoft Access, así que necesitara leer algo acerca de cómo elaborar reportes, vea [ROGER 2001] |
[editar] Capitulo 15 : DISEÑO DE UNA ENTRADA EFICAZ
[editar] Datos Generales:
| Texto Base | [KENDALL 2005] E. KENDALL, KENNETH y E. KENDALL, JULIE. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación. México. 2005. ISBN: 9070-26-0577-6 |
| Capítulo | 14. Diseño de una entrada eficaz. |
| Páginas | 543 - 575 |
| Horas de estudio empleadas para el desarrollo del contenido | 12 horas |
[editar] Propósito
Entender la importancia de diseñar y producir formularios de entrada funcionales para los sistema de información.
[editar] Conceptos Clave
La calidad de la entrada del sistema determina la calidad de la salida del mismo. La entrada bien diseñada debe lograr los objetivos de efectividad, precisión, facilidad de uso, simplicidad, consistencia y atractivo. El conocimiento de muchos elementos de diseño diferentes permitirá al analista de sistemas alcanzar estos objetivos [KENDALL 2005]. Conforme a la tendencia cada vez más marcada de construcción de aplicaciones Web, el texto plantea lineamentos para el diseño de formularios para Web.
- 1. Las pantallas se deben mantener simples.
- 2. Las pantallas deben ser consistentes en la presentación.
- 3. El diseño debe facilitar el movimiento entre las páginas.
- 4. Las pantallas deben ser atractivas.
Comprenda y asimile estos lineamentos, junto con los lineamentos planteados para el diseño de salidas. Muchas veces el usuario espera similitudes en ambas. Como ejemplo, fíjese en el Microsoft ® Word, nosotros como usuarios, esperamos que se imprima lo que vemos en la pantalla. Y si la tarea es transcribir un documento, esperamos que exista una forma sencilla de ingresar el texto que conforma el documento. Esto es conocido como el paradigma “Lo que veo es lo que obtengo”, seria interesante poder aplicar este paradigma a los sistemas empresariales. Justamente de eso trata el foro en el Entorno Virtual de Aprendizaje. Luego de leer los capítulos 11 y 12 usted podrá argumentar. No olvide revisar la documentación extra en la sección material.
[editar] Esquema de Estudio
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| Diseño de una entrada eficaz | La calidad de la entrada del sistema determina la calidad de la salida del mismo. La entrada bien diseñada debe lograr los objetivos de efectividad, precisión, facilidad de uso, simplicidad, consistencia y atractivo. El conocimiento de muchos elementos de diseño diferentes permitirá al analista de sistemas alcanzar estos objetivos [KENDALL 2005] | CASO DE LA CPU EPISODIO 12
Este el episodio final que abordaremos del caso de CPU, los ejercicios planteado aquí tienen el objetivo de ejercitarlo en la construcción de formularios de entrada. Necesitara el archivo KK6CPUStnt.mdb y Microsoft ® Access para desarrollar las soluciones. No se desanime por el número de ejercicios planteados, no representan una perdida de tiempo. Al finalizar usted estará en capacidad de crear formularios de entrada, amigables con el usuario, robustos y fieles a los linimentos de diseño propuestos por el autor en el texto base. |
