Esperamos humildemente que este documento sirva como referencia.

1. Teoría de Sistemas
Profesor: Ricardo Díaz Ibáñez
Integrantes:
Eduardo Cañas
Marcelo Espinoza
Roberto González
Víctor Santana
Mario Silva
Carol Uribe
Cristian Varas
Santiago, 24 de mayo del 2012
Universidad UCINF
Facultad de Ingeniería y Tecnología

2. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 2 de 14
1. INTRODUCCIÓN ...............................................................................................................3
2. LAS HERRAMIENTAS DE MODELADO..............................................................................3
3. PROCESO DE ANÁLISIS ....................................................................................................3
4. SEGUIMIENTO..................................................................................................................3
4.1 PASANDO AL DISEÑO...........................................................................................................3
4.2 PROGRAMACIÓN Y PRUEBA..................................................................................................8
4.3 MANTENIMIENTO DE LA ESPECIFICACIÓN...............................................................................10
4.4 EL FUTURO DEL ANÁLISIS ESTRUCTURADO..............................................................................11
5. PREGUNTAS...................................................................................................................13

3. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 3 de 14
1. Introducción
2. Las herramientas de Modelado
3. Proceso de Análisis
4. Seguimiento
4.1 Pasando al diseño
1. Los tres niveles del diseño de sistemas.
2. Los tres criterios principales para evaluar el diseño de un sistema.
3. Como dibujar un diagrama de estructura.
4. Como usar el acoplamiento y la cohesión para evaluar un diseño.
1.

4. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 4 de 14
2.
Análisis V/S Tiempo:
A mayor análisis menos tiempo de construcción, a menor análisis mayor tiempo de
construcción, esta regla se aplica en todas las etapas del proceso.
22.1- Las etapas del Diseño
Modelo de implantación de sistema
 Modelo procesador
 Modelo de tareas
Nivel de asignación de procesos.
Asignación de modelo esencial, tareas principales y su asignación a la distintas CPU, y
comunicarse deben comunicarse entre si.
Definición de arquitectura tanto del software y hardware.

5. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 5 de 14
3.
Ejemplo hardware
Topología:
Servidor único
Servidor autónomo
Horizontal de clúster
Vertical de clúster
Combinación de clúster vertical y horizontal
4.
Ejemplo software
Sistema Multicapa
Component
Controller

6. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 6 de 14
DataAccess
Domain
Library
Service
5.
Modelo de implantación del programa
Nivel de asignación de tareas individuales.
Definición de almacenamiento de datos.
6.
22.2-Metas y objetos del Diseño
El diseñador en esta etapa se ocupa de la calidad total del sistema, la capacidad de
mantención depende de la calidad del diseño.
Reglas comunes:
Cohesión: una sola función bien definida.
Acoplamiento: mientras mayor acoplamiento, mayor dificultar para la mantención.

7. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 7 de 14
Tamaño del Modulo: lo suficientemente pequeño para caer en una página.
Alcance del control: un modulo no debe llamar a mas de media docena de sub módulos.
Introducir nivel intermedio de módulos administrativos.
Alcance del efecto/alcance: no necesariamente un modulo que surja de una decisión debe
estar subordinado al modulo que toma esa decisión.
7.
Resumen
Hacer coincidir el modelo esencial (requerimientos iniciales) con una configuración de
procesadores.
Organizar los procesos dentro de cada tarea en una jerarquía de módulos.
Proceso adicionales y reserva de datos considerar procesos par incorporar nuevas
tecnologías.
Procesos  Actividades.
Reglas de Negocio.
Validación de reglas de negocio.
Ejemplo de diagrama

8. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 8 de 14
8.
4.2 Programación y prueba
1. El papel del analista de sistemas en la programación y la prueba.
2. Porque es ventajoso el seguimiento rápido durante la programación y prueba.
3. Lo que el analista debe buscar al examinar un programa.
4. Los principales tipos de pruebas que se deben realizar.

9. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 9 de 14
9.
23.1- El papel del analista en la programación y la prueba.
En el momento de comenzar con la codificación o implantación generalmente el analista pasa
a otro proyecto, que razones tendría en analista para seguir con el proyecto.
Razones:
Usted es el líder del proyecto y esta a cargo de los programadores.
Usted es un analista junio y su titulo es de analista programador.
Usted es parte de un grupo que escribe casos de prueba.
Puede verse involucrado en el desarrollo de manuales.
Tal vez los programadores no comprenden su especificación.
Puede ser que los usuarios hayan empezado a cambiar de opinión.
23.2-El impacto de analista, la programación y la prueba sobre la estructura
organizacional.
El análisis involucra una progresión continua de los aspectos del modelo de alto nivel,
diagramas de flujo, aspectos del modelo de bajo nivel, desarrollo específico del proceso,
diccionario de datos completo y detallado. El proceso de diseño involucra el desarrollo,
modelos de diseño que van desde diagramas estructurados de alto nivel, hasta formas de
nivel tan bajo como el pseudocódigo y los diagramas de flujo. La programación debe seguir
este mismo patrón, se escribe la programación para los módulos ejecutivos de alto nivel y
posteriormente se desarrollan los módulos de bajo nivel, que llevan a cabo cálculos
detallados o validan datos de entrada.
Relación entre los niveles del sistema y niveles de organización

10. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 10 de 14
4.3 Mantenimiento de la especificación
1. Porque es importante tener al día las especificaciones.
2. Que tipos de cambios se necesitan hacer a una especificación.
Muchas veces los analistas salen del proyecto cuando se terminan las especificaciones o fin
cumplen funciones de administrador de proyecto, sirviendo como intermediario entre el
equipo de desarrollo y el usuario o participar en el desarrollo de manuales. Aunque el analista
no pueda participar a lo largo de la vida del proyecto debe dejar un legado de documentación.
24.1- Porque es importante.
Cuantas cosas de 100 años tienen documentos actualizados que describen la instalación
eléctrica, tuberías u otros detalles arquitectónicos.
A menudo es más fácil realizar cambios sin documentar correctamente o sin documentar,
generalmente se realiza cuando el cambio es apresurado, normalmente debe arreglarse el
problema mismo antes que la documentación; la documentación es lo ultimo que se hace y
generalmente no se hace.
Existen muchos ejemplos de problemas de mantenimiento, los sistemas antiguos no están
documentados y aun los requerimientos son un misterio.
La única solución para evitar esta crisis es una excautiva documentación actualizada por el
sistema mismo.
24.2- Prerrequisitos necesarios
No se puede mantener actualizado un sistema si su documentación no esta actualizada.
Se debe mantener un sistema de implantación de cambios ya que el solo registro de los
cambios no es suficiente.
24.3- Como hacerlo
Los cambios a implementar deben iniciar con un examen de impacto.
En los siguientes casos:
 El usuario decide implementar una nueva funcionalidad.
 El usuario no esta contento con alguna funcionalidad.
 El usuario quiere un nuevo reporte.
 El usuario quiere modificar un reporte.
 Los programadores deciden recodificar un modulo para hacerlo mas eficiente.
 El departamento de operaciones decide hacer una nueva funcionalidad.
 El usuario se queja de salidas erróneas.
 Se ha decidido un nuevo lenguaje de programación.
 Se requiere que el sistema mande salidas a una nueva dependencia.
Para estos cambios debe documentarse y generar una solicitud de cambio siendo verificado
con el usuario.
24.4- Resumen

11. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 11 de 14
4.4 El futuro del análisis estructurado
Definición de los posibles futuros.
Tres periodos amplios:
1. El antiguo analistas describía los requerimientos tipo novela.
2. A mediados de los 70, se utilizan gráficos y diagramas.
3. Analista estructurado moderno, los años 80.
25.1- Que hace el cambio.
Cambios de tecnología
Partición de acontecimientos.
La des enfatización del modelo físico actual.
Herramientas de modelado en tiempo real.
Integración más cercana de modelado de procesos y de datos.
25.2- Acometimientos futuros en el análisis estructurado.
Los acontecimientos recientes siguen un numero de tendencias que probablemente continúe
hasta bien adentrada la siguiente década.
25.2.1- Mayor difusión del análisis de sistemas
Las computadoras son parte integrante de esta sociedad, es indudable el impacto que tiene a
futuro, en todas las actividades humanas, como son administración, negocios, la educación y
todas las actividades profesionales.
25.2.2 proliferación de herramientas automatizadas
Proliferación de herramientas de análisis, como son herramientas case.
En el 1987, 2%, en el 1990 un 10%, existe la necesidad de creación de nuevas herramientas.
10.

12. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 12 de 14
25.2.3- El Impacto de los desastre de mantenimiento
El análisis estructurado no goza de la importancia necesaria para evitar problemas futuros.
Los sistemas grandes y no documentados son candidatos para desastre de mantenimiento.
La causa mas probable será la imposibilidad de realizar mejoras, las variables que
comprometen los cambios son extensas he incluyen la situación competitiva.
Los códigos que han sido modificados tantas veces es casi imposible saber como operan,
sobre todo si el sistema es de mediados de los 60.
Al enfrentarse con problemas como estos se comenzara a realizar análisis de nuevos procesos
y la implantación de estándares, esto se implantara solo después que ocurra un problema
importante de mantenimiento.
11.
25.2.4- El Matrimonio del análisis estructurado y la inteligencia artificial
Existe una relación directa entre la inteligencia artificial y sistemas expertos.
Los cuales generalmente incluyen tres aspectos.
1. La interface humano maquina.
2. La presentación de conocimiento.
3. Maquina que evalúa e interroga a la base de conocimiento.

13. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 13 de 14
En este sentido la inteligencia puede ayudar a automatizar el análisis estructurado, como un
asistente de análisis.
25.2.5- El Impacto de las nuevas generaciones de hardware de las computadoras
El impacto de las nuevas tecnologías esta directamente relacionado a las metodologías,
arquitectura, y formas de codificar las distintas soluciones.
Nos encontramos en un momento en que la tecnología cambia con la velocidad de menos de
un año, obligando a los profesionales actualizarse permanentemente.
25.3- Conclusión
Aprender a utilizar herramientas de diseño.
Aprender varios paradigmas de programación, (Orientado al evento, Orientado al objeto,
Orientado a los aspectos, Programación estructurada.
Las personas primero: El programa que están construyendo ES USADO POR PERSONAS
póngase en el lugar del usuario.
Documentar procesos, actividades, reglas de negocio, utilizar controles de cambio y
versiones.
Realizar pruebas unitarias, de pares y pruebas de terceros.
Apetito por el conocimiento: Nuestra profesión es dinámica, adáptese, aprenda y aplique.
Reconozca patrones en los problemas: En su vida como desarrollador se va a topar con el
mismo problema pero distinto color, ensamble soluciones basadas en experiencias anteriores.
Reutilización de código y librerías.
Actualmente hay un cambio cultural en proceso, somos parte de un hito histórico.
5. Preguntas
1. ¿Cuáles son los cinco principales cambios que se han dado en el campo del análisis
durante los últimos 10 años?
2. ¿Qué significa, en el contexto de este capitulo, los términos lógico y físico?
3. ¿Qué es partición por acontecimientos? ¿a qué ha remplazado el campo del análisis?
4. ¿Por qué se ha des enfatizado el modelo físico actual en el análisis de sistemas?
5. ¿Qué herramientas adicionales se han añadido al campo del análisis de sistemas para
ayudar a modelar sistemas de tiempo real?
6. ¿Que es un diagrama de estructura de datos? ¿A qué ha remplazado en el campo del
análisis?
7. ¿Cómo están comenzando a afectar las computadoras a los trabajos y actividades de
los administradores experimentados en las organizaciones?
8. ¿Por qué tendría impacto sobre los proyectos de desarrollo de sistemas en los años
venideros la enseñanza del análisis estructurado?

14. Facultad de Ingeniería y Tecnología
Carrera de Ingeniería en Ejecución Informática
Página 14 de 14
9. ¿Por qué es probable que el análisis de sistemas sea un factor de competencia
internacional entre EUA, Europa y muchos países del tercer mundo?
10. Proyecto de investigación: Que porcentaje de los programadores y analistas de
sistemas en su organización tienen estaciones de trabajo con paquetes de herramientas
de análisis?
11. ¿Por qué son importantes las herramientas automatizadas para el análisis de sistemas?
12. ¿Por qué afectarán al análisis estructurado en el futuro los desastres de
mantenimiento?
13. Que relación es probable que exista entre el análisis estructurado y la automatización
en el futuro?