Guia Didactica Analisis y Diseño de Sistemas 2020

Análisis y diseño de sistemas Informáticos |
Guía Didáctica
IN TR OD U C C IÓ N
BI BL I OG RA F ÍA
OR I ENT A CI O NES
ANÁLISIS Y DISEÑO DE
P RO C ES O
SISTEMAS INFORMÁTICOS
GUÍA DIDÁCTICA
UN I DAD ES
S OL U CI ON AR I O
AN EXO S
Instituto Superior Tecnológico Sucúa | 1

Tecnología Superior en Desarrollo de Software
Guía Didáctica
TECNOLOGÍA SUPERIOR EN DESARROLLO DE SOFTWARE
www.tecnologicosucua.milaulas.com
ANÁLISIS Y DISEÑO
DE SISTEMAS
BI BL I OG RA F ÍA
INFORMÁTICOS
1er. Ciclo
OR I ENT A CI O NES
P RO C ES O
UN I DAD ES
Guía didáctica S OL U CI ON AR I O
158 Horas
Pablo Fernando Aguilar Cango
Docente Instituto Superior Tecnológico Sucúa
Sucúa – Morona Santiago
2019
AN EXO S

Guía Didáctica
2. ÍNDICE
Contenido
2. ÍNDICE ........................................................................................................ 3
3. INTRODUCCIÓN ......................................................................................... 5
4. BIBLIOGRAFÍA ........................................................................................... 6
4.1 Texto básico ............................................................................................ 6
BI BL I OG RA F ÍA
4.2 Bibliografía complementaria ...................................................................... 7
4.3 Referencias electrónicas ........................................................................... 7
5. ORIENTACIONES GENERALES PARA EL ESTUDIO .................................... 7
5.1 Los materiales educativos ......................................................................... 7
5.2 Planificación del estudio............................................................................ 8
OR I ENT A CI O NES
5.3 ¿Cómo estudiar? ...................................................................................... 9
5.4. Apoyo tecnológico .................................................................................. 12
6. PROCESO DE ENSEÑANZA APRENDIZAJE PARA EL LOGRO DE LAS
COMPETENCIAS .............................................................................................. 13
6.1 Competencias genéricas ......................................................................... 13
P RO C ES O
6.2 Sistema de evaluación de la asignatura ................................................... 13
6.3 Orientaciones específicas para el aprendizaje por competencias. ............... 13
Unidad 1: Conceptos básicos ................................................................... 15
1.1. Introducción a los sistemas de información. ................................ 29
UN I DAD ES
1.2. Técnicas para el levantamiento de información ........................... 46
1.2.1 Entrevista ..................................................................................... 46
1.2.2 Revisión de registro ......................................................................... 47
1.2.3 Observación .................................................................................... 47 S OL U CI ON AR I O
Autoevaluación 1 .......................................................................................... 48
Unidad 2: Documento de especificaciones ............................................. 49
2.1 Requerimientos funcionales. ................................................................ 49
2.2. Requerimientos no funcionales ............................................................ 49
2.3. Alcance del sistema ............................................................................. 51
AN EXO S
2.4. Tipos de usuarios y permisos ............................................................... 51

2.5. Descripción de módulos ....................................................................... 51
2.6. Arquitectura de hardware y software .................................................... 53

Guía Didáctica
Trabajo Autónomo ....................................................................................... 56

Autoevaluación 2 .......................................................................................... 57
Unidad 3: Estructuras repetitivas de datos ............................................ 58
3.1. Nociones básicas de lenguaje Z............................................................ 58
3.2. Diagrama de estados........................................................................... 62
3.3. Diagrama de clases ............................................................................. 68
3.4. Diagrama de Objetos .......................................................................... 74
BI BL I OG RA F ÍA
Trabajo Autónomo ....................................................................................... 78
Autoevaluación 3 .......................................................................................... 78
Unidad 4: UML Modelo conceptual .......................................................... 79
4.1. Entidades ........................................................................................... 80
4.2. Atributos ............................................................................................ 82
OR I ENT A CI O NES
4.3. Estándares de diseño de interfaces ...................................................... 84
Trabajo Autónomo ......................................................................................104
Autoevaluación 4 .........................................................................................105
7. SOLUCIONARIO (Autoevaluaciones) .....................................................106
8. ANEXOS ....................................................................................................111
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
3. INTRODUCCIÓN
La asignatura de Análisis y diseño de sistemas informáticos está considerada en la
malla curricular de la carrera de Tecnología Superior en Desarrollo de software, consta
de 6 créditos y es parte del campo de profesionalización de la carrera.
Esta asignatura se imparte con el objetivo de incorporar en el profesional en formación
BI BL I OG RA F ÍA
el concepto de conocer sobre el análisis y diseño de sistemas como el arte de definir
la arquitectura y procesos dentro de la etapas iniciales del desarrollo de sistemas
informáticos, componentes, módulos y diagramación, analizando las diferentes etapas
y los métodos de recopilación de información, a efectos de satisfacer los
diferentes requerimientos en el desarrollo de software. Además se analiza al diseño
OR I ENT A CI O NES
de sistemas y como éste es determinante al realizar las etapas iniciales en un proyecto
de software. Los métodos de análisis y diseño orientado a objetos están siendo los
métodos más ampliamente utilizados para el diseño de sistemas. Se analiza como
el UML (lenguaje unificado de modelado o por sus siglas en inglés, Unified Modeling
Language) se ha vuelto un estándar en el Análisis y diseño orientado a objetos ya que
P RO C ES O
es ampliamente utilizado para el modelado de sistemas de software y como se ha
incrementado su uso para el diseño de sistemas.
Esta asignatura corresponde a 158 horas las cuales se distribuyen en 72 horas teóricas,
UN I DAD ES
36 horas prácticas y 50 horas correspondientes a actividades autónomas, así mismo
estas se distribuyen en 4 unidades de trabajo y cada unidad tiene una actividad de
autoevaluación.
S OL U CI ON AR I O
Iniciar una carrera de educación superior, en ocasiones es una tarea difícil al comienzo.
Por eso es necesario que pongamos todo el esfuerzo y el empeño para no dejarnos
vencer por las diferentes dificultades que se presenten el transcurso del presente
periodo académico. Y veremos que pronto obtendremos resultados favorables que nos
traerán satisfacciones en todos los ámbitos.
AN EXO S
Adelante y ¡éxitos! ¡Ud. está llamado a grandes cosas!

Guía Didáctica
4. BIBLIOGRAFÍA
4.1 Texto básico
Aguilar Cango P.F. (2019) Guía didáctica. Análisis y diseño de sistemas informáticos,
Primer semestre. Tecnología Superior en Desarrollo de Software, Sucúa, Morona
Santiago, Ecuador, Instituto Superior Tecnológico Sucúa.
El docente responsable de la redacción de la presente guía, tiene amplia experiencia
BI BL I OG RA F ÍA
en el campo educativo, es actualmente docente de la Carrera de Tecnología Superior
en Desarrollo de Software, además de ser tutor y cumplir con las funciones propias
emitidas por la máxima autoridad.
La presente guía está estructurada de la siguiente manera, caratula, índice,

introducción, bibliografía; tanto bibliografía de texto básico (guía desarrollada por el
OR I ENT A CI O NES
docente) como también la bibliografía complementaria que son libros que se
recomienda para realizar las consultas referentes a los diferentes temas de análisis en
el componente curricular que se deberá estudiar, además de sugerir algunas
referencias electrónicas que serán de gran ayuda para el estudiante, orientaciones
generales para el estudio, materiales educativos, planificación del estudio, ¿Cómo
P RO C ES O
estudiar?, en esta sección se encontrara tips para que el proceso de inter aprendizaje
sea eficaz, apoyo tecnológico, planificación para el trabajo del estudiante, sistema de
evaluación de la asignatura y orientaciones específicas para el aprendizaje por
UN I DAD ES
competencias que se encuentra enmarcado dentro del modelo pedagógico del instituto
Superior Tecnológico Sucúa.
Luego de estas temáticas encontrara el desarrollo teórico practico de los diferentes

unidades de estudio, conceptos, ejemplos y demás, cada unidad de trabajo contiene S OL U CI ON AR I O
una auto evaluación y el cumplimiento de un trabajo autónomo.
Finalmente, se indican los solucionarios a las autoevaluaciones y anexos en donde se

propone un ejercicio práctico completo.
La guía didáctica es un instrumento que ayuda a manejar el texto haciendo

AN EXO S
aclaraciones, dando pistas para el ritmo de trabajo, proponiendo actividades para

aclarar conceptos y reafirmar conocimientos, utilizando las técnicas y orientaciones
que se estudia en el texto.

Guía Didáctica
4.2 Bibliografía complementaria

A pesar de que todos los contenidos están en el texto básico, indicamos unos pocos
textos adicionales que pueden servir de ayuda:
 KENDALL, H. & KENDALL, J. “Análisis y Diseño de Sistemas”. 3era. Ed.

Editorial Prentice Hall, México D.F. 1997
 Daniel Cohen Karen. Enrique Asín Lares(2000).Sistemas de información para
BI BL I OG RA F ÍA
los negocios.Mexico, McGrawHill
4.3 Referencias electrónicas

 http://cotana.informatica.edu.bo/downloads/ldAnalisis%20y%20Diseno%20de
OR I ENT A CI O NES
%20Sistemas_Kendall-8va.pdf
 https://ocw.unican.es/pluginfile.php/1403/course/section/1794/Ejemplo_Estru
cturado.pdf
5. ORIENTACIONES GENERALES PARA EL ESTUDIO
P RO C ES O
5.1 Los materiales educativos
Todos hemos recibido talentos y debemos ponerlos en práctica para no perderlos. Le

invito a animarse y a motivarse para empezar un trabajo intelectual sumamente
UN I DAD ES
complaciente. El trabajo intelectual es una aventura que pocas personas han tenido la
suerte de llevarla. No pierda usted esta oportunidad.
Al iniciar el estudio de una asignatura nos encontramos desorientados. No sabemos

S OL U CI ON AR I O
cómo empezar.
Nos asoma un panorama muy amplio y parece que va a superar nuestras fuerzas. Pues
bien, no hay que desalentarse. Vamos a dar unas indicaciones para que empecemos
a caminar poco a poco.
A manera de iniciación le hago estas preguntas:

AN EXO S
¿Quiere aprender técnicas y métodos de estudio que le ayuden en su vida a conocer

aquello que no conoce pero que le llama y le anima a seguir?

Guía Didáctica
¿Está dispuesto a pasar una buena parte de su tiempo estudiando tenazmente aun a
costa de ciertas satisfacciones momentáneas?
¿No se detiene ante el primer obstáculo que encuentra y más bien le estimula para
seguir adelante?
¿Le impulsa el anhelo de ascender a las altas cumbres? ¿Siente el llamado de una
estrella?
BI BL I OG RA F ÍA
Cualquiera que sea la respuesta a cada una de estas preguntas yo quiero asegurarle
que YA HA EMPEZADO A ESCALAR LA CUMBRE Y NADA DEBE DETENERLO.
USTED ES EL ARTÍFICE DE SU PROPIO DESTINO. ESTOY PARA AYUDARLE
EN LO QUE SÍ PUEDE HACER.
OR I ENT A CI O NES
Vamos a darles algunas ideas para que el trabajo sea más fructífero.
5.2 Planificación del estudio
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
BI BL I OG RA F ÍA
OR I ENT A CI O NES
P RO C ES O
5.3 ¿Cómo estudiar?
En primer lugar, debe tener presente los materiales que va a utilizar: el texto, la guía
didáctica, diccionario y material de escritorio dispositivos de almacenamiento y de ser
posible una PC de escritorio o laptop ya que eminentemente la carrera escogida tiene
UN I DAD ES
una relación y dependencia con uso de tecnologías de la información y comunicación.
Disponga de un lugar limpio y ordenado. Cuide de las condiciones ambientales en

cuanto a iluminación, temperatura y objetos que le rodeen, para que no lo distraigan.
S OL U CI ON AR I O
Pida que no le interrumpan mientras trabaja y aléjese del teléfono y de la televisión.
Hay que empezar planificando las actividades de todo el ciclo y estar dispuestos a
cumplirlas. Dentro de ello, es necesario hacer un horario tomando en cuenta el tiempo
mínimo para las actividades. Se requiere de unas veinte horas semanales de estudio
AN EXO S
para todas las asignaturas, de las cuales puede tomar unas cinco horas para análisis y
diseño de sistemas informáticos, es decir, cerca de una hora diaria. Realice una lectura
total del texto. Si esto no es posible por la extensión y falta de tiempo, hágalo leyendo

Guía Didáctica
lo que corresponde al primer parcial o, por lo menos, una primera unidad. Después de
esto realice una lectura comprensiva, tratando de entender cada concepto, frase,
párrafo, capítulo y el texto total. Lo mismo hay que hacer para el segundo bimestre.
Hay que trabajar conjuntamente el texto (modulo), la guía didáctica, consultar en el

diccionario las palabras cuyo significado no se sepa y utilizarlas durante las
conversaciones con otras personas.
BI BL I OG RA F ÍA
Subraye las ideas principales y anote las posibles respuestas a las preguntas del trabajo
de autoevaluación, colocando con un lápiz el número de la pregunta en la página del
texto o en un cuaderno para el efecto.
No se olvide hacer resúmenes de lo que va leyendo para luego utilizarlos en un repaso
OR I ENT A CI O NES
posterior.
Paralelamente, confeccione fichas de trabajo, cuestionarios personales, etc., anotando

lo más importante o sobresaliente.
Una vez que ha dado lectura a cada capítulo, realice las actividades recomendadas,
así como las autoevaluaciones, porque algunas de esas actividades pueden estar
P RO C ES O
tomadas en cuenta para los exámenes, a la vez que le permite medir el grado de
comprensión al que ha llegado.
Es una buena práctica conversar en familia sobre lo que se va aprendiendo, para recibir
UN I DAD ES
ideas y confrontarlas.
No siempre vamos a realizar nuestras tareas de la mejor forma, por eso no hay que
desesperarse si no se logra el éxito total en algún trabajo. Tenemos que sacar
S OL U CI ON AR I O
enseñanzas de nuestros errores y falencias. Pero lo que debemos observar es no dejar
para los últimos días el estudio del examen.
Finalmente, recuerde que sus actividades (Gestión Formativa) corresponden al 30%,

de su calificación, la gestión práctica (Proyecto de aula-integrador) 30% y hay una
evaluación presencial por parcial que corresponde al 40% de su calificación final. Se
AN EXO S
califica sobre 10 puntos. Es una prueba estructurada.
Ud. no debe conformarse con sacar la calificación mínima. Si cuando hacemos esfuerzo
por sacar la máxima calificación, a veces no avanzamos a hacerlo, mucho menos

Guía Didáctica
cuando nos proponemos metas mínimas. Las autoevaluaciones le sirven para que Ud.
mismo tenga una apreciación del avance de sus conocimientos. Al final de esta guía
se encuentra el solucionario para que compulse con sus respuestas.
Además no olvide cumplir con cada uno de los trabajos autónomos que se presentan
en cada unidad, estás se desarrollan para fortalecer su aprendizaje.
Una buena distribución del trabajo y su cumplimiento respectivo nos permite realizar
BI BL I OG RA F ÍA
otras actividades.
Quien más trabaja ordenadamente, de más tiempo dispone.
Recuerde aprovechar las videoconferencias, clases presenciales virtuales, tutorías y

asesoramiento, así como los recursos digitales subido a la plataforma virtual del
OR I ENT A CI O NES
instituto. Consulte con su docente si tiene dudas o preguntas, ya sea por medio del
chat de la plataforma, teléfono, celular o por correo electrónico.
¡Adelante en la tarea!
P RO C ES O
Nota importante:
Por su participación en ciertas actividades en la
plataforma virtual del instituto en cada parcial, usted
UN I DAD ES
podrá obtener algún puntaje adicional lo que motivara su
interacción en foros y actividades que será adicional la
nota obtenida en la evaluación a distancia; esto quiere
decir que si obtiene en la misma menos de 6 puntos
podrá incrementar su nota (hasta 6 puntos) por medio de
la participación, actividades y los ejercicios que su
tutor(a) le propondrá en la plataforma. S OL U CI ON AR I O
AN EXO S

Guía Didáctica
5.4. Apoyo tecnológico

Para realizar una coordinación directa entre el estudiante, el docente y la institución
educativa el estudiante debe utilizar la plataforma virtual oficial:
https://tecnologicosucua.milaulas.com/
A continuación usted puede observar los pasos para ingresa la plataforma virtual.
BI BL I OG RA F ÍA
1.
2.
OR I ENT A CI O NES
3.
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
6. PROCESO DE ENSEÑANZA APRENDIZAJE PARA EL LOGRO DE LAS

COMPETENCIAS
6.1 Competencias genéricas
Las competencias genéricas son aquellas que se requieren en la sociedad del
conocimiento y en el desempeño profesional para aprender a lo largo de la vida, tener
un desempeño exitoso y reconvertirse profesionalmente, si es el caso.
BI BL I OG RA F ÍA
6.2 Sistema de evaluación de la asignatura
OR I ENT A CI O NES
6.3 Orientaciones específicas para el aprendizaje por competencias
P RO C ES O
El Instituto Superior Tecnológico Sucúa se inspira en la pedagogía crítica, de corte
constructivista, que privilegia las competencias y las diversas visiones de la realidad y
donde el estudiante es el eje del proceso de aprendizaje.
UN I DAD ES
La Calidad: La calidad de educación superior se puede enfocar al proceso (las fases
y componentes de la actividad educativa del nivel superior: docencia, investigación,
vinculación con la colectividad y gestión); a los elementos que intervienen o
el “producto” (el ciudadano, el profesional o el científico que se forma); y a S OL U CI ON AR I O
los hallazgos de la investigación o a los resultados que se obtienen para la sociedad
(solución de problemas, a través de proyectos de intervención). “Calidad es la
valoración de un proceso o un resultado, que surge de la comparación de un modelo
teórico con la realidad”.
El Constructivismo: Los ejes del Modelo Educativo del Instituto, son el estudiante y
AN EXO S
sus aprendizajes. El docente es un facilitador o mediador, según el nuevo paradigma

llamado “aprendizaje significativo”. La Heurística: Aprendizajes basados en la

Guía Didáctica
investigación científica. La investigación representa un rubro importante en el plano

académico, y es la estrategia básica de la docencia de calidad.
Las Competencias tanto generales como específicas de cada carrera, establecidas en
el currículo general del instituto, como en los sílabos de cada carrera. Las
competencias se refieren al desarrollo de actitudes y aptitudes propias para el logro
de objetivos de aprendizaje.
BI BL I OG RA F ÍA
También se reconocen a las Competencias como el modelo pedagógico en el que el
estudiante “aprender a saber a hacer en contexto”, cuyos principios básicos de
formación son:
Aprender a aprender, que consiste en promover las capacidades para adquirir los
conocimientos y prácticas en que se sustentarán la labor profesional.
OR I ENT A CI O NES
Aprender a ser, que contempla la promoción de valores, actitudes y normas éticas
que orientarán el comportamiento e integración social, así como el desempeño
profesional de los alumnos.
Aprende a hacer, que trata del desarrollo de competencias para la aplicación de

principios, métodos y tecnologías de manera productiva a lo largo de la carrera.
P RO C ES O
Aprender a convivir, sobre la base del reconocimiento del otro, es decir, de los otros
seres humanos, en igualdad de dignidad, de derechos y deberes.
UN I DAD ES
Aprender a decidir con responsabilidad.
La planificación y evaluación del currículo son concebidas por competencias.
La Interdisciplinariedad. Es un principio rector del enfoque de las nuevas ciencias,

articulado a sistemas complejos de investigación que conducen a la S OL U CI ON AR I O
transdisciplinariedad. El Capital Intelectual, a través de la transferencia de

Tecnologías de Información y Comunicación (TICs), para la transmisión y construcción
de nuevos conocimientos y tecnologías.
La Didáctica Heterodoxa. Enfatiza en el aprendizaje más que en la enseñanza; en el

estudiante más que el docente; en la investigación más que en la transmisión de
AN EXO S
conocimientos; en la transferencia de métodos para aprender a aprender, antes que

fomentar la memorización; en el trabajo colaborativo antes que en el trabajo
exclusivamente

Guía Didáctica
Unidad 1: Conceptos básicos

“En una organización o empresa, el analista y diseño de sistemas es el proceso de
estudiar su situación con la finalidad de observar cómo trabaja y decir si es necesario
realizar una mejora; el encargado de realizar estas tareas es el analista de sistemas
para . Antes de comenzar el desarrollo de cualquier proyecto, se conoce un estudio de
sistema s para detectar todos los detalles de la situación actual en la empresa. La
información reunida con este estudio sirve como base para crear varias estrategias de
BI BL I OG RA F ÍA
diseño. Los administradores deciden qué estrategia seguir. Los gerentes, empleados y
otros usuarios finales que se familiarizan cada vez más con el empleo de computadoras
están teniendo un papel muy importante en el desarrollo de sistemas.
Todas las organizaciones son sistemas que actúan recíprocamente con su medio
ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden estar
OR I ENT A CI O NES
formados por otros sistemas más pequeños denominados subsistemas, funcionan para
alcanzar fines específicos. Sin embargo, los propósitos o metas se alcanzan sólo
cuando se mantienen el control.
SISTEMA DE INFORMACIÓN
P RO C ES O
Conjunto u ordenación de elementos organizados para llevar a cabo algún métodos,
procedimiento o control mediante el proceso de información.
UN I DAD ES
ANÁLISIS Y SISTEMAS
El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una
empresa con el propósito de mejorar con métodos y procedimientos más adecuados.
El desarrollo de sistemas tiene dos componentes. S OL U CI ON AR I O
Análisis Es el proceso de clasificación e interpretación de hechos, diagnostico de
problemas y empleo de la información para recomendar mejoras al sistemas.
Diseño: Especifica las características del producto terminado.
Análisis: Especifica que es lo que el sistema debe hacer.
Diseño: Establece como alcanzar el objetivo.
AN EXO S
EL ANALISTA DE SISTEMAS DE INFORMACIÓN

En una empresa pequeña, lo más probable es que realice las actividades:

Guía Didáctica
1.- Análisis de sistemas (Analista de información): Es reunir información y
determinar los requisitos. Los analistas no son responsables del diseño de sistema.
2.- Análisis y diseño del sistema (Diseñadores de sistemas, Diseñadores de
aplicaciones): El analista tiene la responsabilidad adicional de diseñar el nuevo sistema.
3.- Análisis, diseño y programación del sistema (Analista programador): Desarrolla
las especificaciones de diseño y escribe el s/w necesario para implementar el diseño.
BI BL I OG RA F ÍA
ELEMENTOS DE UN SISTEMA DE INFORMACIÓN
 SOFTWARE. Los programas de computadoras, as estructuras de datos y la
documentación asociada, que sirve para realizar el método lógico.
 HARDWARE: Los dispositivos electrónicos que proporcionan la capacidad de
OR I ENT A CI O NES
computación y que proporcionan las funciones del mundo exterior.
 GENTE: Los individuos que son usuarios y operadores del software y del hardware.
 BASES DE DATOS: Una colección organizada de información a la que se accede
mediante el software y que es una parte integral del funcionamiento del sistema.
 DOCUMENTACIÓN: Los manuales, los impresos y otra información descriptiva que
P RO C ES O
explica el uso y / o la operación.
 PROCESAMIENTOS: Los pasos que definen el uso específico de cada elemento del
sistema o el contexto procedimental en que reside el sistema.
 CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles de
UN I DAD ES
control tolerables de rendimiento por ejemplo: el sistema de control de un
calentador de agua.
S OL U CI ON AR I O
CLASIFICACIÓN DE LOS SISTEMAS DE INFORMACIÓN
Abiertos. Intercambian información, materiales y energía con su ambiente.
Cerrados. Son auto contenidos, no interactúan con el medio ambiente.
Probabilístico. No se conoce con certeza su comportamiento.
Determinístico. Cualquier estado futuro que adopten puede preciarse con antelación
AN EXO S
CARACTERÍSTICAS DE SISTEMA DE INFORMACIÓN

Sus principales características son:

Guía Didáctica
 Suelen lograrse ahorros significativos de mano de obra.

 Son el primer tipo de S.I. que se implanta en las organizaciones.
 Son intensivos en entradas y salidas de información; sus cálculos y procesos
suelen ser simples y poco sofisticados, requieren mucho manejo de datos para
poder realizar sus operaciones y como resultado generan también grandes
volúmenes de información.
 Tiene la propiedad de ser recolectores de información.
BI BL I OG RA F ÍA
 Son adaptables de aplicación que se encuentran en el mercado.
Ejemplos de sistemas de información: facturación, nóminas, cuentas por cobrar,

cuentas por pagar, contabilidad general.
OR I ENT A CI O NES
SISTEMAS DE APOYO PARA LA TOMA DE DECISIONES
Entre los tipos de sistemas que apoyan el proceso de toma de decisiones se idéntica
los siguientes:
 Sistemas de Soporte para la Toma de Decisiones (DSS: Decision
Support Systems)
P RO C ES O
Apoyar la toma de decisiones mediante la generación y evaluación sistemática de
diferentes alternativas o escenarios de decisión.
Un DSS no soluciona problemas, ya que solo apoya al proceso de toma de decisiones.
UN I DAD ES
La responsabilidad de tomar una decisión, de adoptar y de realizarla es de los
administradores, no del DSS. Puede emplearse para obtener información que revele
los elementos clave de los problemas y las relaciones entre ellos. También puede
usarse para identificar, crear y comunicar cursos de acción disponibles y alternativas S OL U CI ON AR I O
de decisión.
 Sistemas de Soporte para la Toma de Decisiones de Grupo (Group
Decisión Support Systems). Cubren el objetivo de lograr la participación de
un grupo de personas durante la toma de decisiones en ambientes de
anonimato y consenso, apoyando decisiones simultaneas.
AN EXO S
 Sistemas Expertos de Soporte para la Toma de Decisiones (DEss:

Expert Decision Supprt Systems). Permiten cargar bases de conocimiento

Guía Didáctica
que se integran por una serie de reglas de sentido común para que diferentes
usuarios las consulten, apoyen la toma de decisiones, la capacitación, etc.
 Sistemas de Información para Ejecutivos (EIS: Executive information
Systems). Están dirigidos a apoyar el proceso de toma de decisiones de los
altos ejecutivos de una organización, presentado información relevante y
usando recursos visuales de fácil interpretación, con el ejecutivo de mantenerlos
informados.
BI BL I OG RA F ÍA
Las principales características de estos sistemas son las siguientes:
 La Información que generan sirve de apoyo a los mandos intermedios y a la
alta administración en el proceso de toma de decisiones.
Suelen ser intensivos en cálculos y escasos en entrada y salidas de información.
OR I ENT A CI O NES

 Así, por ejemplo, un modelo de planeación financiera requiere poca información

de entrada, genera poca información como resultado pero puede realizar
muchos cálculos durante su proceso.
 No suelen ahorrar mano de obra.
 Suelen ser interactivos y amigable, con altos estándares de diseño grafico y
P RO C ES O
visual, ya que están dirigidos al usuario final.
 Apoyan la toma de decisiones que por su misma naturaleza son estructuradas
y no estructuradas.
UN I DAD ES
 Estos sistemas pueden ser desarrollados directamente por el usuario final sin la
participación operativa de los analistas y programadores del área de
informática.
S OL U CI ON AR I O
S.I. de Soporte para la Toma de Decisiones (DSS: Decision Support Systems)
Características
 Interactividad. Interactuar en forma amigable y con el cargado de tomar
decisiones.
 Tipo de decisiones. Apoya el proceso de toma de decisiones estructuradas y no
AN EXO S
estructuradas.
 Frecuencia de uso. Tiene una utilización frecuente por parte de la
administración.

Guía Didáctica
 Variedad de usuario. Puede emplearse por usuarios de diferentes áreas

funcionales.
 Flexibilidad. Permite acoplarse a una variedad determinada de estilos
administrativos participativos.
 Desarrollo que el usuario desarrolle de manera directa modelos de decisión sin
la participación operativa de profesionales en informática.
 Interacción ambiental. Permite la posibilidad de interactuar con información
BI BL I OG RA F ÍA
externa como parte de los modelos de decisión.
 Comunicación ínter organizacional. Facilita la comunicación de información
relevante de los niveles altos a los niveles operativos y viceversa, a través de
gráficas.
Acceso a bases de datos. Tiene la capacidad de acceder información de las
OR I ENT A CI O NES

bases de datos corporativas.

 Simplicidad. Simple y fácil de aprender y utilizar por el usuario final.
DSS integran en su mayoría un conjunto de modelos que apoyan las diferentes
decisiones a las que se enfrenta el tomador de decisiones.
P RO C ES O
Ventajas del uso de los DSS.
 Menores costos.
 Disponibilidad de una gran variedad de herramientas en el mercado que operan
UN I DAD ES
en el ambiente de microcomputadoras.
 Muy baja dependencia de personas que se encuentran fuera del control de
tomador de decisiones.
S OL U CI ON AR I O
Desventajas pueden ser:
 Falta de integridad y consolidación en la administración de la información.
 Problemas de seguridad de la información.
 Pérdida del control administrativa por parte del área de informática.
Las diferentes opciones para la implantación de los DSS
AN EXO S
 Implantación aislada en microcomputadoras.

 Implantación en microcomputadoras interconectadas y que constituyen una red
local.

Guía Didáctica
 Microcomputadoras conectadas a mini computadoras o servidores.
MÓDULOS FUNCIONALES QUE INTEGRAN UN DSS.
Una de las características que poseen los DSS es la facilidad de que un usuario, sin
tener conocimientos amplios sobre sistemas computacionales, pueda desarrollar sus
propios modelos de decisión. Estos modelos son construidos con la ayuda de las
herramientas, en términos generales se clasifican en herramientas de h/w y de s/w.
BI BL I OG RA F ÍA
MANEJO DE MODELOS
Permite al usuario utilizar modelos clásicos, que se encuentran desarrollados y
disponibles, formando la base de modelos. Pueden incluir:
Inventarios
OR I ENT A CI O NES

 Control de proyectos
 Programación lineal
 Simulación
 Colas
 Análisis estadísticos
P RO C ES O
 Planeación financiera y generación de esencias
MANEJO Y ADMINISTRACIÓN DE DATOS
UN I DAD ES
Incluye funciones tales como:
 Acceso a las bases de datos corporativos
 Generación de información privada en bases de datos locales.
 Manipulación de la información a través de técnicas de manejo de información. S OL U CI ON AR I O
DESARROLLO DE APLICACIONES
La mayoría de los DSS permite a los usuarios desarrollar sus propios modelos de
decisión.
En este sentido, el usuario diseña sus propios formatos de entrada y salida, así como
AN EXO S
la estructura de almacenamiento y las funciones de procesamiento, tal forma que el

sistema puede evolucionar de manera permanente, a través de los cambios.

Guía Didáctica
Prototipo, es diferente al proceso tradicional de desarrollo de un sistema tradicional de

desarrollo de un sistema transaccional típico.
Aplicaciones desechables, es decir, modelos de decisión que fueron desarrollados en
tiempo muy corto, para apoyar una decisión en particular.
INTERFACES GRÁFICAS, REPORTES Y CONSULTAS

Facilidad para explorar la información a través de graficas de alta calidad y reportes
BI BL I OG RA F ÍA
que se diseñan y obtienen en intervalos cortos de tiempo, la disponibilidad de
lenguajes de muy alto nivel para facilitar la consulta de información que contienen las
bases de datos.
BASE DE DATOS CORPORATIVA
Integra toda la información de la compañía, la cual pueden consultar los diferentes
OR I ENT A CI O NES
usuarios para construir y utilizar herramientas para la toma de decisiones.
BASES DE DATOS LOCALES Y ARCHIVOS PROPIETARIOS

Las bases de datos locales y los archivos propietarios son generados y utilizados por
los usuarios, para lo cual debe tomarse información de la de datos corporativa. Pueden
P RO C ES O
ser manipulados por el usuario.
Sistemas de Soporte para la Toma de Decisiones de Grupo (GSS: Group
UN I DAD ES
Decision Support Systems)
Los sistemas de Soporte para la Toma de Decisiones de Grupo (GDSS) para
considerarse como tal deben reunir un conjunto de características; las principales son
las siguientes: S OL U CI ON AR I O
 GDSS. Sistemas diseñados especialmente para apoyar las decisiones en grupo.
 La meta de GDSS. Es apoyar a los tomadores de decisiones en su trabajo.
 GDSS. Es fácil de aprender y de usar. Accesible para usuarios con diferentes
niveles de conocimiento computacional y de soporte a la decisión. Tales como
ventas, producción, recursos humanos, administración y finanzas.
AN EXO S
 Un GDSS. Contiene mecanismo para evitar el desarrollo de conductas negativas

en el grupo, como son los problemas de comunicación.

Guía Didáctica
 Un GDSS debe motivar a todos los miembros del grupo a participar de manera
activa. Es importante que pueda existir anonimato de la participación.
Las principales ventajas de GDSS son:
 Motiva a los miembros del grupo a trabajar juntos
 Da la misma oportunidad de participación a todos los miembros del grupo.
 Se optimiza el uso de la información que aporta cada miembro del grupo.
BI BL I OG RA F ÍA
 Proporciona un mecanismo para enfocar a grupo en problemas clave.
 Apoya el desarrollo de una memoria organizacional.
 Mejora la calidad de toma de decisiones.
 Incrementa la creatividad en la toma de decisiones.
OR I ENT A CI O NES
Las principales desventajas de GDSS son:
 Falta de costumbre al utilizar un sistema para soportar el proceso de toma de
decisiones.
 Resistencia al cambiar por parte de los administradores.
 La responsabilidad al tomar una decisión puede diluirse.
P RO C ES O
APLICACIONES DE LOS DGSS
 Establecimiento de la misión de una empresa.
UN I DAD ES
 Formulación de estrategias que ayudarán a que la misión se cumpla.
 Evaluación de administradores. Para incrementar el sueldo de un administrador
o para verificar que esté cumpliendo con su deber.
 Planeación de sistemas de información. Cuando se requiere introducir nueva S OL U CI ON AR I O
tecnología de sistemas de información es necesario modificar el plan de
sistemas
 Soporte en negociaciones.
 Apoyar los trabajos que visuales, como la selección de un empaque para un
nuevo producto.
AN EXO S
 Apoyar los trabajos que involucran diseño y revisiones de control de calidad.

 Apoyar una decisión en particular.

Guía Didáctica
Sistemas Expertos de Soporte para la Toma de Decisiones (EDSS: Expert

Decision Support Systems)
Los sistemas expertos constituyen el área de la inteligencia artificial que quizá en este
momento tiene más relación con el apoyo al proceso de la toma de decisiones en las
organizaciones.
Beneficios de la utilización de un sistema GDSS
BI BL I OG RA F ÍA
del personal especializado son detenidos durante el proceso de aprendizaje y están
listos para ser utilizados por diferentes personas.
sin experiencia.
OR I ENT A CI O NES
toma de decisiones. Las
decisiones podrán tomarse de 1 forma más ágil con el apoyo de un sistema experto.
descentralización de datos en el proceso de la toma de decisiones en aquellos casos

que se consideren convenientes.
P RO C ES O
COSTO QUE INVOLUCRA
 El Shell o paquete generador del sistema experto.
UN I DAD ES
 El equipo computacional o hardware que se requiera.
 Consultorio especializado.
 Contratación o pago a los ingenieros especialistas.
 El tiempo de los expertos. S OL U CI ON AR I O
 Costos de implantación.
 Costos involucrados con el mantenimiento y se guimiento del sistema.
Sistemas de Información para Ejecutivos (EIS: Executive Information
Systems)
AN EXO S
CARACTERÍSTICAS DE UN EIS
 Están diseñados para cubrir las necesidades específicas y particulares de la alta
administración de la empresa.

Guía Didáctica
 Extraen, filtran, comprimen y dan seguimiento a formación crítica del negocio.

 Pueden acceder información que se encuentra en línea, extrayéndose en forma
directa de las bases de datos de la organización
 El sistema está soportado por elementos especializados de hardware, tales
como monitores o videos de alta resolución y sensibles al tacto.
Características Adicionales que deben estar presentes para considerar a un ESS:
BI BL I OG RA F ÍA
 Contempla las facilidades de comunicación electrónica.
 Capacidad de análisis de datos, tales como hoja electrónica de cálculo.
 Herramientas para la organización personal del ejecutivo, tales como
calendario.
OR I ENT A CI O NES
FACTORES DEL ÉXITO DE UN EIS
Es necesario que cumpla con los siguientes factores:
 Que se vea bien. Debe de estar orientado al uso gráfico de las pantallas.
 Que sea relevante. Debe dar a los ejecutivos acceso a los datos que son
importantes para la organización y que se han identificado como críticos para
P RO C ES O
el éxito de la empresa.
 Que sea rápido. Se necesitan tiempos de respuesta cortos, de lo contrario los
ejecutivos dirán que están perdiendo su tiempo.
UN I DAD ES
 Que la información esté disponible y actualizada. Un ELS debe proporcionar a
los ejecutivos la información en el momento oportuno, es decir, cuando ellos la
requieren.
Los cuatros factores anteriores aseguran que un EIS se utilice en una empresa y que S OL U CI ON AR I O
tenga el éxito esperado.
EL PROCESO DE DESARROLLO DE UN EIS

El proceso de desarrollo de un EIS tiene características que lo hacen único.
En la primera instancia, porque es el primer sistema que se desarrolla en la empresa
AN EXO S
dirigida al ejecutivo, en segundo lugar, las técnicas utilizadas para el análisis y

desarrollo de los tradicionales sistemas transaccionales no necesariamente funcionan
100% de manera similar durante el desarrollo de un EIS.

Guía Didáctica
A continuación se propone una metodología para su desarrollo e implantación.

1.-Identificación de las alternativas para el desarrollo del sistema
Existen diferentes alternativas para el desarrollo de un EIS.
A continuación se mencionan algunas de las alternativas que existen para su
desarrollo:
 Desarrollar sistema de manera interna y partiendo de cero.
 Hacer modificaciones a los sistemas actuales con el fin de cubrir los requisitos
BI BL I OG RA F ÍA
del ejecutivo.
 Desarrollar el sistema partiendo de cero con la ayuda de desarrolladores
externos con experiencia previa en EIS.
 Cada una de estas alternativas tiene ventajas y desventajas en reglones tales
como costo tiempo y control durante el desarrollo de la aplicación.
OR I ENT A CI O NES
2.-Creación de la propuesta
En este paso debe escribirse o elaborarse una presentación de la propuesta del EIS.
La creación de la propuesta ayudará a tener un apoyo más sólido para el desarrollo
del EIS.
P RO C ES O
Las principales razones que existen para presentar de manera formal una propuesta
de un EIS son:
UN I DAD ES
 Claro entendimiento con el ejecutivo. Esto se refiere a que el desarrollo del EIS se
haga tomando como base lo que piensa el desarrollador y lo que espera el
ejecutivo de la organización o de la empresa.
 Reducir la resistencia al cambio. S OL U CI ON AR I O
 Manejar las expectativas. En la creación y presentación de una propuesta deben
ponerse en una balanza las expectativas. De la misma manera en que se hable de
los beneficios que pueden lograrse con un EIS, deben informarse los riesgos que
implica y de los recursos que requiere.
 Lograr el compromiso de los recursos.
AN EXO S
Con todo esto, el ejecutivo tendrá una visión más clara de lo que es un EIS, de las
expectativas con respecto a su uso y de los recursos que requiere su desarrollo.

Guía Didáctica
3.-.Determinación de las necesidades del ejecutivo

Este paso consiste en determinar las necesidades del ejecutivo. Turban surgiere un
conjunto de estrategias para lograr lo anterior:
 Cuestionar al ejecutivo acerca de cuáles son las preguntas que le gustaría
formular al regresar de un periodo vacacional de tres semanas.
 Realizar entrevistas con los directores o gerentes de las diferentes áreas
funcionales de la empresa.
BI BL I OG RA F ÍA
 Listar los principales objetivos de la empresa a corto y mediano plazos y definir
la información necesaria para darle seguimiento.
 Preguntar a los ejecutivos cuáles son los datos que no les gustaría que llegaran
a manos de la competencia.
A través de simple observación o entrevistas de terminar la información que
OR I ENT A CI O NES

utiliza en la actualidad el ejecutivo para monitorear la situación de la empresa.
4.- Creación del sistema y presentación de un prototipo

La clave para la creación de un EIS exitoso es el prototipo. En ocasiones en EIS se
P RO C ES O
describe como un prototipo.
SISTEMAS GERENCIALES
Una herramienta para soportar las funciones operativas. La perspectiva actual y futura
UN I DAD ES
tiende a cambiar este enfoque radicalmente, los sistemas de información son vistos
además como áreas de oportunidad para lograr ventajas en el terreno de los negocios,
y éstas representan un diferencial o valor agregado con respecto a los competidores.
La perspectiva estratégica considera a los sistemas de información como una S OL U CI ON AR I O
herramienta para mejorar la estructura competitiva del negocio, por lo que tienen su
área de influencia en el medio ambiente de la organización, a través de nuevos
servicios a clientes, nuevos negocios y oportunidades de inversión.
Wiseman define la visión gerencial o estrategia como <<la necesidad de entender de
qué forma la tecnología de la información es utilizada para soportar o dar forma a la
AN EXO S
estrategia competitiva de la empresa>>. Esta habilidad de ver y entender el nuevo rol

de los sistemas de información constituye la esencia de la visión de los sistemas de
información estratégica.

Guía Didáctica
Sus principales características son:

 Proporcionar información para apoyar la toma de decisiones.
 No pueden adaptarse fácilmente a paquetes disponibles en el mercado.
 Típicamente su forma de desarrollo es a base de incrementos y a través de su
evolución dentro de la organización.
 Su función es lograr ventajas que los competidores no posean, tales como
ventajas en costos y servicios diferenciados con clientes y proveedores. En este
BI BL I OG RA F ÍA
contexto, los sistemas estratégicos son creados de barreras de entrada al
negocio.
 Apoyan los procesos de innovación de productos y proceso dentro de la
empresa. Una forma de hacerlo es innovando o creando productos y procesos.
OR I ENT A CI O NES
Wisenman utilizan el término impulsos estratégicos para connotar los movimientos que
hace una empresa con el fin de ganar o mantener algún tipo de ventaja competitiva.
Las cinco categorías que contempla wiseman en cuanto a los impulsos estratégicos.
DIFERENCIACIÓN
P RO C ES O
Este impulso estratégico se refiere a la diferenciación de los productos o servicios a
través de precios, plazas o promociones. Proceso de diferenciación puede trabajar en
dos direcciones. La primera de ellas se refiere a lograr ventajas de diferenciación sobre
UN I DAD ES
los competidores utilizando la tecnología de la información; la segunda consiste en
identificar oportunidades para reducir las ventajas de diferenciación de los
competidores, clientes o proveedores
S OL U CI ON AR I O
COSTO
Se refiere a los movimientos que puede hacer la empresa para reducir sus costos o
bien provocar la reducción de costos a proveedores o clientes, con el fin de obtener
un trato preferencial.
Las economías de escala se logran cuando se aumenta el volumen de la ventas de
AN EXO S
productos o servicios para reducir los costos unitarios, a través de mejores

negociaciones con proveedores de servicio debidas a mayor volumen de compra.

Guía Didáctica
CRECIMIENTO
El impulso estratégico del crecimiento permite la consecución de ventas competitivas,
mediante el incremento del volumen de operaciones en el negocio.
El crecimiento de producto o mercado se refiere a la expansión de mercados,
satisfacción de nuevas necesidades o la incorporación de nuevas tecnologías asociadas
al producto. El crecimiento puede darse funcionalmente, es decir, sustituyendo los
servicios que proporcionan los proveedores, las funciones que llevan a cabo los clientes
BI BL I OG RA F ÍA
(hacia delante).
Pueden lograrse ventajas competitivas, el impulso estratégico de la globalización es,
según wiseman, un impulso de crecimiento que involucra elementos foráneos al
producto neto de la compañía.
OR I ENT A CI O NES
ALIANZAS
Las alianzas son definidas por wiseman como la combinación de dos más grupos o
individuos que se unen para lograr un objetivo común.
INNOVACIÓN
P RO C ES O
Otro de los impulsos estratégicas que puede ser apoyando a través de la tecnología
de información, ya sea en productos o en tecnología de información, ya sea en
productos o en procesos nuevos. Para que un proceso de innovación tenga éxito
UN I DAD ES
requiere respuestas rápidas a las oportunidades que se representan, sin embargo,
existen riesgos inherentes debido a la naturaleza del proceso, ya que es difícil innovar
sin correr riesgos.
El proceso de innovación consta de las siguientes fases: nacimiento de una idea, venta S OL U CI ON AR I O
de la idea a una persona con poder de decisión, desarrollo de la idea y lanzamiento al

mercado de la idea desarrollada.
Alcanzar al mercado la idea puede tenerse éxito o fracaso en el proceso. Si se tiene

éxito deben construirse barreras de entrada a esta innovación para protegerse de los
AN EXO S
competidores.”1
1
https://html.rincondelvago.com/analisis-y-diseno-de-sistemas-informaticos.html

Guía Didáctica
1.1. Introducción a los sistemas de información.
 Análisis y Diseño de Sistemas. Busca analizar sistemáticamente la entrada
de datos y flujo de los mismos.
 Proceso o transformación de datos. El almacenamiento de datos y salida
de información dentro del contexto de un negocio en particular.
 Entrada Proceso Salida. Resultado del proceso
BI BL I OG RA F ÍA
Ojo: Ser analista de sistemas es una carrera que demanda mucho pero en compensación es
cambiante y retadora.
Consultor:
 Ventaja: Lleva una perspectiva fresca.
OR I ENT A CI O NES
 Desventaja: La verdadera cultura organizacional nunca es conocida por
extraños.
Experto en soporte. Se apoya en la experiencia profesional relacionada con el

hardware, software y su uso en los negocios. Su trabajo sería hacer pequeñas
P RO C ES O
modificaciones o decisiones que afectan a un solo departamento. Solo sirve como un
recurso para aquellos que manejan un sistema.
UN I DAD ES
Agente de cambio. Es agente de cambio cada vez que ejecuta cualquiera de las
actividades del ciclo de vida del desarrollo del sistema y se esta presente en el negocio
por un periodo extendido.
Desarrolla un plan para el cambio y trabaja junto con otros para facilitar ese cambio.
S OL U CI ON AR I O
FUNCIONES DE UN SISTEMA DE INFORMACIÓN

 Reservaciones aéreas.
 Departamento de registro hospitalario.
 Control escolar.
AN EXO S
 Preparación de nóminas en operaciones bancarias.

 Sistema de intercomunicación electrónica.
 Entre otras.

Guía Didáctica
Para cumplir sus propósitos los sistemas interactúan con su medio ambiente es decir
cualquier entidad que se sitúa fuera de los límites del sistema (sistemas abiertos).
Los niveles de rendimiento se miden con estándares. Los rendimientos reales se
comparan contra los estándares que vienen de la experiencia.
Las actividades que están por encima o debajo de los estándares deben anotarse,
BI BL I OG RA F ÍA
estudiarse y ajustar.
Retroalimentación. La información suministrada a través de la comparación de los

resultados con los estándares y el informe de los elementos de control sobre las
diferencias. Ejemplo: Una empresa que produce pasteles caros y de baja calidad, las
OR I ENT A CI O NES
ventas bajas serían la retroalimentación.
Hay que tomar en cuenta los siguientes ejemplos de datos relevantes relacionados con
el sistema.
P RO C ES O
Canales no formales. ¿Qué interacciones existen entre el personal y los
departamentos, pero que no aparecen en el organigrama o en el procedimiento de
operación previamente establecido?
UN I DAD ES
Interdependencia. ¿En qué otras áreas, departamentos y componentes de la
empresa se encuentra una dependencia específica? Esto es, ¿Quiénes dependen de
quien para realizar sus funciones?
El personal clave. ¿Cuáles individuos y elementos del sistema son más S OL U CI ON AR I O
importantes para su existencia?¿Crees que una área a la que no se le haya tomado
en cuenta su opinión, hubiera aportado buenas idea al diseño de elaboración del
sistema sobre todo si tiene directamente que ver con su función?
Relaciones críticas de comunicación. ¿Cómo circula la información y las
instrucciones entre los componentes de la empresa y cómo interactúan las diferentes
AN EXO S
áreas?

Guía Didáctica
TIPOS DE SISTEMAS DE INFORMACIÓN

MODELO DE CONTROL BÁSICO PARA UN SISTEMA DE INFORMACIÓN
Consiste en:
BI BL I OG RA F ÍA
- Característica importante de la mayor parte de los sistemas de cómputo es la confiabilidad.
Confiabilidad depende de:

 La corrección permanente de su diseño.
 Lo correcto de la correspondencia entre este.
OR I ENT A CI O NES
 Lo que quiere el usuario.
 Funcionalidad de los componentes.
Los sistemas de SW como las personas son únicos. Su confiabilidad depende por
completo de la corrección de su diseño y aplicación.
Hardware. La confiabilidad puede lograrse mediante la duplicación de los
P RO C ES O
componentes o cambiando de forma automática cada parte si detecta algún fallo.
Para la confiabilidad del SW es difícil dar una definición precisa, el software es confiable
si es correcto, si cumple con especificaciones iniciales y se comporta estadísticamente
UN I DAD ES
según lo estipulado, aun que no se toma en cuenta que en su función interviene el
hombre. El logro de la alta confiabilidad implica una buena cantidad de codificaciones
(programas) adicionales, a menudo redundante, inesperado al sistema para realizar
las verificaciones necesarias, esto reduce la velocidad de ejecución del programa sin S OL U CI ON AR I O
embargo, su principal criterio para la calidad del sistema es la confiabilidad más que
la eficiencia.
Ejemplo. Pensar más en saber manejar u automóvil que en pensar si el sistemas lectivo
funciona correctamente.
AN EXO S
LA TOMA DE DECISIONES SE CLASIFICA EN:

Condición de certidumbre. No es común especialmente cuando se trata de
decisiones muy importantes. En este tipo de circunstancias las decisiones con muy

Guía Didáctica
difíciles porque se conocen todos los elementos que podrían resultar en el caso de
seleccionar una u otra alternativa.
Condiciones de incertidumbre. Se conoce de manera general las posibles
consecuencias, pero no recuenta con suficiente información como para asignar una
probabilidad a cada situación.
Condiciones de riesgo. Se conocen las posibles consecuencias y se cuenta con
suficiente información como para asignar una probabilidad a cada situación con la
BI BL I OG RA F ÍA
capacidad de poder correr el riesgo.
Si las decisiones requieren apoyo de la información se pueden dividir en 2 tipos:

 Estructuradas (repetitivas o programadas). Se toman en niveles intermedios
dentro de la organización.
OR I ENT A CI O NES
o Son predecibles.
o Su impacto (corto plazo). Afecta primordialmente las operaciones cotidianas
de la empresa. Ejemplo:
o Decidir el programa de producción del próximo bimestre.
o Decidir los instrumentos de inversión más rentables en corto plazo.
P RO C ES O
o Decidir el nuevo límite de crédito de los principales clientes.
o Decidir los pagos de proveedores que serán pospuestos debido a una aja
inesperada en el flujo de efectivo.
UN I DAD ES
 No estructuradas (no repetitivos o no programados).
 Se presenta en los niveles más altos de la organización.
 Considerable grado de incertidumbre.
 Su elemento relevante es la imposibilidad de predecir el tipo y escenario de la S OL U CI ON AR I O
decisión. Ejemplo:
 Cambio de una materia prima d mayor costo pero con mayor rendimiento.
 Análisis de factibilidad para determinar la conveniencia de iniciar la producción y
venta de un producto nuevo a un cliente, incrementando los volúmenes d
producción pero bajando de manera sensible el precio de venta.
AN EXO S
 Determinar la conveniencia de efectuar alianzas estratégicas con algún

competidor foráneo para optimizar los procesos de producción y mercado.

Guía Didáctica
La toma de decisiones se clasifica de acuerdo con el número de participantes en el

proceso:
 Decisiones independientes. Son tomadas en forma aislada por una persona.
 Decisiones secuénciales. Son generadas por un grupo de personas. El
tomador de decisiones solo participa una parte de la decisión y el resto es
transferido a otras áreas o ejecutivos de la organización para completar este
proceso.
BI BL I OG RA F ÍA
 Decisión simultánea. Solo se toma en grupos, son producto de la interacción
y negociación entre varias personas en forma simultánea.
Ingeniería d software. Es una disciplina que integra métodos, herramientas y
procedimientos para el desarrollo de programas con la intención de brindar el
apoyo en la toma de decisiones.
OR I ENT A CI O NES
Modelo de control básico
Entradas Sistema Salidas
Real = Se utiliza una experiencia previa.
CICLO DE VIDA DE UN SISTEMA
P RO C ES O
Ciclo de vida de un sistema:
 Definición del problema.

 Recopilación de información.
UN I DAD ES
 Análisis.
 Diseño.
 Programación.
 Prueba. S OL U CI ON AR I O
 Documentación.
 Implementación.
Objetivo. Conocer los elementos necesarios en cada paso de un ciclo de vida de un
sistema.
AN EXO S
Ciclo de vida de un sistema.

 También llamado modelo de cascada o SDLC (símbolos en ingles).

Guía Didáctica
 Es un enfoque sistemático y secuencial por fases del análisis y diseño de un sistema

de información.
Características.
 Las fases nunca se llevan como un paso a parte.
 Varias actividades pueden suceder simultáneamente.
 Las actividades pueden repetirse.
BI BL I OG RA F ÍA
Actividades. Proyecto. Traslapan.
Conclusión: Las actividades se traslapan y luego disminuyen.
CICLO DE VIDA IDENTIFICACIÓN DE:
Problemas:
OR I ENT A CI O NES
 Etapa crítica para el éxito del resto del proyecto.
 Requiere de la observación honesta del analista s/el negocio.
 Analista y personal hacen resaltar los problemas.
Oportunidades:
 Situaciones que el analista cree que pueda ser mejores.
P RO C ES O
 Permite que el negocio gane un avance competitivo que ponga un estándar de la
industria.
UN I DAD ES
Objetivo:
 Componente importante de la primera fase.
 El analista debe descubrir lo que está tratando de hacer el negocio.
 El analista será capaz de identificar si una aplicación de sistema de S OL U CI ON AR I O
información pude ayudar al sistema, negocio, a que alcance sus objetivos atacando
problemas específicos y oportunidades.
PRIMERA FASE
PLANTEAMIENTO DEL PROBLEMA:

AN EXO S
Reglas:
 Identificar los componentes, explicando las relaciones entre ellos.

Guía Didáctica
 Ubicar el problema dentro de un marco conceptual.

 Analizar el problema desglosando en sus unidades más simples.
 simplificando, eliminando la información redundante.
 investigar estudios análogos consultando la literatura existente.
 plantear el problema en una forma más variable para poder investigarlo.
Características:
BI BL I OG RA F ÍA
 Cada actividad realizada siempre es parte de un entorno mayor.
 El trabajo comienza estableciendo los requisitos de todos aquellos elementos
importantes del sistema.
 Asignando grupos con estos requisitos para integrar el sistema de cómputo.
OR I ENT A CI O NES
 Es esencial cuando el SW debe interrelacionarse con otros elementos SW, HW,
personas, base de datos, etc.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN

Herramientas: Muestra e investigación de datos relevantes.
P RO C ES O
 Entrevista.
 Cuestionario.
 Comportamiento de los tomadores de decisión.
 Prototipos.
UN I DAD ES
El analista: Comprende que información necesitan los usuarios para trabajar.
Sirve: Para formar la imagen que el analista tiene de la organización y sus objetivos. S OL U CI ON AR I O
Involucrados: Analista, usuarios, administradores de las operaciones.
El analista necesita:
Los detalles de las funciones actuales del sistema.
AN EXO S
 ¿Quien? Personas
 ¿Que? Actividad del negocio

Guía Didáctica
 ¿Donde? Ambiente
 ¿Cuando? En qué momento
 ¿Como? De qué manera se desarrollo
Al término de la fase:
El analista debe comprender el porqué de los funciones del negocio.
Tener informe sobre personas, objetivos y procedimientos.
BI BL I OG RA F ÍA
Herramientas: técnicas para la recolección de datos.
ANÁLISIS DE LAS NECESIDADES DEL SISTEMA

DISEÑO DEL SISTEMA (RECOMENDADO).
OR I ENT A CI O NES
 Usa la información recolectada anteriormente para hacer el diseño lógico de S1
(pseudo código, DF, etc.).
 Diseña procedimientos precisos para la captura de datos (diseño de entradas).
 Proporciona entrada efectiva para el sistema de información mediante el uso de
P RO C ES O
técnicas para el diseño de formas y pantallas
 Diseña la interfaz del usuario (teclado, menú de pantalla y ratón)
 Diseño de salidas
 Diseño de base de datos
UN I DAD ES
 Diseño de archivo
 Diseño de control y respaldo, etc.
OBJETIVO: Son las metas o fines hacia las, cuales se quiere llegar. Es determinar los S OL U CI ON AR I O
resultados deseados ¿Qué es lo que se requiere?
POLÍTICA: Son reglas que se establecen para dirigir funciones y seguir qué éstas se
desempeñen de acuerdo con los objetivos deseados (son guías para las toma de
decisión).
AN EXO S
MISIÓN: Es la función o tarea básica de una organización o individuo.

Guía Didáctica
ESTRATEGIA: Son planes, su función consiste en regir la obtención uso y disposición,

de los medios necesarios para alcanzar los objetivos.
REGLAS: Describen con claridad las acciones especificas requeridas o las que no se
deben llevar acabo.
Son aquellos que guían una acción sin especificar un orden de tiempo, de hecho.
BI BL I OG RA F ÍA
NORMAS: Todo señalamiento imperativo de algo que ha de realizarse sea genérico o
específico.
DISEÑO Y DOCUMENTACIÓN DEL SOFTWARE
OR I ENT A CI O NES
Las representaciones del diseño deben ser traducidas a un lenguaje artificial, dando
como resultado unas instrucciones ejecutadas por la computadora el paso de la
codificación es el que lleva acabo esa traducción.
Identificar
P RO C ES O
 Ambiente operativo
 Lógica de los programas
 Elección del lenguaje de programación
UN I DAD ES
Tipo de documentación
 Manual del usuario
 Manual de programación
 Manual del sistema S OL U CI ON AR I O
El analista trabaja con los programadores para desarrollar cualquier sw original que
necesite.
Incluye Diagrama estructurado, método HIPO, DF, diagram Nassi - s. y warnicr.

AN EXO S
Ojo: Muchos procedimientos sistemáticos que emplea el analista ayuda a mantener al

mínimo los mantenimientos.

Guía Didáctica
 Se desarrollan a lo largo del ciclo.

 Sirve para asegurar que toda información del software que este disponible.
 Documentación Confiabilidad a usuarios.
 Debe seguir creciendo.
Tomar en cuenta:
 Prueba.
BI BL I OG RA F ÍA
 Verificación y validación.
 Certificación confirmación que el programa esta bien hecho.
Importancia del mantenimiento. Los programas de computación deben ser
modificados y mantenidos y actualizados. La cantidad promedio del tiempo y gastado
en mantenimiento en una instalación del sistema de información gerencial (MIS) es de
OR I ENT A CI O NES
40% al 60%.
FACTORES QUE INFLUYEN EN LOS CAMBIOS QUE OCURREN EN LA

ORGANIZACIÓN
P RO C ES O
 Factores tecnológicos
 Viajar al espacio
 Velocidad de aplicación de la nueva tecnología
UN I DAD ES
 Factores sociales y económicos
 Nueva tecnología
 Nuevas oportunidades para el negocio sobre:
S OL U CI ON AR I O
 Proceso de producción
 Hacer algo que antes no era posible
 Relaciones ente negocios y competidores, clientes, proveedores, oficinas.
 Decisiones de alto nivel y presiones operativas

 En respuesta a las dos anteriores
AN EXO S
 Gerentes de alto nivel deciden:

 Reorganizar operaciones
 Construir una nueva pantalla

Guía Didáctica
 Introducir nuevos productos

 Nuevos procedimientos de presupuestos.
 Gerentes de bajo nivel de los departamentos operativos
 Emprender cambios para gozar reconocimientos y obtener recompensas.
 Estos gerentes de negocios enfrentan presiones de competencia y deben
responder lo siguiente:
 Productos nuevos y existentes
BI BL I OG RA F ÍA
 Precio de los productos y canales de distribución
 Financiamiento
¿Quiénes trabajan en el diseño de sistema de información para completar
una serie de pasos? El analista de sistemas, usuarios, usuarios de la información,
programadores, otros especialistas.
OR I ENT A CI O NES
¿Qué debemos considerar en la práctica antes de empezar el ciclo de vida
de un sistema? La natural resistencia ante el cambio del sistema que suele mostrar
la gente.
P RO C ES O
FORMAS QUE ADOPTA LA RESISTENCIA AL CAMBIO:
 Amenaza a la seguridad. Temor de perder el empleo o reducción en el salario.

 Reducción en la satisfacción social. Reorganización de los departamentos y los
UN I DAD ES
grupos de trabajo.
 Reducción en la autoestima y la reputación. Falta de conocimiento y experiencia
sobre los sistemas de computación. Miedo a la pérdida de status o prestigio.
S OL U CI ON AR I O
OTRO SÍNTOMAS:
 Negar la información
 Proporcionar hechos no existentes
 Mostrar poco empeño
AN EXO S
Administrar el cambio es una tarea difícil. No hay que preocuparse solo por los aspectos
técnicos del sistema e ignorar los factores humanos implícitos en la transmisión.

Guía Didáctica
ANÁLISIS DE SISTEMAS (REQUERIMIENTOS)

Determinación de la factibilidad y el manejo de las actividades de Análisis y Diseño.
FUNDAMENTOS DEL PROYECTO
El analista debe dominar:
 Iniciación del proyecto
 Determinación de la factibilidad del proyecto
BI BL I OG RA F ÍA
 Calendarización del proyecto
 Administración de las actividades y los miembros del equipo para logra
productividad.
OPORTUNIDAD DE MEJORAS
OR I ENT A CI O NES
 Aceleración de un proceso
 Analizar de un proceso mediante la eliminación de pasos innecesarios
SELECCIÓN DEL PROYECTO

 Respaldo de la administración
 Temporización
P RO C ES O
 Posibilidad de mejoras en los objetivos
 Practico
 Valioso en la inversión
UN I DAD ES
Un proyecto de sistema comienza con problemas y oportunidades de mejora dentro
de un negocio. Una vez que es sugerido un proyecto, el analista trabajara rápidamente
con los tomadores de decisiones, para determinar si es factible, si es aprobado se hará
S OL U CI ON AR I O
un estudio de sistemas completo. Las actividades son calenda rizadas mediante el uso
de herramientas como gráficas de Gantt y PERT para que el proyecto se realizar a
tiempo.
AN EXO S
INICIO DEL PROYECTO
Los sistemas se inician por muchas causas y razones diferentes. Algunos proyectos
sobrevivirán, otros no sobrevivirán a las diversas etapas de evaluación.

Guía Didáctica
Los proyectos son sugeridos por dos razones.
 Para experimentar en problemas que lleven por si mismo a soluciones de S.I.
 Para reconocer oportunidades y hacer mejoras mediante la actualización,
alteración o instalación de nuevos sistemas.
 Problemas de la organización
 Oportunidades de mejoras
BI BL I OG RA F ÍA
PROBLEMAS DENTRO DE LA ORGANIZACIÓN
Los problemas con proceso que son visibles en la salida que pueden requerir la ayuda
de un analista, incluyen errores excesivos y trabajado desarrollado demasiado lento,
incompleto, en forma incorrecta o incluso que no se realiza.
OR I ENT A CI O NES
Otros síntomas de problemas se hacen evidentes cuando las personas no logran los
objetivos.
 Errores
 Revisar salida contra Trabajo lento
 Trabajo incorrecto
P RO C ES O
 Criterios de desempeño Trabajo incompleto
 Trabajo no terminado
 Para identificar Ausentismo
UN I DAD ES
 Ob. del comportamiento Insatisfacción
 problemas Rotación del puesto
 Quejas
 Sugerencias de mejoras S OL U CI ON AR I O
 Retroalimentación Perdida de ventas

 Menores ventas
DETERMINACIÓN DE LA FACTIBILIDAD
AN EXO S
Deben ser calificados

Definir objetos con entrevistas

Guía Didáctica
Cifrado de proyectos
Evaluación inconsistente
Determinación Valoración de la Técnicamente
Determinar razones:
 Factibilidad Técnica
 Factibilidad Económica
BI BL I OG RA F ÍA
 Factibilidad Operacional
La realizan:
 Administradores
 Encargados (usuarios)
 Analistas
OR I ENT A CI O NES
Nota. El estudio de factibilidad debe estar altamente comprendido en tiempo,
comprendiendo varias actividades en un pequeño lapso.
PLANEACIÓN Y CONTROL DE LAS ACTIVIDADES
P RO C ES O
Plantación:
 Seleccionar un equipo para el análisis del sistema
 Asignar a los miembros en proyectos adecuados
UN I DAD ES
 Estimación de tiempo requerido para cada tarea
 Calendarización del proyecto para determinar las tareas y ordenamiento
Planeación Control Usar la retroalimentación
S OL U CI ON AR I O
ESTIMACIÓN DE TIEMPO REQUERIDO

GRAFICA DE GANTT
Una gráfica de Gantt es una forma fácil para calendarizar tareas. Es esencialmente una
AN EXO S
gráfica en donde las barras representan cada tarea o actividad. La longitud de cada
barra representa la longitud relativa de la tarea.

Guía Didáctica
En conclusión un sistema de información un sistema de información es un

conjunto de componentes que interaccionan entre sí para alcanzar un fin determinado,
el cual es satisfacer las necesidades de información de dicha organización. Estos
componentes pueden ser personas, datos, actividades o recursos materiales en
general, los cuales procesan la información y la distribuyen de manera adecuada,
buscando satisfacer las necesidades de la organización.
BI BL I OG RA F ÍA
El objetivo primordial de un sistema de información es apoyar la toma de decisiones y
controlar todo lo que en ella ocurre.
Análisis estructurado
Es un método para el análisis de sistemas manuales o automatizados, que conduce al

desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a
OR I ENT A CI O NES
los ya existentes. Cuando los analistas de sistemas abordan una situación poco
familiar, siempre existe una pregunta sobre donde comenzar el análisis. El análisis
estructurado permite el analista conocer un sistema o proceso (actividad) en una forma
lógica y manejable el mismo tiempo que proporciona la base para asegurar que no se
omite ningún detalle pertinente.
P RO C ES O
Método para la selección de proyectos
Método del comité directivo: Supervisan la revisión de propuestas para los
UN I DAD ES
proyectos, reciben las propuestas y las evalúa.
Método del comité de sistema de información: Es donde se aprueba o hasta se

rechaza el proyecto mostrando los elementos mas importantes dentro del mismo. S OL U CI ON AR I O
Análisis y diseño de un sistema
Defina y detalle el ciclo clásico de un sistema
Es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para

AN EXO S
desarrollar e implantar un sistema de información. El método del ciclo de vida para el

desarrollo de sistemas consta de 6 fases:

Guía Didáctica
1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de

información puede originarse por varias razones: sin importar cuales sean estas, el
proceso se inicia siempre con la petición de una persona.
2). Determinación de los requerimientos del sistema: El aspecto fundamental

del análisis de sistemas es comprender todas las facetas importantes de la parte de la
empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados
BI BL I OG RA F ÍA
y administradores, deben estudiar los procesos de una empresa para dar respuesta a
las preguntas.
3). Diseño del sistema: El diseño de un sistema de información produce los detalles
que establecen la forma en la que el sistema cumplirá con los requerimientos
OR I ENT A CI O NES
identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con
frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del
software, a la que denominan diseño físico.
4). Desarrollo del software: Los encargados de desarrollar software pueden instalar
P RO C ES O
software comprobando a terceros o escribir programas diseñados a la medida del
solicitante. La elección depende del costo de cada alternativa, del tiempo disponible
para escribir el software y de la disponibilidad de los programadores.
UN I DAD ES
5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de
manera experimental para asegurarse de que el software no tenga fallas, es decir, que
funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan S OL U CI ON AR I O
que lo haga.
6). Implantación y evaluación: La implantación es el proceso de verificar e instalar

nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los
archivos de datos necesarios para utilizarla.La evaluación de un sistema se lleva a cabo
AN EXO S
para identificar puntos débiles y fuertes.

Guía Didáctica
Metodología de Kendall
“El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el
análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan
mejor utilizando un ciclo especifico de actividades del analista y el usuario.”
El ciclo de vida de un sistema consta de siete partes:
BI BL I OG RA F ÍA
FASE I: Identificación de problemas, oportunidades y objetivos Identificar los
problemas de la organización, detallarlos, examinar, evaluar las oportunidades y
objetivos. Las oportunidades son situaciones que el analista considera susceptibles de
mejorar utilizando sistemas de información computarizados, lo cual le da mayor
seguridad y eficacia a las organizaciones además de obtener una ventaja competitiva.
OR I ENT A CI O NES
FASE II: Determinación de los requerimientos de información
Se esfuerza por comprender la información que necesitan los usuarios para llevar a
cabo sus actividades.
FASE III: Análisis de las necesidades del sistema
P RO C ES O
Evalúa las dos fases anteriores, usa herramientas y técnicas como el uso de diagramas
de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones
del negocio en una forma gráfica estructurada.
UN I DAD ES
FASE IV: Diseño del sistema recomendado
En esta fase el analista utiliza la información recopilada en las primeras fases para
realizar el diseño lógico del sistema de información.
S OL U CI ON AR I O
FASE V: Desarrollo y documentación del software
El analista trabaja de manera conjunta con los programadores para desarrollar
cualquier software original necesario.La documentación indica a los usuarios cómo
utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso.
FASE VI: Prueba y mantenimiento del sistema

AN EXO S
Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos

costoso encontrar los problemas antes que el sistema se entregue a los usuarios.El

Guía Didáctica
mantenimiento del sistema de información y su documentación empiezan en esta fase

y se llevan de manera rutinaria durante toda su vida útil.
FASE VII: Implementación y evaluación
Se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la
imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de
sistemas.Se menciona la evaluación como la fase final del ciclo de vida del desarrollo
BI BL I OG RA F ÍA
de sistemas principalmente en áreas del debate. En realidad, la evaluación se lleva a
cabo durante cada una de las fases.
Definiciones
OR I ENT A CI O NES
Técnica: Es el procedimiento o el conjunto de procedimientos que tienen como
objetivo obtener un resultado determinado, ya sea en el campo de la ciencia, de la
tecnología, o en otra actividad.La técnica implica el conocimiento de las operaciones
como el manejo de las habilidades, tanto de las herramientas como los conocimientos
técnicos y la capacidad de inventiva.Una técnica es una manera de lograr
P RO C ES O
eficientemente una tarea en una manera que no es inmediatamente obvia o directa.
Herramienta: Es un dispositivo que cuando se usa de forma adecuada, mejora el

rendimiento de tarea, tal como el desarrollo de sistema de información basados en
UN I DAD ES
computadora.
Método: Es una serie de pasos sucesivos que conducen a una meta o fin dado.
Metodología: Consiste en los procedimientos que deben llevarse a cabo para cumplir
S OL U CI ON AR I O
con lo estipulado por ella y obtener conclusiones verídicas sobre el fenómeno o
problema que se analiza.
1.2. Técnicas para el levantamiento de información

1.2.1 Entrevista
AN EXO S
“Es una interacción verbal, que consiste en obtener información sobre hechos,
personas, está conformada por 2 tipos la estructurada y la no estructurada.

Guía Didáctica
 La entrevista estructurada: Constituye un interrogatorio, para el cual se han

preparado previamente un conjunto de preguntas. Las preguntas se formulan
siempre en el mismo orden y en los mismos términos; el interrogador anota las
respuestas en forma textual o atendiendo a un código.
 La entrevista no estructurada: Deja al entrevistado mayor margen de libertad

e iniciativa, se utilizan preguntas abiertas, no hay formas estándar.
BI BL I OG RA F ÍA
Cuestionario o Encuesta
Son serie de preguntas ordenadas que buscan obtener información de
parte de quien las responda. El cuestionario en sistemas puede ser
utilizado como ayuda o complemento de las entrevistas y
OR I ENT A CI O NES
observaciones personales.
1.2.2 Revisión de registro

Es buscar el historial de lo que ha sucedido anteriormente.
P RO C ES O
1.2.3 Observación
Consiste en examinar e investigar alguna situación, hecho, fenómeno, etc, con el fin
de recolectar datos o información para describir lo que se esta detallando. Los métodos
de revelamiento de información se pueden dividir en estáticos y dinámicos, se
UN I DAD ES
denomina estáticos aquellos en los que las personas dicen lo que hacen y dinámicos
en los que lo ocultan.
Requerimientos: Es una necesidad documentada sobre el contenido, forma o S OL U CI ON AR I O
funcionalidad de un producto o servicio.”2
Trabajo autónomo:
Desarrollar un resumen de las técnicas de levantamiento de datos.
AN EXO S
2
ion-sistematica.blogspot.com/2012/11/tecnicas-de-levantamiento-de-informacion.html

Guía Didáctica
Autoevaluación 1
Escriba el acrónimo de los siguientes términos. (1 punto)
a). S/W:_________________
b). RAM:_________________
c). H/W:_________________
d). PC:__________________
Escribe V si usted considera que es verdadero y F si lo considera falso a la

siguiente interrogante.
BI BL I OG RA F ÍA
El análisis y diseño de sistemas se refiere al trabajo de examinar la situación de una
empresa con el propósito de automatizar y mejorar procesos. ( ).
Una con líneas las respuestas correctas: (1 punto)
a. Proceso objetivo y directo de

obtener información. Entrevista
b. Se utiliza preguntas abiertas y/o cerradas
OR I ENT A CI O NES
c. Se realiza a varias personas de la empresa
utilizando un cuestionario. Encuesta
d. La persona puede ampliarse en la respuesta
Complete:
• Uno delos objetivos de los S.I. es ________________ los procesos manuales de una
organización o empresa.
• Sistema de Información: Sistema cuya finalidad es __________ datos de entrada
para producir como salida información oportuna, relevante y confiable.
P RO C ES O
Complete la siguiente gráfica. (1 punto)
UN I DAD ES
Unir con líneas los conceptos que corresponden (2 puntos)
Conjunto de actividades jcompletamente informales

o rigurosamente estructuradas, que definen la
forma en la cual el trabajo es realizado dentro Procesos de negocio
de la organización y con su entorno. S OL U CI ON AR I O
Los Procesos de Negocio son diseñados para

producir un resultado usando los recursos
disponibles del negocio y que tiene un valor
para este.
El material, energía e información que es

consumida y producida por una organización.
AN EXO S
Incluyen a la gente, dinero, equipamiento, Recursos de negocio

tecnología y Know-How. También se incluyen agentes
externos a la organización como proveedores, clientes,
contratistas, autoridades reguladoras, y otros.

Guía Didáctica
Unidad 2: Documento de especificaciones

2.1 Requerimientos funcionales.
Los requerimientos funcionales son declaraciones de los servicios que proveerá el
sistema, de la manera en que éste reaccionará a entradas particulares. En algunos
casos, los requerimientos funcionales de los sistemas también declaran explícitamente
lo que el sistema no debe hacer.
BI BL I OG RA F ÍA
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en
la especificación de requerimientos. Para un desarrollador de sistemas es natural dar
interpretaciones de un requerimiento ambiguo con el fin de simplificar su
implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que
estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la
OR I ENT A CI O NES
entrega de éste e incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe estar

completa y ser consistente. La compleción significa que todos los servicios solicitados
por el usuario están definidos. La consistencia significa que los requerimientos no
tienen definiciones contradictorias.
P RO C ES O
En la práctica, para sistemas grandes y complejos, es imposible cumplir los
requerimientos de consistencia y compleción. La razón de esto se debe parcialmente
UN I DAD ES
a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de
vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los
requerimientos se especifican por primera vez. Los problemas emergen después de un
análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones
S OL U CI ON AR I O
o en las fases posteriores del ciclo de vida, se deben corregir en el documento de
requerimientos.
2.2. Requerimientos no funcionales
Son aquellos requerimientos que no se refieren directamente a las funciones

AN EXO S
específicas que entrega el sistema, sino a las propiedades emergentes de éste como
la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma

Guía Didáctica
alternativa, definen las restricciones del sistema como la capacidad de los dispositivos
de entrada/salida y la representación de datos que se utiliza en la interface del sistema.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las
restricciones en el presupuesto, a las políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas de software o hardware o a factores externos
como los reglamentos de seguridad, las políticas de privacidad, entre otros.
BI BL I OG RA F ÍA
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
• Requerimientos del producto. Especifican el comportamiento del producto; como los

requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria
OR I ENT A CI O NES
se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea
aceptable; los de portabilidad y los de usabilidad.
• Requerimientos organizacionales. Se derivan de las políticas y procedimientos

existentes en la organización del cliente y en la del desarrollador: estándares en los
P RO C ES O
procesos que deben utilizarse; requerimientos de implementación como los lenguajes
de programación o el método de diseño a utilizar, y los requerimientos de entrega que
especifican cuándo se entregará el producto y su documentación.
UN I DAD ES
• Requerimientos externos. Se derivan de los factores externos al sistema y de su
proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la
manera en que el sistema interactúa con los otros sistemas de la organización; los S OL U CI ON AR I O
requerimientos legales que deben seguirse para asegurar que el sistema opere dentro
de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para
asegurar que será aceptado por el usuario.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes

no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de
AN EXO S
éstas, como las de mantenimiento, no existen métricas que se puedan utilizar; el costo

Guía Didáctica
de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy

alto.
En principio, los requerimientos funcionales y no funcionales se diferencian en el
documento de requerimientos. En la práctica, esto es difícil. Si un requerimiento no
funcional se declara de forma separada a los funcionales, algunas veces es difícil ver
la relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil
separar las condiciones funcionales y no funcionales e identificar los requerimientos
BI BL I OG RA F ÍA
que se refieren al sistema como un todo. Se debe hallar un balance apropiado que
dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que
claramente se refieren a las propiedades emergentes del sistema se deben resaltar.
Esto se hace colocándolos en una sección aparte o diferenciándolos, de alguna forma,
de los otros requerimientos del sistema.
OR I ENT A CI O NES
2.3. Alcance del sistema
Esta actividad tiene como objetivo definir el alcance del sistema a construir. Dada la
especificación de los requerimientos y la aprobación de los mismos por el
P RO C ES O
Cliente/usuario se realiza un documento que especifique, en lenguaje natural, lo que
comprende y de que trata el sistema a construir.
2.4. Tipos de usuarios y permisos
UN I DAD ES
Esta actividad tiene como objetivo definir el alcance del sistema a construir. Dada la
especificación de los requerimientos y la aprobación de los mismos por el
Cliente/usuario se realiza un documento que especifique, en lenguaje natural, lo que
S OL U CI ON AR I O
comprende y de que trata el sistema a construir.
2.5. Descripción de módulos
En programación, un módulo es una porción de un programa de ordenador. De las

varias tareas que debe realizar un programa para cumplir con su función u objetivos,
AN EXO S
un módulo realizará, comúnmente, una de dichas tareas (o varias, en algún caso).

Guía Didáctica
En general (no necesariamente relacionado con la programación), un módulo recibe

como entrada la salida que haya proporcionado otro módulo o los datos de entrada
al sistema (programa) si se trata del módulo principal de éste; y proporcionará una
salida que, a su vez, podrá ser utilizada como entrada de otro módulo o bien contribuirá
directamente a la salida final del sistema (programa), si se retorna al módulo principal.
Particularmente, en el caso de la programación, los módulos suelen estar (no
BI BL I OG RA F ÍA
necesariamente) organizados jerárquicamente en niveles, de forma que hay un módulo
principal que realiza las llamadas oportunas a los módulos de nivel inferior.
Cuando un módulo es convocado, recibe como entrada los datos proporcionados por
otro del mismo o superior nivel, el que ha hecho la llamada; luego realiza su tarea. A
OR I ENT A CI O NES
su vez este módulo convocado puede llamar a otro u otros módulos de nivel inferior si
fuera necesario; cuando ellos finalizan sus tareas, devuelven la salida pertinente al
módulo inmediato llamador, en secuencia reversa. Finalmente se continúa con la
ejecución del módulo principal.
P RO C ES O
 Características de un módulo
“Cada uno de los módulos de un programa idealmente debería cumplir las siguientes
características:
UN I DAD ES
- Tamaño relativamente pequeño.- Esto facilita aislar el impacto que pueda tener
la realización de un cambio en el programa, bien para corregir un error, o bien
por rediseño del algoritmo correspondiente.
S OL U CI ON AR I O
- Independencia modular.- Cuanto más independientes son los módulos entre sí,
más fácil y flexiblemente se trabajará con ellos. Esto implica que para desarrollar
un módulo no es necesario conocer detalles internos de otros módulos. Como
consecuencia de la independencia modular, un módulo cumplirá:
AN EXO S
Características de caja negra; es decir, abstracción

Aislamiento de los detalles mediante encapsulamiento

Guía Didáctica
La independencia modular mejora el rendimiento humano, pudiendo

realizarse programación en equipo y desarrollar módulos paralelamente.
También contribuye a la reutilización de software.”3
2.6. Arquitectura de hardware y software
BI BL I OG RA F ÍA
 Arquitectura De Hardware
“¿Qué es hardware?
Es que todo lo físico que podemos ver en una computadora,

es considerado como hardware. Todo lo que usted puede
OR I ENT A CI O NES
llegar a tocar de una computadora, es el hardware. O sea,
el monitor, el teclado, el mouse, la impresora, etc. Cada
uno de estos elementos por separados, no son nada. Pero al unirlos de manera
conjunta, para formar una computadora, pasan a ser parte del hardware de nuestro
terminal computacional.
P RO C ES O
Definición de arquitectura de Hardware
UN I DAD ES
La arquitectura de hardware es el diseño conceptual y la estructura operacional
fundamental de un sistema de computadora. Es decir, es un modelo y una descripción
funcional de los requerimientos y las implementaciones de diseño para varias partes S OL U CI ON AR I O
de una computadora, con especial interés en la forma en que la unidad central de
proceso (UCP) trabaja internamente y accede a las direcciones de memoria.
También suele definirse como la forma de seleccionar e interconectar componentes de

hardware para crear computadoras según los requerimientos de funcionalidad,
AN EXO S
rendimiento y costo.
3
https://es.wikipedia.org/wiki/M%C3%B3dulo_(inform%C3%A1tica)

Guía Didáctica
El ordenador recibe y envía la información a través de los periféricos por medio de los
canales. La UCP es la encargada de procesar la información que le llega al ordenador.
El intercambio de información se tiene que hacer con los periféricos y la UCP. Todas
aquellas unidades de un sistema exceptuando la UCP se denomina periférico, por lo
que el ordenador tiene dos partes bien diferenciadas, que son: la UCP (encargada de
ejecutar programas y que está compuesta por la memoria principal, la Unidad
aritmético lógica (UAL) y la Unidad de Control) y los periféricos (que pueden ser de
BI BL I OG RA F ÍA
entrada, salida, entrada-salida y comunicaciones).”4
 Arquitectura De Software
“¿Qué es Software?
OR I ENT A CI O NES
Existen varias definiciones similares aceptadas para software, pero probablemente la
más formal sea la siguiente:
Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación

y datos asociados, que forman parte de las operaciones de un sistema de computación.
P RO C ES O
Considerando esta definición, el concepto de software va más allá de los programas
de computación en sus distintos estados: código fuente, binario o ejecutable; también
su documentación, los datos a procesar e incluso la información de usuario forman
UN I DAD ES
parte del software: es decir, abarca todo lo intangible, todo lo «no físico» relacionado.
S OL U CI ON AR I O
AN EXO S
4
http://luisxdsena.blogspot.com/p/arquitectura-de-hardware.html

Guía Didáctica
Definición de arquitectura de Software
BI BL I OG RA F ÍA
OR I ENT A CI O NES
En los inicios de la informática, la programación se consideraba un arte y se
P RO C ES O
desarrollaba como tal, debido a la dificulta que entrañaba para la mayoría de las
personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías
generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha
denominado Arquitectura de Software, porque, a semejanza de los planos de un
UN I DAD ES
edificio o construcción, estas indican la estructura, funcionamiento e interacción entre
las partes del software. En el libro "An introduction to Software Architecture", David
Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño que hace foco
S OL U CI ON AR I O
en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el
diseño y especificación de la estructura global del sistema es un nuevo tipo de
problema"
- La Arquitectura del Software es el diseño de más alto nivel de la estructura de

un sistema.
AN EXO S

Guía Didáctica
- Una Arquitectura de Software, también denominada Arquitectura lógica,

consiste en un conjunto de patrones y abstracciones coherentes que
proporcionan el marco
- Una arquitectura de software se selecciona y diseña con base en objetivos y

restricciones. Los objetivos son aquellos prefijados para el sistema de
información, pero no solamente los de tipo funcional, también otros objetivos
BI BL I OG RA F ÍA
como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros
sistemas de información. Las restricciones son aquellas limitaciones derivadas
de las tecnologías disponibles para implementar sistemas de información. Unas
arquitecturas son más recomendables de implementar con ciertas tecnologías
mientras que otras tecnologías no son aptas para determinadas arquitecturas.
OR I ENT A CI O NES
Por ejemplo, no es viable emplear una arquitectura de software de tres capas
para implementar sistemas en tiempo real.
- La arquitectura de software define, de manera abstracta, los componentes que

llevan a cabo alguna tarea de computación, sus interfaces y la comunicación
entre ellos. Toda arquitectura debe ser implementable en una arquitectura física,
P RO C ES O
que consiste simplemente en determinar qué computadora tendrá asignada
cada tarea.
- La arquitectura de software, tiene que ver con el diseño y la implementación de
UN I DAD ES
estructuras de software de alto nivel. Es el resultado de ensamblar un cierto
número de elementos arquitectónicos de forma adecuada para satisfacer la
mayor funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales como la confiabilidad, escalabilidad, portabilidad, S OL U CI ON AR I O
y disponibilidad.”5
Trabajo Autónomo
- Desarrollar un documento ejemplo de SRD.
AN EXO S
5
http://luisxdsena.blogspot.com/

Guía Didáctica
Autoevaluación 2
Subraye la respuesta correcta. (1 punto)
De la siguiente lista cuales son tipos de sistemas informáticos
o Sistemas de automatización de oficinas (OAS)
o Sistemas de herramientas case (SCASE)
o Sistemas de información administrativa (MIS)
o Sistemas de procesamiento de transacciones (TPS)
o Sistemas de soporte para ejecutivos (ESS)
o Sistemas asistidos por la web
o Sistemas de trabajo colaborativo asistido por computadora
BI BL I OG RA F ÍA
siguiente interrogante. (1 punto)
Existen tipos de metodología de desarrollo.
La metodología del ciclo de vida del desarrollo de sistemas (SDLC),
metodologías ágiles y metodologías orientadas a objetos. ( ).
Complete: Fases de Desarrollo de Sistemas (1 punto)
OR I ENT A CI O NES
1. Identificación de los problemas, oportunidades y objetivos
2. ________________________________________________
3. Análisis de las necesidades del sistema
4. Diseño del sistema recomendado
5. _______________________________________________
6. _______________________________________________
7. Implementación y evaluación del sistema
2. Complete: (2 puntos)
P RO C ES O
TPS: son sistemas de información _____________ que se desarrollaron para procesar
grandes cantidades de información para las ______________ de negocios rutinarias,
como __________ e inventario.
3. Complete la siguiente tabla. (2 punto)
UN I DAD ES
ACRÓN SIGNIFICADO EN INGLÉS SIGNIFICADO EN
CASTELLANO
TPS Operations Processing Systems
OAS Office Automation Systems S OL U CI ON AR I O
Administrative Information Systems S. de información administrativa
GDSS
KWS Knowledge Work Systems
Decision support systems Sistemas de soporte dedecisiones
Executive support systems
CSCWS
SDLC
Object Oriented Analysis Análisis Orientado a Objeto
AN EXO S
DFD
Graphical User Interfaces Interfaces gráficas de usuario
UML Unified Modeling Language

Guía Didáctica
Unidad 3: Estructuras repetitivas de datos

3.1. Nociones básicas de lenguaje Z.
El Lenguaje Z es un lenguaje formal utilizado en Ingeniería del software para la
especificación formal de un sistema de cómputo, como una fase previa al desarrollo
del código de programa para el mismo en un lenguaje de programación. Fue
desarrollado por Jean-Raymond Abrial mientras formaba parte del Grupo de
BI BL I OG RA F ÍA
investigación en Programación del Laboratorio de computación de la Universidad de
Oxford.
El lenguaje Z se basa en la teoría de conjuntos, el cálculo lambda y la lógica de primer

orden. En Z se definen construcciones denominadas esquemas para describir el
OR I ENT A CI O NES
espacio de estados del sistema y las operaciones que sobre el mismo se efectúan. En
los esquemas se declaran variables y predicados que afectan los valores de las
variables declaradas.
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
Ejemplo:
Descripción Especificcion en Z
El ejemplo de especificación en Z mostrado en la

imagen se encuentra en el libro de Spiveyes un
sencillo ejemplo de un sistema de manejo de una
BI BL I OG RA F ÍA
agenda de cumpleaños. Ha sido adaptado para
este artículo gracias a la herramienta Z-eves.
En la primera línea podemos observar la
OR I ENT A CI O NES
declaración de dos conjuntos, el conjunto de
todos los nombres: NOMBRE y el conjunto de
todas las fechas: FECHA, en la especificación se
los declara como tipos básicos.
P RO C ES O
El primer esquema que vemos: AgendaCumple es
el esquema principal de la especificación y define
el espacio de estados del sistema. En el mismo
UN I DAD ES
se definen las variables: contactos (como el
conjunto de nombres cuyos cumpleaños están
agendados – subconjunto de todos los nombres
S OL U CI ON AR I O
- ) y cumple como una función parcial con
dominio en el conjunto NOMBRE e imagen en el
conjunto FECHA; en la siguiente parte del
esquema se define una condición o invariante del
sistema, que en este caso indica que el
conjunto contactos es igual al dominio de la
AN EXO S
función cumple.

Guía Didáctica
El esquema IniciarAgendaCumple representa el

estado inicial del sistema.
Los siguientes esquemas definen las operaciones
que se realizan sobre el sistema:
El esquema AgregarCumple especifica la
BI BL I OG RA F ÍA
operación de agregar un nuevo cumpleaños, la
letra griega delta delante del nombre del
esquema principal, indica que luego de esta
operación se producirá un cambio de estado,
OR I ENT A CI O NES
luego se declaran 2 variables: nombre? y fecha?,
la decoración (?), indica que son variables
de entrada; las condiciones que se declaran son
que los valores de la variable nombre? NO deben
pertenecer al conjunto contactos y que el estado
inmediato posterior del conjunto cumple
P RO C ES O
(cumple') es igual al estado anterior unión la upla
conformada por el nombre y la fecha ingresadas.
UN I DAD ES
El esquema BuscarCumple especifica la operación
de búsqueda de un cumpleaños dado un nombre,
se puede apreciar que las variables
S OL U CI ON AR I O
de salida poseen la decoración (!), en este caso
la letra griega theta delante del nombre del
esquema principal, denota que esta operación no
producirá un cambio de estados. Aquí las
condiciones son que los valores de la variable de
AN EXO S
entrada nombre? deben pertenecer al

conjunto contactos y que el valor de la variable
de salida fecha! será igual al valor devuelto por

Guía Didáctica
la función cumple aplicada al valor de la

variable nombre?
Finalmente el esquema Recordatorio especifica la
operación que dada un fecha, el sistema nos
devuelve el conjunto de los cumpleaños que
ocurren en la misma, como puede verse tampoco
BI BL I OG RA F ÍA
modifica el estado del sistema y la condición
indica que la variable de salida tarjetas! deberá
ser igual al conjunto de nombres tal que al aplicar
la función cumple sobre cualquiera de ellos el
resultado es igual al valor del la variable de
OR I ENT A CI O NES
entrada hoy?
 Estándar
El lenguaje Z logró el estandar ISO en el 2002. Se puede obtener una copia
P RO C ES O
directamente en el sitio de la ISO.
 Herramientas
UN I DAD ES
- ERZ - Herramienta basada en Web para integrar paradigmas de integración,
específicamente transforma del modelo entidad relación a su equivalente
en lenguaje Z, desarrollada en PHP por Luis Espino, Guatemala.
S OL U CI ON AR I O
- Fastest una herramienta de testeo de código abierto para el Lenguaje Z.
- Fuzz - Es un chequeador de tipos para lenguaje Z.
- HOL-Z entorno de prueba de código abierto para Z en Isabelle/HOL
- Z Word Tools - Permite escribir especificaciones en Microsoft Word.

AN EXO S
- ZETA sistema de código abierto para el desarrollo de especificaciones en Z.
- Z/Eves — Un tester de pruebas para el Lenguaje Z (sitio en Alemán)

Guía Didáctica
3.2. Diagrama de estados
“Este muestra la secuencia de estados por los que pasa bien un caso de uso, un objeto
a lo largo de su vida, o bien todo el sistema. Es una forma de representación gráfica
más intuitiva de los autómatas finitos basadas en dígrafos con arcos acotados llamados
transiciones en los cuales se ponen los símbolos de tránsito entre un vértice (estado)
y otro y se identifican los estados de partida y los de aceptación del resto. Los
BI BL I OG RA F ÍA
diagramas de estados finitos son también representaciones más cómodas para su
elaboración, legibilidad y comprensión de distintos tipos de abstracciones
computacionales de reconocimiento como los autómatas de pila y las máquinas de
Turing.
OR I ENT A CI O NES
P RO C ES O
Concepto: Muestra la secuencia de estados por los que pasa bien un caso de
uso, un objeto a lo largo de su vida, o bien todo el sistema
UN I DAD ES
Características
Sea un autómata finito definido por la 5-tupla A=<Q, T, g, F, q0>, donde Q es

el conjunto de estados, T el alfabeto de símbolos terminales, la relación de
S OL U CI ON AR I O
transiciones , F son los estados finales o de llegada dentro
de Q, q0 es el estado inicial o de partida; se le llama diagrama de estados de A al grafo
orientado con aristas y vértices acotados de la forma siguiente:
Todos los estados de Q se representan por círculos en cuyo interior se designa el

nombre del estado que representa.
AN EXO S

Guía Didáctica
El estado inicial q0 se indica agregando una saeta corta a su izquierda que no tiene
origen alguno y concluye en el borde de la circunferencia, normalmente en los 180
grados del mismo.
Los estados finales se indican o bien sombreando el círculo o poniendo un borde doble
al estado.
Pueden existir estados iniciales finales, simplemente se aplican los dos casos
BI BL I OG RA F ÍA
anteriores. A cada transición entre los estados qi y qj con el símbolo terminal x o la
cadena vacía ε se representa como un arco etiquetado con x ó ε según corresponda.
Si entre los estados y en el mismo sentido hay varias transiciones con los terminales x1,
x2, ..., xn entonces se indican en el mismo arco pero separados por espacio o comas
OR I ENT A CI O NES
según convenga.
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S
Función
En el diagrama de estados se indica qué eventos hacen que se pase de un estado a

otro y cuáles son las respuestas y acciones que genera. También ilustra qué eventos

Guía Didáctica
pueden cambiar el estado de los objetos de la clase. En cuanto a la representación, un

diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son
transiciones etiquetadas con los nombres de los eventos. Normalmente contienen:
estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos,
acciones y actividades. Al igual que otros diagramas, en los diagramas de estado
pueden aparecer notas explicativas y restricciones.
BI BL I OG RA F ÍA
Definición de Estado
Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está
esperando alguna operación, tiene cierto estado característico o puede recibir cierto
tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados,
OR I ENT A CI O NES
que puede tener tres compartimientos: uno para el nombre, otro para el valor
característico de los atributos del objeto en ese estado y otro para las acciones que se
realizan al entrar, salir o estar en un estado. También en casos mas simples se usan
círculos con textos dentro para la representación de los estados, como para
los autómatas finitos.
P RO C ES O
Partes que conforman el Diagrama de Estados
Estado
UN I DAD ES
Un estado se representa como una caja redondeada con el nombre del estado en su
interior.
Una transición se representa como una flecha desde el estado origen al estado destino.
S OL U CI ON AR I O
La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento
aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden
aparecer acciones de entrada, de salida y acciones internas.
Eventos
AN EXO S
Es una ocurrencia que puede causar la transición de un estado a otro de un objeto.

Esta ocurrencia puede ser una de varias cosas:

Guía Didáctica
 Condición que toma el valor de verdadero o falso

 Recepción de una señal de otro objeto en el modelo
Recepción de un mensaje
Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha
particular. El nombre de un evento tiene alcance dentro del paquete en el cual está
definido, no es local a la clase que lo nombre.
BI BL I OG RA F ÍA
Envío de mensajes
Además de mostrar y transición de estados por medio de eventos, puede representarse

el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante
una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.
OR I ENT A CI O NES
Transición simple
Una transición simple es una relación entre dos estados que indica que un objeto en
el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones,
cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como
P RO C ES O
una línea sólida entre dos estados, que puede venir acompañada de un texto con el
siguiente formato:
UN I DAD ES
Transición interna
Es una transición que permanece en el mismo estado, en vez de involucrar dos estados
distintos. Representa un evento que no causa cambio de estado. Se denota como una
S OL U CI ON AR I O
cadena adicional en el compartimiento de acciones del estado.
Acciones
Se puede especificar la solicitud de un servicio a otro objeto como consecuencia de
la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar,
salir, estar en un estado, o por la ocurrencia de un evento.
AN EXO S
Generalización de Estados

Guía Didáctica
Se puede reducir la complejidad de estos diagramas usando la generalización de

estados. Se distingue así entre superestado y subestados. Un estado puede contener
varios subestados disjuntos. Los subestados heredan las variables de estado y las
transiciones externas. La agregación de estados es la composición de un estado a
partir de varios estados independientes. La composición es concurrente por lo que el
objeto estará en alguno de los estados de cada uno de los subestados concurrentes.
La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza
BI BL I OG RA F ÍA
un estado final no anidado. La llegada a un estado final anidado implica la subida al
superestado asociado, no el fin del objeto.
Subestados
OR I ENT A CI O NES
Un estado puede descomponerse en subestados, con transiciones entre ellos y
conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de
inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel
inmediatamente superior.
P RO C ES O
Transacción Compleja
Una transición compleja relaciona tres o más estados en una transición de múltiples
fuentes y/o múltiples destinos. Representa la subdivisión en threads del control
UN I DAD ES
del objeto o una sincronización. Se representa como una línea vertical de la cual salen
o entran varias líneas de transición de estado.
Transición a estados anidados

S OL U CI ON AR I O
Una transición de hacia un estado complejo (descrito mediante estados anidados)
significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del
estado complejo se entienden como transiciones desde cada uno de los subestados
hacia afuera (a cualquier nivel de profundidad).
AN EXO S
Transiciones temporizadas
Las esperas son actividades que tienen asociada cierta duración. La actividad de espera
se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena una

Guía Didáctica
transición que permite salir del estado que alberga la actividad de espera. El flujo de
control se transmite entonces a otro estado.
 Ventajas y Desventajas
Ventajas
El Diagrama de Estados tiene éxito en sistemas interactivos, ya que expresa la
BI BL I OG RA F ÍA
intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las

necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la
gente especializada en informática dirija la funcionalidad del nuevo sistema basándose
solamente en criterios tecnológicos.
OR I ENT A CI O NES
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las
tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor
aportan al negocio. Esto facilita luego la priorización del requerimiento.
Desventajas
P RO C ES O
La inclusión de estas relaciones hace que los diagramas sean más difíciles de leer,
sobre todo para los clientes.
UN I DAD ES
Importancia
Los diagramas de estado en el caso de los automatas finitos, además de mejorar su

legibilidad, comprensión, e incluso visualizar una especie de primera aproximación S OL U CI ON AR I O
material a su implementación física o computacional; también ayudan a visibilizar las
propiedades del AF más intuitivamente que en la notaciones de la 5-tupla o la de la
tabla de transiciones.
Por ejemplo un autómata finito no determinista se reconoce con más prontitud viendo
AN EXO S
si en su esquema aparecen las transiciones de la forma:

Guía Didáctica
(Transición no determinista).
(Transición vacía).
O si existe un estado inaccesible desde el inicio como en el caso:
BI BL I OG RA F ÍA
OR I ENT A CI O NES
Entre otras muchas situaciones.”6
3.3. Diagrama de clases
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S
6
https://www.ecured.cu/Diagrama_de_estado

Guía Didáctica
“Diagramas de Clase en UML . El UML (Lenguaje Unificado de Modelado), es una de

las herramientas mas emocionantes en el mundo actual del desarrollo de sistemas.
Esto se debe a que los creadores de sistemas generar diseños que capturen sus ideas
en forma convencional y bacín de aprender para comunicarlas a otras personas.
El UML es la creación de Grady Booch, James Rumbaugh e Ivar Jacobson. “Los tres
Amigos” como se apodaron estos tres grandes utilizaban metodologías diferentes para
el diseño de software hasta que en los años 90 decidieron unirse y trabajar en conjunto
BI BL I OG RA F ÍA
en una solo metodología, el UML está compuesto pro diversos elementos gráficos que
se combinan para conformar diagramas, con las mismas finalidades que es presentar
diversas perspectivas de un sistema a las cuales se conoce como modelo. En este
artículo nos estaremos refiriendo principalmente al Diagrama de Clases.
OR I ENT A CI O NES
Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
agregación, ya que una clase es una descripción de conjunto de objetos que comparten
los mismos atributos, operaciones, métodos, relaciones y semántica; mostrando un
conjunto de elementos que son estáticos, como las clases y tipos junto con sus
P RO C ES O
contenidos y relaciones. Un diagrama de clases esta compuesto por los siguientes
elementos: Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición,
Agregación, Asociación y Uso.
UN I DAD ES
Notación de Clase
Las clases se representan por rectángulos que muestran el nombre de la clase y

opcionalmente el nombre de las operaciones y atributos. Los compartimientos se usan S OL U CI ON AR I O
para dividir el nombre de la clase, atributos y operaciones. Adicionalmente las

restricciones, valores iniciales y parámetros se pueden asignar a clases.
En el siguiente diagrama la clase contiene el nombre de la clase en el compartimiento

más alto, el compartimiento siguiente detalla los atributos, con el atributo del “centro”
AN EXO S
mostrando los valores iniciales. El último compartimiento muestra las operaciones, las
operaciones setWidth, setLength y setPosition mostrando sus parámetros.

Guía Didáctica
La notación que precede el nombre del atributo u operación indica la visibilidad del
elemento, si se usa el símbolo + el atributo y la operación tienen un nivel público de
visibilidad, si se usa un símbolo – el atributo u operación es privado. Además, el
símbolo # permite definir una operación o atributo como protegido y el símbolo ~
indica la visibilidad del paquete.
Tablas
BI BL I OG RA F ÍA
Una tabla es una clase estereotipada. Esto se dibuja con un pequeño icono de la tabla
en la esquina superior derecha. Los atributos de la tabla son «columnas»
estereotipadas. La mayoría de las tablas tendrán una clave primaria, siendo uno o más
campos los que forman una combinación única usada para acceder la tabla, más una
OR I ENT A CI O NES
operación de clave primaria que es «PK» estereotipada. Algunas tablas tendrán una o
más claves foráneas, siendo uno o más campos que juntos trazan a una clave foránea
en una tabla relacionada, más una operación de clave foránea que es «FK»
estereotipada.
P RO C ES O
Atributos y Métodos
Los atributos o características de una Clase pueden ser de tres tipos, los que definen
el grado de comunicación y visibilidad de ellos con el entorno, estos son:
UN I DAD ES
 public (+,): Indica que el atributo será visible tanto dentro como fuera de la
clase, es decir, es accsesible desde todos lados.
 private (-,): Indica que el atributo sólo será accesible desde dentro de S OL U CI ON AR I O
la Clase (sólo sus métodos lo pueden accesar).
 protected (#,): Indica que el atributo no será accesible desde fuera de la clase,
pero si podrá ser accesado por métodos de la clase además de las subclases
que se deriven (ver Herencia).
AN EXO S
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su
entorno, éstos pueden tener las características:

Guía Didáctica
 public (+,): Indica que el método será visible tanto dentro como fuera de
la Clase, es decir, es accsesible desde todos lados.
 private (-,): Indica que el método sólo será accesible desde dentro de la clase
(sólo otros métodos de la clase lo pueden accesar).
 protected (#,): Indica que el método no será accesible desde fuera de la clase,
pero si podrá ser accesado por métodos de la clase además de métodos de las
BI BL I OG RA F ÍA
subclases que se deriven (ver herencia).
Relaciones
Ahora ya definido el concepto de Clase, es necesario explicar como se pueden
OR I ENT A CI O NES
interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en
cada extremo de la relación y éstas pueden ser: – uno o muchos: 1..* (1..n) – 0 o
muchos: 0..* (0..n) – número fijo: m (m denota el número).
P RO C ES O
Herencia
UN I DAD ES
Indica que una subclase hereda los métodos y atributos especificados por una
superclase, de esta forma la subclase además de poseer sus propios métodos y
atributos, poseerá las características y atributos visibles de la superclase (public y
protected).
S OL U CI ON AR I O
Agregación
Para modelar objetos complejos, no es suficiente con los tipos de datos básicos que
proveen los lenguajes:
AN EXO S
 Enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos

que son instancias de clases definidas por el desarrollador de la aplicación, tenemos
dos posibilidades:

Guía Didáctica
o Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto
incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo
de relación es comúnmente llamada Composición (el Objeto base se construye
a partir del objeto incluido, es decir, es "parte/todo").
o Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida

del objeto incluido es independiente del que lo incluye. Este tipo de relación
BI BL I OG RA F ÍA
es comúnmente llamada Agregación (el objeto base utiliza al incluido para su
funcionamiento).
Asociación
OR I ENT A CI O NES
La relación entre clases conocida como Asociación, permite asociar objetos que
colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de
vida de un objeto no depende del otro.
Dependencia o Instanciación
P RO C ES O
Representa un tipo de relación muy particular, en la que una clase es instanciada (su
instanciación es dependiente de otro objeto/clase). Se denota por una flecha
punteada. El uso más particular de este tipo de relación es para denotar la dependencia
UN I DAD ES
que tiene una clase de otra, como por ejemplo una aplicación Gráfica que instancia
una ventana (la creación del Objeto Ventana esta condicionado a la instanciación
proveniente desde el objeto Aplicación):
S OL U CI ON AR I O
Ventajas y Desventajas
 Ventajas
o Genera un código automáticamente.
o Propone soluciones a algunos errores.

AN EXO S
o Representa las relaciones entre las clases de sistema.

Guía Didáctica
o Se diseña los componentes de los sistemas.
o Se protegen los datos.
o Se posibilita una reducción de acoplamiento.
o Más fácil la comunicación entre los programadores, descubrimiento de

fallas del sistema en el diseño Mejor diseño del sistema ofrece más
documentación.
BI BL I OG RA F ÍA
 Desventajas
o Los diagramas de clases especifican qué clases hay y cómo están

relacionadas, pero no cómo interactúan para alcanzar comportamientos
OR I ENT A CI O NES
particulares.
o El método tiende hacer muy lento.
o La instalación es muy costosa”7
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S
7
https://www.ecured.cu/Diagrama_de_Clase

Guía Didáctica
3.4. Diagrama de Objetos
BI BL I OG RA F ÍA
OR I ENT A CI O NES
Un diagrama de objetos UML representa una instancia específica de un diagrama de
P RO C ES O
clases en un momento determinado en el tiempo. Cuando se lo representa
visualmente, verás muchas similitudes con el diagrama de clases.
UN I DAD ES
Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo
esos objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama de objetos,
las tres cuentas bancarias están ligadas al banco mismo. Los títulos de clase muestran
el tipo de cuentas (ahorros, corriente y tarjeta de crédito) que un cliente dado podría S OL U CI ON AR I O
tener con este banco en particular. Los atributos de clase son diferentes para cada tipo
de cuenta. Por ejemplo, el objeto de tarjeta de crédito tiene un límite de crédito,
mientras que las cuentas de ahorros y corriente tienen tasas de interés. Para examinar
este documento con más detalle, haz clic aquí.
AN EXO S
No obstante, los diagramas de objetos no se limitan a casos de uso bancarios, ya que

se puede crear fácilmente un diagrama de objetos para árboles genealógicos,
departamentos corporativos o cualquier otro sistema con partes interrelacionadas.

Guía Didáctica
BI BL I OG RA F ÍA
OR I ENT A CI O NES
Elementos de los diagramas de objetos
Los diagramas de objetos son sencillos de crear: se componen de objetos,

representados por rectángulos, conectados mediante líneas. Echa un vistazo a los
elementos principales de un diagrama de objetos.
P RO C ES O
Objetos
Los objetos son instancias de una clase. Por ejemplo, si "coche" es una clase, un Altima
UN I DAD ES
2007 de Nissan es un objeto de una clase.
Títulos de clases
S OL U CI ON AR I O
Los títulos de clases son los atributos específicos de una clase dada. En el diagrama
de objetos de árbol genealógico, los títulos de clases incluyen nombre, género y edad
de los integrantes de la familia. Se pueden listar títulos de clases como elementos en
el objeto o incluso en las propiedades del propio objeto (como el color).
AN EXO S

Guía Didáctica
BI BL I OG RA F ÍA
OR I ENT A CI O NES
Atributos de clases
Los atributos de clases se representan por medio de un rectángulo con dos pestañas
que indica un elemento de software.
Enlaces
P RO C ES O
Los enlaces son líneas que conectan dos figuras de un diagrama de objetos entre sí.
El diagrama de objetos corporativo siguiente muestra cómo los departamentos están
UN I DAD ES
conectados al estilo del organigrama tradicional.
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
Aplicaciones del diagrama de objetos
A un desarrollador le resultarán útiles los diagramas de objetos en muchos de los
casos. Dichos casos incluyen:
 Revisión de una iteración específica de un sistema general.

 Obtención de una vista de nivel alto del sistema que desarrollarás.
 Prueba de un diagrama de clases que creaste para la estructura general del
BI BL I OG RA F ÍA
sistema, por medio de diagramas de objetos para casos de uso específicos.
Otros ejemplos de diagramas de objetos UML
Las especificaciones UML generalmente no cambian cuando describimos un diagrama
OR I ENT A CI O NES
de objetos en diferentes lenguajes de programación. La finalidad del UML es que los
desarrolladores planifiquen software independientemente de las plataformas
específicas. A continuación se encuentran dos de los tipos de diagramas de objetos
más comúnmente usados en diferentes lenguajes de programación.
Diagrama de objetos en Objective C
P RO C ES O
Objective C se ha vuelto muy popular desde el lanzamiento de "Objective C 2.0" de
Apple, y ahora es el lenguaje de programación preferido para las aplicaciones de la
UN I DAD ES
tienda virtual de Apple. La mayoría de las personas que usen diagramas de objetos en
Objective C están intentando mostrar instancias para una aplicación de iPhone.
Diagrama de objetos en Java

S OL U CI ON AR I O
Hay diagramas de objetos que se pueden usar en UML para describir instancias que
se programarían en Java en última instancia y hay diagramas que describen objetos
Java que no tienen nada que ver con UML. Ya sea que busques los primeros o los
últimos, Lucidchart puede ayudarte a trazar la estructura que necesites crear. Pruébalo
por ti mismo.”8
AN EXO S
8
https://www.lucidchart.com/pages/es/diagrama-de-objetos-uml

Guía Didáctica
Trabajo Autónomo
Investigar sobre las técnicas de diseño Orientado a Objetos
Autoevaluación 3
En referencia al lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified
Modeling Language) identifique la siguiente definición:
BI BL I OG RA F ÍA
Especifica una interacción entre un actor y el sistema, de modo tal que
pueda ser entendida por una persona sin conocimientos técnicos, también
permite captar una función visible para los actores.
a) Diagramas de flujo b) Casos de uso

c) Actores d) Diagrama de actividades
Complete el siguiente enunciado. (1 punto)
OR I ENT A CI O NES
Utilice la alternativa que considere correcta: Secuencia - Actividades - Flujo – Estado.
Diagramas de ________: Son una herramienta que sirve para modelar cómo afecta
un escenario a los estados que un objeto toma, en conjunto con los eventos que
provocan las transiciones de estado.
Identifique y seleccione la opción correcta. (1 punto)

¿Cuáles de las siguientes características corresponden a Elementos distintivos de un
diagrama de estado?
P RO C ES O
1. Las decisiones se representaran por un rombo que designa una doble entrada.
2. Los estados por los que pasa el objeto, se representan con rectángulos de
puntas redondeadas.
3. Al realizar un almacenamiento en un diagrama se utiliza el símbolo de archivo.
UN I DAD ES
4. Los nodos inicial y final se representan igual que las actividades de inicio y fin
del diagrama de actividades.
5. Las transiciones entre estados se representan por flechas.
Opciones de respuesta: a) 2,4,5 b) 1,2,3 c) 2,3,4 d) 1,4,5
Escriba V si usted considera que es verdadero y F si lo considera falso a los S OL U CI ON AR I O

siguientes enunciados. (1 punto)
( ) Los Diagramas de flujo muestran la forma en que un grupo de objetos se

comunican (interactúan) entre sí a lo largo del tiempo.
( ) Un Diagrama de Secuencia consta de objetos, mensajes entre estos objetos y una
línea de vida del objeto representada por una línea vertical.
( ) En los diagramas de actividades las bifurcaciones condicionales se especifican con
un rombo colocando la condición de las ramas entre corchetes.
AN EXO S
( ) En los diagramas de flujo Las acciones concurrentes se dibujan naturalmente, con

dos barras gruesas, una para indicar el comienzo de la concurrencia.

Guía Didáctica
Unidad 4: UML Modelo conceptual
UML son las siglas de “Unified Modeling Language” o
“Lenguaje Unificado de Modelado”. Se trata de un estándar
que se ha adoptado a nivel internacional por numerosos
organismos y empresas para crear esquemas, diagramas y
documentación relativa a los desarrollos de software
BI BL I OG RA F ÍA
(programas informáticos).
“Antes de definir el modelo estático o de clases, es necesario definir el modelo

conceptual, el cual nos muestra los conceptos presentes en el dominio del problema.
Un concepto para este caso, en términos de POO, es un objeto del mundo real, es
OR I ENT A CI O NES
decir, es la representación de cosas del mundo real y NO de componentes de software.
En él no se definen operaciones (o métodos). En este modelo se pueden mostrar los
conceptos, los atributos de los conceptos (opcionalmente) y la relación o asociación
entre ellos. Informalmente podríamos decir que un concepto es una idea, cosa u
objeto. Para descubrirlos debemos analizar los sustantivos en las descripciones
P RO C ES O
textuales del dominio del problema, es decir, de la descripción del sistema, de los
requerimientos y de los Casos de Uso.”9
UN I DAD ES
S OL U CI ON AR I O
AN EXO S
9
http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro10/222_modelo_conceptual_de_uml.html

Guía Didáctica
BI BL I OG RA F ÍA
OR I ENT A CI O NES
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
4.1. Entidades
“Una entidad es cualquier concepto del mundo real con una existencia independiente.
AN EXO S
Puede ser un objeto con una existencia física (por ejemplo, una computadora o un
robot) o un objeto con una existencia conceptual (por ejemplo, un curso universitario).
Cada entidad posee un conjunto de atributos que describen sus propiedades.

Guía Didáctica
Nota: No existe una notación estándar para representar diagramas ER. Diferentes
textos sobre este tema usan distintas notaciones. Los conceptos y notaciones para los
diagramas ER que usa Umbrello se han tomado del libro Fundamentos de sistemas de
bases de datos, 4ª edición, de Elmasri R. y Navathe S. (2004), Addison Wesley.
En un diagrama ER, las entidades se representan mediante rectángulos, con el nombre
BI BL I OG RA F ÍA
de la entidad en la parte superior. También pueden mostrar los atributos de la entidad
en otro «compartimento» dentro del rectángulo.
OR I ENT A CI O NES
Representación visual de una entidad en un diagrama ER
Atributos de las entidades
P RO C ES O
En los diagramas ER, los atributos de las identidades se muestran con su nombre en
un compartimento distinto de la entidad a la que pertenecen.
UN I DAD ES
Restricciones
Las restricciones de los diagramas ER indican las restricciones de los datos en el

esquema de información.
S OL U CI ON AR I O
Existen cuatro tipos de restricciones que permite usar Umbrello:
 Clave primaria: El conjunto de atributos declarado como clave primaria es único

para la entidad. Solo puede existir una clave primaria en una entidad y ninguno
de los atributos que la constituyen puede ser nulo.
AN EXO S
 Clave única: El conjunto de atributos declarado como clave única es único para
la entidad. Pueden existir varias restricciones únicas en una entidad. Los

Guía Didáctica
atributos que la constituyen pueden ser nulos. Las claves únicas y las claves
primarias identifican unívocamente una fila de una tabla (entidad).
 Clave externa: Una clave externa es una restricción referencial entre dos tablas.
La clave externa identifica a una columna o a un conjunto de columnas de una
tabla que hacen referencia a una columna o a un conjunto de columnas de otra
tabla. Las columnas de la tabla referenciada deben formar una clave primaria o
BI BL I OG RA F ÍA
una clave única.
 Restricción de comprobación: Una restricción de comprobación (también

conocida como «restricción de comprobación de tabla») es una condición que
define datos válidos cuando se añade o se actualiza una entrada de un a tabla
de una base de datos relacional. Se aplica una restricción de comprobación a
OR I ENT A CI O NES
cada rila de la tabla. La restricción debe ser un predicado. Se puede referir a
una o a varias columnas de la tabla. Ejemplo: precio >= 0”10
4.2. Atributos
P RO C ES O
Un atributo es una característica o propiedad de una clase de la cual se puede extraer
un valor. Los valores de los atributos definen el estado de una instancia y son los que
la hacen diferente de otras instancias.
UN I DAD ES
Un atributo tiene:
 Un nombre: es obligatorio. En el modelado conceptual los nombres han de ser

significativos ya que lo debe entender el cliente. Evita usar versiones acotadas S OL U CI ON AR I O
(ya las usaremos en el diseño técnico). Por ejemplo, es mejor escribir Fecha de
nacimiento o bien fechaNacimiento en vez de f_nac.
 Un tipo de datos: Es el tipo de datos al que pertenece el atributo. Puede ser un

tipo primitivo (String, Integer, Date, etc.), un tipo especial (los veremos en el
próximo capítulo) o una instancia de otra clase. Este último caso equivale a una
AN EXO S
asociación, así que se recomienda evitarlo y trazar una línea de asociación.
10
https://docs.kde.org/trunk5/es/kdesdk/umbrello/uml-elements.html

Guía Didáctica
 Una multiplicidad. Es el número posible de valores que admite el atributo. Se

especifica entre corchetes y dentro se explicita el rango usando la
notación (M..N); M y N son los valores mínimo y máximo. Si no especificamos
ninguna multiplicidad, por defecto es 1..1 (sólo admite valor único y es
obligatorio). A parte de la anterior, las multiplicidades más comunes son:
o 0..1. El valor del atributo es único y puede ser nulo.
BI BL I OG RA F ÍA
o 0..* y 1..*. El atributo es multiocurrente. En el primer caso no es
necesaria la existencia de valor y en el segundo, sí.
Observa los siguientes ejemplos de declaración de atributos:
OR I ENT A CI O NES
apellidos Sólo hemos especificado el nombre
fechaNacimiento: Date fechaNacimiento es una fecha y obligatoria

(nombre y tipo)
P RO C ES O
teléfonos: Integer[*] teléfonos es un listado de varios números enteros
(nombre, tipo y multiplicidad)
dirección[0..1] Sólo hemos especificado el nombre
UN I DAD ES
Y ahora, dos ejemplos usando la definición de clases. El primero, sin detalles de
atributos; y el segundo, con ellos.
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
4.3. Estándares de diseño de interfaces
PRINCIPIOS Y ESTÁNDARES DE INTERFAZ.
Los siguientes principios son fundamentales para el diseño e implementación de

interfaces gráficas efectivas, ya sea interfaces GUI de escritorios o para la web.
BI BL I OG RA F ÍA
Muchas aplicaciones web obvian algunos de los principios de los que hablaremos, y
dichos principios no cambian aunque sea una aplicación web, todo lo contrario,
respetarlos puede llegar a ser aún más importante y necesario.
Las interfaces gráficas efectivas son visualmente comprensibles y permiten errores por
OR I ENT A CI O NES
parte del usuario, dándole una sensación de control. Los usuarios ven rápidamente el
alcance de las opciones y comprenden como obtener sus metas y realizar su trabajo.
Dichas interfaces ocultan al usuario el funcionamiento interno del sistema. El trabajo

se va guardando constantemente brindando una opción de deshacer en todo momento
cualquier acción que se haya hecho. Las aplicaciones y servicios efectivos realizan el
P RO C ES O
máximo trabajo requiriendo la mínima información del usuario.
Anticiparse.
UN I DAD ES
Una buena aplicación intentará anticiparse a las necesidades y deseos de los usuarios.
No esperes que el usuario busque o recuerde información o herramientas. Muestra al
usuario toda la información y herramientas necesarias para cada etapa en su trabajo.
S OL U CI ON AR I O
Autonomía.
El ordenador, la interfaz y el entorno de la tarea pertenecen al usuario, pero no

podemos abandonarlo.
Ante una interface, al usuario hay que darle “cuerda” para que investigue y sienta que
AN EXO S
tiene el control del sistema. No obstante, hay que tener en cuenta que los adultos nos

Guía Didáctica
sentimos más cómodos en un entorno que no sea ni muy restrictivo, ni demasiado

grande, un entorno explorable pero no peligroso.
Mantén informado al usuario del estado del sistema.
No existe autonomía en ausencia de control; y el control no se puede tener sin

información suficiente. Comunicar el estado es fundamental para que el usuario
BI BL I OG RA F ÍA
responda apropiadamente con la información disponible.
Ejemplo: los trabajadores sin información del estado del sistema, tienden a
mantenerse bajo presión durante cortos periodos de tiempo hasta que el trabajo se
termina. Un estrés y fatiga innecesarios por lo que cuando venga la siguiente carga de
trabajo, puede que los trabajadores no estén en las mejores condiciones físicas y
OR I ENT A CI O NES
mentales.
Los usuarios no tienen que buscar la información de estado. De un vistazo deberían

ser capaces de hacerse una idea aproximada del estado del sistema. La información
de estado pude ser bastante sutil: el icono de la bandeja de entrada puede mostrarse
vacía, medio llena o hasta los topes, por ejemplo. Sin embargo, no es conveniente
P RO C ES O
abusar: En Mac se utilizó durante años un icono de la papelera que parecía que iba a
estallar en cualquier momento, aunque sólo tuviese un documento. Los usuarios
adquirieron la costumbre de vaciar la papelera apenas contuviese un documento,
UN I DAD ES
convirtieron un proceso de un paso en uno de dos (primero llevamos el documento a
la papelera, luego lo vaciamos). Esto tuvo el efecto negativo de reducir una de las
funciones básicas de la papelera: la posibilidad de deshacer la acción.
S OL U CI ON AR I O
Otro ejemplo posible de información de estado sería el de un una caja de búsquedas
que cambiase de color para indicar si la búsqueda está todavía en marcha o si ya ha
terminado, con demasiados resultados, con muy pocos o justos con lo necesario.
Mantén la información de estado fácilmente visible y actualizado.
Los usuarios no tienen que buscar la información de estado. De un vistazo deberían

AN EXO S
ser capaces de hacerse una idea aproximada del estado del sistema. La información
de estado pude ser bastante sutil: el icono de la bandeja de entrada puede mostrarse

Guía Didáctica
vacía, medio llena o hasta los topes, por ejemplo. Sin embargo, no es conveniente
abusar: En Mac se utilizó durante años un icono de la papelera que parecía que iba a
estallar en cualquier momento, aunque sólo tuviese un documento.
Los usuarios adquirieron la costumbre de vaciar la papelera apenas contuviese un

documento, convirtieron un proceso de un paso en uno de dos (primero llevamos el
documento a la papelera, luego lo vaciamos). Esto tuvo el efecto negativo de reducir
BI BL I OG RA F ÍA
una de las funciones básicas de la papelera: la posibilidad de deshacer la acción.
Otro ejemplo posible de información de estado sería el de un una caja de búsquedas

que cambiase de color para indicar si la búsqueda está todavía en marcha o si ya ha
terminado, con demasiados resultados, con muy pocos o justos con lo necesario.
OR I ENT A CI O NES
Daltonismo.
Si utilizas el color para transmitir información debes utilizar otros elementos
complementarios para la gente con daltonismo.
Aproximadamente un 10% de los hombres adultos sufren daltonismo.
P RO C ES O
Las pistas secundarias pueden consistir en distintos tonos de gris, gráficos
complementarios o etiquetas de texto.
UN I DAD ES
Coherencia.
Los siguientes principios, vistos en su conjunto, dan al diseñador de interfaces mucho
margen para la evolución de un producto sin perjudicar los aspectos más importantes
para el usuario. S OL U CI ON AR I O
Niveles de Coherencia:
Mantener una coherencia estricta depende del caso. En la siguiente lista aparecen los
elementos de la interfaz ordenados por su necesidad de coherencia, de mayor a menor.
Mucha gente asume que el orden de los cinco primeros elementos es justo el contrario,
AN EXO S
dando lugar a aplicaciones que se parecen pero que se comportan de forma

impredecible y totalmente distinta.

Guía Didáctica
Interpretación del comportamiento del usuario. Ejemplo: los atajos de teclado deben
funcionar siempre igual.
 Estructuras invisibles.
 Estructuras visibles pequeñas.
 El aspecto general de una aplicación o servicio (presentación, elementos de
diseño).
BI BL I OG RA F ÍA
 Una suite de productos.
Coherencia interna.
Coherencia con la plataforma
OR I ENT A CI O NES
Las estructuras invisibles se refieren a objetos como al botón izquierdo de Word, que
tiene toda clase de propiedades y comportamientos, si es que alguna vez los
descubres. A veces aparece y otras no, depende de tu versión de Windows; y si no
aparece, nunca estarás seguro de si está o no, dado que es invisible. Por eso es tan
P RO C ES O
importante la coherencia en los objetos invisibles.
Otros objetos en la interfaz se consideran visibles, pero muchas veces no parecen

controles: es posible que el usuario nunca descubra que se pueden interactuar con
UN I DAD ES
ellos. Su significado, si decides utilizarlos, debería ser muy claro. "Por ejemplo,
podemos hacer clic y arrastrar en una esquina de un ventana activa para cambiar su
tamaño" pero no "a veces podemos hacer clic y arrastrar pero otras veces no".
Las pequeñas estructuras visibles se refieren a iconos, flechas de desplazamiento, etc. S OL U CI ON AR I O
Es necesario mantener su consistencia si no queremos que la gente se pase el día

averiguando cómo se hace qué con estos objetos. Su posición en pantalla es
ligeramente menos importante. Si tiene sentido estandarizar la posición, hazlo.
Incoherencia: es tan importante ser visualmente incoherente con los objetos que se
comportan de forma distinta, como ser coherente con los que se comportan de igual
AN EXO S
manera.

Guía Didáctica
Evita la uniformidad. Haz que los objetos que se comportan de forma distinta parezcan
distintos.
La coherencia más importante es aquella que espera el usuario. La única manera de
comprobar las expectativas del usuario es hacer pruebas con ellos.
Valores por defecto.
BI BL I OG RA F ÍA
Los valores por defecto deberían ser poder descartados con facilidad y rapidez. Los
campos de texto con valores por defecto deben aparecer seleccionados, para que el
usuario sólo tenga que teclear y no seleccionar todo, borrar y escribir.
Los valores por defecto deben tener sentido.
OR I ENT A CI O NES
No uses la palabra "por defecto" en una aplicación o servicio. Utiliza "estándar", "Usar
valores habituales", "Restablecer valores iniciales" o términos más específicos que
describan lo que sucederá.
P RO C ES O
MODOS DE USO, NAVEGACIÓN, TÉCNICAS DE CODIFICACIÓN Y DISEÑO
VISUAL. (COLOR, ÍCONOS, FONDO DE LETRAS).
UN I DAD ES
Consideraciones de Diseño.
Existen tres factores que pueden considerarse para el diseño de una interfaz de usuario
correcta: factores de desarrollo, factores de viabilidad y factores de aceptación.
S OL U CI ON AR I O
Los factores de desarrollo ayudan a mejorar la comunicación visual. Esto incluye
toolkits y librerías de componentes, soportes para un rápido prototipado, y
adaptabilidad.
Los factores de viabilidad tienen en cuenta factores humanos y expresan una fuerte
identidad visual. Esto incluye: habilidades humanas, la identidad del producto, un claro
AN EXO S
modelo conceptual, y múltiples representaciones.

Como factores de aceptación están la política de la corporación, los mercados
internacionales, y la documentación y entrenamiento.

Guía Didáctica
El Lenguaje Visible.
El Lenguaje Visible se refiere a todas las técnicas gráficas usadas para comunicar el
mensaje o contexto. Esto incluye:
- Disposición o Layout: formatos, proporciones, y mallas (grids); organización: ya

sea 2D y 3D.
Tipografía: selección de tipos de letra y estilos, incluyendo la anchura fija y
BI BL I OG RA F ÍA
-
variable.
- Color y Textura: color, textura y luminancia aportan información compleja y

realidad pictorial.
Imágenes: signos, iconos y símbolos, desde lo fotográficamente real a lo
OR I ENT A CI O NES
-
abstracto.
- Animación: un display dinámico o cinético: muy importante en la utilización de
imágenes relacionadas con el vídeo.
- Secuenciamiento: el aproximamiento total del secuenciamiento visual al
P RO C ES O
secuenciamiento lógico.
- Sonido: abstracto, vocal, concreto, o musical.
- Identidad Visual: las reglas adicionales y únicas que proporcionan consistencia
UN I DAD ES
de conjunto a una interfaz de usuario.
Principios del Diseño de interfaces de usuario.

S OL U CI ON AR I O
Existen tres principios fundamentales relacionados en el uso del lenguaje visible:
- Organizar: proveer al usuario de una estructura conceptual clara y consistente.

- Economizar: hacer lo máximo con la menor cantidad de elementos.
- Comunicar: ajustar la presentación a las capacidades del usuario.
AN EXO S
Organizar.
Consistencia, disposición de la pantalla, relaciones y navegabilidad son importantes
conceptos de organización.

Guía Didáctica
Consistencia.
Existen 4 visiones de la consistencia: consistencia interna, consistencia externa,
consistencia del mundo real y cuando no hay consistencia.
La primera visión, la consistencia interna, afirma que las mismas convenciones y reglas
deben ser aplicadas a todos los elementos de la interfaz gráfica de usuario.
Los mismos tipos de elementos se muestran en los mismos lugares.
BI BL I OG RA F ÍA
Aquellos con diferentes tipos de comportamiento tienen su propia apariencia especial.
La consistencia externa afirma que las plataformas existentes y convenciones

culturales deben ser utilizadas y aplicadas en las interfaces gráficas de usuario.
OR I ENT A CI O NES
Consistencia externa para iconos de herramientas de texto.
Estos iconos son de diferentes aplicaciones, pero generalmente tienen el mismo
significado.
Consistencia del mundo real.
La consistencia del mundo real afirma que las convenciones y reglas deben ser
P RO C ES O
consistentes y consecuentes con las experiencias del mundo real, y las observaciones
y percepciones del usuario.
El último punto, la innovación, trata con la carencia de consistencia. Desviarse de las
UN I DAD ES
convenciones existentes sólo debe hacerse cuando proporciona un CLARO beneficio al
usuario.
Disposición de la pantalla (Layout). S OL U CI ON AR I O
Hay tres formas para diseñar una disposición espacial de la pantalla: usar una
estructura de malla (grid), estandarizar la disposición de la pantalla, y usar los
elementos relacionados con grupos.
Una estructura de malla puede ayudar a colocar menús, paneles de diálogo o de

AN EXO S
control. Generalmente el máximo número de divisiones horizontales o verticales se

ajusta a la expresión 7 +/- 2. Esto ayudará a hacer la pantalla más inteligible y menos
saturada.

Guía Didáctica
Relaciones.
Conectar los items relacionados y disociar los items independientes mejora
sensiblemente la organización visual.
Relaciones: Izquierda: La localización, forma y valor pueden todas ellas crear

relaciones que es posible sean inapropiadas.
Derecha: relaciones claras, consistentes, apropiadas y fuertes.
BI BL I OG RA F ÍA
Navegabilidad.
Existen tres técnicas importantes de navegabilidad:
Proveer un foco inicial para la atención del usuario.
OR I ENT A CI O NES
-
- Dirigir la atención a los items importantes, secundarios o periféricos.
- Asistir la navegación a través del material.
Navegabilidad:
Izquierda: diseño pobre.
P RO C ES O
Derecha: diseño mejorado: la disposición espacial y el color ayudan a centrar la
atención del usuario a las áreas más importantes.
Economizar.
UN I DAD ES
Hay que considerar 4 grandes factores: simplicidad, claridad, singularidad y énfasis.
Simplicidad.
S OL U CI ON AR I O
La simplicidad incluye únicamente los elementos que son más importantes para la
comunicación.
Debería producir también la menor obstrucción posible.
Diseño complicado y diseño más simple.

AN EXO S
Claridad.
Iconos ambiguos y claros.

Guía Didáctica
Todos los componentes deberían ser diseñados para que su significado no sea
ambiguo, que no lleve al equívoco.
Singularidad.
Las propiedades de los elementos necesarios deben ser características singulares.
BI BL I OG RA F ÍA
Énfasis.
Los elementos más importantes deben ser fácilmente percibidos.
Se debe restar énfasis a los elementos no críticos y minimizarlos para no ocultar
información crítica.
OR I ENT A CI O NES
Comunicar.
La interfaz gráfica de usuario debe mantener un balance entre legibilidad, tipografía,
simbolismo, múltiples vistas, y color o textura, para comunicar adecuadamente.
P RO C ES O
Legibilidad.
Texto ilegible y legible.
La pantalla debe ser fácil de identificar e interpretar, además de atractiva y agradable.
UN I DAD ES
Tipografía.
Incluye características de elementos individuales (tipos de letra y estilos) y sus
agrupamientos (técnicas de estilo). S OL U CI ON AR I O
Se deberá usar un número reducido de tipos de letra que serán legibles, claros y
singulares (por ejemplo, para distinguir diferentes clases de información).
Recomendaciones:
AN EXO S
- Un máximo de 3 tipos de letra en un máximo de 3 tamaños de puntos.

- Un máximo de 40-60 caracteres por línea de texto.

Guía Didáctica
- Ajustar el texto a la izquierda y los números a la derecha. En listas, usar el

centrado de texto.
 Tipos de letra y estilos recomendados
- Usar mayúsculas y minúsculas siempre que sea posible.
Múltiples vistas.
Proveer de múltiples perspectivas en la pantalla de estructuras y procesos complejos.
BI BL I OG RA F ÍA
Hacer uso de estas múltiples vistas:
- Múltiples formas de representación.

- Múltiples niveles de abstracción.
Vistas alternativas simultaneas.
OR I ENT A CI O NES
-
- Conexiones y referencias cruzadas.
- Metadatos, metatexto y metagráficos.
- Múltiples vistas verbales y visuales.
Color.
P RO C ES O
El color es uno de los más complejos elementos a la hora de intentar diseñar una
interfaz gráfica correcta. Puede ser una potente herramienta de comunicación usado
correctamente. Los colores pueden ser combinados para tomar un sentido visual.
UN I DAD ES
Ventajas en el uso del color para facilitar la comunicación:
- Enfatizar la información importante. S OL U CI ON AR I O

- Identificar subsistemas de estructuras.
- Portar objetos naturales de un modo realista.
- Portar tiempo y progreso.
- Reducir los errores de interpretación.
- Añadir dimensiones a la codificación.
AN EXO S
- Incrementar la comprensibilidad.
- Incrementar la credibilidad y atractivo.

Guía Didáctica
Cuando el color es usado correctamente la gente suele aprender más.
La memoria para la información en color parece ser mucho más capaz que para la
información presentada en blanco y negro.
También existen desventajas en el uso del color:

- Requiere un equipamiento más complicado y costoso.
BI BL I OG RA F ÍA
- La mayoría no se acomoda a la visión de los daltónicos.
- Algunos colores pueden potencialmente causar molestias visuales y
postimágenes.
- Puede contribuir a asociaciones erróneas a causa de diferencias
multidisciplinarias o multiculturales.
OR I ENT A CI O NES
Términos y conceptos relacionados con el color.
Las discusiones sobre el color suelen ser confusas porque científicos, artistas,
diseñadores, programadores y profesionales del marketing describen el color de
P RO C ES O
diferentes formas.
Algunas de estas formas difieren del rojo, verde y azul que basan el sistema de color
UN I DAD ES
“RGB”, familiar para los usuarios de periféricos con tubos de rayos catódicos (CRTs).
Los siguientes términos aclaran conceptos sobre esta manera de entender el color:
Matiz (Hue) es la composición espectral de longitud de onda que produce percepciones S OL U CI ON AR I O
de ser azul, naranja, verde, etc. por ejemplo.
Valor (Value) es la cantidad relativa de claridad u oscuridad del color en un rango

desde el negro al blanco (también llamado intensidad).
AN EXO S
Saturación (Chroma) es la pureza del color en una escala desde el gris a la variante
mas viva del color percibido.

Guía Didáctica
Brillo (Brightness) es la cantidad de energía luminosa al crear el color.

Principios de diseño del color.
Los tres principios básicos de diseño pueden aplicarse también al color: organización
del color, economía del color y comunicación del color.
BI BL I OG RA F ÍA
Organización del color.
La organización del color influye en la consistencia de la organización. El color debe

emplearse para agrupar los items relacionados.
OR I ENT A CI O NES
Debe aplicarse una organización de color consistente tanto a las pantallas, como a la
documentación y a los materiales de entrenamiento.
Los colores similares infieren similitud en los objetos. Se debe mirar la completud y
consistencia al agrupar objetos con el mismo color.
P RO C ES O
Una vez se establece una codificación del color, esta debe ser usada en toda la interfaz
gráfica así como en la documentación y publicaciones relacionadas.
UN I DAD ES
Economía del color.
S OL U CI ON AR I O
El segundo principio del color, la economía del color, sugiere usar un máximo de 5 +/-
2 colores cuando el significado tiene que ser recordado.
La idea fundamental es usar color para aumentar la información proporcionada en

blanco y negro (por ejemplo, diseñar la interfaz para que funcione bien primero en
AN EXO S
blanco y negro).

Guía Didáctica
Comunicación del color.
El énfasis del color sugiere usar fuertes contrastes en valor y tono para centrar la
atención del usuario en la información más importante. Cuando demasiadas figuras o
campos del fondo compiten por la atención del usuario se produce cierta confusión. La
jerarquía de los estados sobreiluminado, neutro e infrailuminado para todas las áreas
de la pantalla deben ser cuidadosamente diseñadas para proporcionar la máxima
BI BL I OG RA F ÍA
sencillez y claridad.
La comunicación en color pugna con la legibilidad, incluyendo usar un color apropiado

para las áreas central y periférica del campo visual. Las combinaciones entre colores
pueden producir influencias entre ellos y cambios en la elección de los mismos.
OR I ENT A CI O NES
Es aconsejable que el color rojo y el verde no sean usados en la periferia del campo
visual sino en el centro. Si son usados en la periferia, es necesario un medio para
captar la atención del usuario, como un cambio de tamaño o el parpadeo, por ejemplo.
P RO C ES O
El negro, azul, blanco y amarillo son apropiados para la periferia del campo visual,
donde la retina es más sensitiva a ellos.
UN I DAD ES
Si se produce un cambio en el tamaño de los elementos coloreados se debe tener en
cuenta que nuestra percepción sobre su luminancia o tono puede cambiar, y tomar las
medidas oportunas.
Es preciso usar colores que difieran tanto en valor como en tono. Las combinaciones S OL U CI ON AR I O
rojo/verde, azul/amarillo, verde/azul, y rojo/azul deben ser evitadas excepto si se
necesita un efecto visual especial. Pueden crear vibraciones, ilusiones, sombras y
postimágenes.
Para situaciones con poca iluminación se recomienda texto claro, líneas finas y formas
AN EXO S
pequeñas o medianas sobre un fondo oscuro; para situaciones con iluminación

abundante, por el contrario, texto oscuro (azul o negro), líneas finas y formas

Guía Didáctica
pequeñas sobre fondo claro. Estas combinaciones son para presentaciones con
transparencias, videos, papel o estaciones de trabajo.
Simbolismo del color.
La importancia del color es comunicar. Los códigos de colores deben respetar el uso
profesional y cultural ya existente de determinados colores. Las connotaciones varían
BI BL I OG RA F ÍA
fuertemente respecto a los diferentes tipos de usuario, especialmente cuando son de
diferentes culturas. Las connotaciones del color deben ser usadas con sumo cuidado.
Por ejemplo: los buzones de correos son azules en Estados Unidos, rojo brillante en
Inglaterra y amarillos en Grecia. Si se usa un icono gráfico para representar el correo
OR I ENT A CI O NES
electrónico, es conveniente adecuar su color al país para mejorar la comunicación.
Características del color en una interfaz gráfica.
Consideremos cuál es la razón última para aprovechar las ventajas del color: ofrecer
al usuario la misma información pero de una forma más persuasiva o amistosa,
P RO C ES O
incrementando su interés. Por lo tanto, la principal utilidad que va a tener el color en
las pantallas de nuestra interfaz gráfica será la de resaltar las informaciones que se
consideren más importantes en detrimento del resto, para así poder identificar
rápidamente los datos más relevantes, que serán aquellos a los que se presta atención
UN I DAD ES
prioritariamente.
Por otra parte, un buen manejo del color nos lleva a agrupar los diferentes elementos
de la pantalla en conjuntos, que quedarán asociados aunque estén distanciados S OL U CI ON AR I O
espacialmente, y a distribuir de forma clara los que deben diferenciarse. Este punto de
vista de asociaciones y divisiones se aplica tanto a los componentes físicos de la
pantalla como a las ideas y procesos inherentes a ellos. Por ejemplo, se puede emplear
la misma gama de colores para señalar una secuencia de procesos determinada sin
necesidad de numeraciones o indicaciones directas. También es muy interesante
AN EXO S
cuando tenemos información dinámica en el tiempo, ya que se altera el color cuando

cambia el estado de la información.

Guía Didáctica
Debemos tener en cuenta que los objetos verdes o azules parecen más grandes que
aquellos que son rojos o amarillos. También consideraremos que los colores fríos hacen
aparecer al objeto como mucho más plano que los calientes, que producen efecto de
relieve.
Pero, como se ha enunciado brevemente antes, no se puede emplear cualquier color

en cualquier momento. Es necesario tener un criterio de distribución decidido desde el
BI BL I OG RA F ÍA
momento en que se conoce que se van a utilizar colores en nuestras pantallas.
Uno de los errores más habituales a la hora de diseñar una pantalla es la de, intentando
aprovechar la posibilidad de usar el color, acabar abusando de él. Esto puede ocurrir
cuando en la aplicación se presentan, por ejemplo, diferente gama de colores, lo que
OR I ENT A CI O NES
provoca confusión a la persona que va a manejarla, ya que acaba preocupándose más
de adaptar su vista al continuo cambio de color que al contenido de la información.
También hay que hacer hincapié en evitar las combinaciones que puedan provocar
connotaciones culturales negativas, que pueden llegar a herir susceptibilidades.
P RO C ES O
Veamos un ejemplo de combinación errónea indiscriminada en la siguiente imagen. La
pantalla que se ha elegido pertenece a una aplicación sobre historiales clínicos.
Dispone de dos bloques de información: los datos personales del paciente y la relación
UN I DAD ES
de las citas anteriores a la actual, cada uno de ellos en un marco (frame). Realmente
son dos informaciones que, aunque independientes, mantienen la asociación de
pertenecer a la misma persona. Sin embargo, el diseñador ha decidido distinguir
claramente las diferencias al establecer los colores verde y rojo como fondo para estos S OL U CI ON AR I O
marcos. La conjunción de dos tonos tan distintos entre sí invita a pensar que ambos
conceptos son completamente exclusivos, aunque en la realidad no sea el caso, ya que
tanto los datos personales como las citas anteriores se refieren al mismo paciente.
Combinación errónea indiscriminada.

AN EXO S
Otro error en el diseño de esta pantalla ha sido la de utilizar unas etiquetas con un
color muy parecido en el fondo. Ocurre en los cuadros de texto de los datos personales.

Guía Didáctica
El azul es muy semejante al verde y por lo tanto no permite una nítida delimitación.
Obliga a forzar los ojos, lo que desde luego agota la vista del usuario en muy poco
tiempo. Además, cuando se utilizan varias tonalidades del mismo color, como es el
caso, puede incluso provocar confusión, o dar la impresión de que algunos datos
físicamente cercanos estén conceptualmente distantes.
Por último, veamos la diferencia entre un texto de color oscuro sobre fondo claro
BI BL I OG RA F ÍA
(como suele ser lo habitual) y al revés. La primera situación la tenemos en los datos
personales y la segunda en las citas anteriores. Como se puede observar, es mucho
más fácil trabajar con situaciones como la del marco superior.
En esta imagen se ha representado la misma pantalla pero con colores más adecuados.
OR I ENT A CI O NES
Pantalla con colores adecuados.
Este problema de atropello de los colores no es exclusivo de cada pantalla considerada
P RO C ES O
de una manera singular. Es posible que se estudie cada pantalla de forma individual y
nos parezca que las combinaciones han sido las adecuadas, que el efecto óptico que
producen es armonioso y no son susceptibles de provocar efectos negativos en el ojo
del usuario ni desviaciones desproporcionadas de atención. Esto es debido a que a
UN I DAD ES
veces el problema se presenta porque la combinación errónea se compone entre
pantallas.
No es de recibo que a lo largo de la aplicación el usuario pueda ver que el predominio S OL U CI ON AR I O
de los tonos en tiempo de ejecución va variando sin ningún orden lógico y que lleguen,
incluso, a provocar interferencias entre las pantallas. Por supuesto, hay que intentar
mantener una coherencia, buscando siempre transmitir una sensación de bloque
homogéneo durante toda la aplicación. Si, por ejemplo, los fondos de todas las
pantallas no pertenecen a la misma gama de color, provocará sin duda confusión a la
AN EXO S
persona que en este momento observa el monitor de su ordenador, a pesar de que

pantalla a pantalla la composición de tonalidades haya sido la adecuada. Desde luego,

Guía Didáctica
el problema de la uniformidad es extrapolable al resto de características de nuestra

aplicación. El usuario debe encontrarse en un entorno homogéneo para poder trabajar.
La anterior reflexión nos lleva a establecer que cualquier medida tomada en cuanto al
color para incrementar los aspectos ergonómicos de nuestras aplicaciones deben ser
estudiadas tanto a nivel individual de cada pantalla como a nivel global de la aplicación
completa.
BI BL I OG RA F ÍA
Combinaciones entre colores.
En el siguiente cuadro vemos ciertas combinaciones entre colores que pueden

considerarse correctas e incorrectas. Por ejemplo, los colores claros quedan bien
integrados si se unen con colores oscuros, ya que hay un buen contraste, pero en
OR I ENT A CI O NES
determinados casos se pueden combinar con tonos también claros, excepto si son
demasiado parecidos, como ocurre con el azul y el verde. En general, digamos que
tanto un fondo claro con texto y figuras oscuras es tan admisible como un fondo oscuro
con texto y figuras claros, pero en el primer caso se gana en legibilidad.
P RO C ES O
Combinaciones de colores.
En la combinación de colores oscuros hay que tener más cuidado, porque es más fácil
confundirse y que se unan colores que hagan un mal efecto. Tonos oscuros como el
UN I DAD ES
rojo y el azul presentados en una misma pantalla obligan al usuario a un esfuerzo de
acomodación óptica innecesario.
Cuando pensamos en qué colores debemos emplear en nuestras pantallas debemos S OL U CI ON AR I O
reparar en la influencia que un determinado color puede llegar a tener sobre el resto.
Los colores provocan sensaciones cuando se abandona su visión y se pasa sin
transición a observar otro. Por ejemplo, si estamos viendo el color azul y pasamos a
ver un amarillo, éste se verá brillante. Si no se pasa anteriormente por el azul, el
amarillo se verá mucho más pálido y mate.
AN EXO S

Guía Didáctica
En general, los colores tienen unas propiedades psicológicas que actúan sobre nuestro
subconsciente. Existen algunos efectos de la yuxtaposición entre colores que se
admiten de forma general. Por ejemplo, el color amarillo, que como hemos dicho es
alegre y brillante, pierde toda su fuerza cuando se combina con el blanco. Para rebajar
el excesivo dinamismo que evoca el naranja no hay nada como mezclarlo con el blanco.
Sin embargo, combinado con el rojo forma un color pardo demasiado denso. El violeta
combina muy bien con el rojo, porque da más prestancia a la imagen noble y altiva
BI BL I OG RA F ÍA
del violeta, pero si se mezcla con el blanco resulta cursi.
Veamos ciertas relaciones que se deben considerar a la hora de seleccionar la gama

de colores de nuestras pantallas:
Un objeto pequeño parecerá aún más pequeño si se coloca cerca de una
OR I ENT A CI O NES
-
superficie grande.
- Un color claro parecerá más claro sobre un fondo oscuro que sobre un fondo
claro.
- Un color llama más la atención si se encuentra sobre un color mezclado que si
está sobre un color vivo.
P RO C ES O
- Un tono frío parecerá más frío cuanto más cálido sea el color sobre el que
aparece.
- Cada color muestra más claramente sus características si se coloca cercano a
UN I DAD ES
su complementario.
Finalmente, una breve mención a un aspecto muy interesante de cara a obtener

delimitaciones más finas en nuestros diseños: la escala de grises. Muchas veces es S OL U CI ON AR I O
más interesante jugar con los diferentes grises que mezclar otros colores, debido a
que el ojo humano percibe con más dificultad los pequeños detalles cuando se emplea
el color, y sin embargo, la combinación de varios grises permite la discriminación de
los elementos de manera más eficaz y agradable a la vista.
AN EXO S
Además, se le puede añadir azul para suavizar las posibles connotaciones negativas
que se comentaban anteriormente.

Guía Didáctica
En definitiva, cuando estamos hablando se colores es mejor pecar de prudentes antes

que arriesgarnos a que se provoque una dispersión de la atención por parte del
usuario. Pero, con una pequeña dedicación, un proyecto que utilice una agrupación
bien estudiada de colores va a mejorar claramente el acabado final, enriqueciéndolo
de una forma muy interesante.
Guía de uso del color en el diseño de GUIs.
BI BL I OG RA F ÍA
Recomendaciones.
1.- Usar un máximo de cinco, más menos dos colores. Cuatro colores distintos son
apropiados. Permite mayor sitio adicional en la memoria a corto plazo (memoria de
trabajo). Los ordenadores pueden proporcionar alrededor de 16 millones de colores,
OR I ENT A CI O NES
pero los humanos sólo pueden discriminar entre 7,5 millones de colores.
2.- Usar colores centrales y periféricos de forma apropiada. Usar el color azul para
áreas grandes, no para detalles o texto. El azul es apropiado para fondos de
transparencias y pantallas. Usar el rojo y el verde para captar la atención es una buena
P RO C ES O
medida, el campo visual se adapta fácilmente a esto.
3.- Usar el mismo color para agrupar elementos relacionados. La ciencia cognitiva ha
UN I DAD ES
avanzado en la noción de preparar y el proceso preatento. En este contexto, puedes
preparar al usuario para eventos relacionados usando un código de color común. Un
grupo de imágenes sucesivas puede mostrarse para relacionarse usando el mismo
color. Colores similares pueden evocar significados similares. Es preciso mantener el S OL U CI ON AR I O
color de fondo a no ser que exista una poderosa razón, por el mismo motivo.
4.- Usar un código de formas redundante de la misma manera que el color. Hace la
pantalla más impermeable a distorsiones en el color. Los cambios en la claridad del
ambiente pueden provocar cambios en el color percibido.
AN EXO S
5.- Evitar azul para el texto, líneas finas, y formas pequeñas. Nuestro sistema visual
no está únicamente diseñado para estímulos detallados y precisos en longitudes de

Guía Didáctica
onda corta. Sin embargo, el azul es muy aconsejable para el color de fondo, y se
percibe de manera idónea en la periferia del campo visual.
6.- Evitar que los colores adyacentes difieran únicamente en la cantidad de azul. Los
límites que difieran únicamente en la cantidad de azul se percibirán distintos.
7.- Evitar el rojo y el verde en la periferia de pantallas de gran escala. Debido a la
BI BL I OG RA F ÍA
insensibilidad de la periferia retinal al rojo y al verde, estos colores deben ser evitados
en la periferia en su forma saturada. El amarillo y el azul son buenos colores periféricos.
Tiempo de Respuesta y Retroalimentación.

En un sistema interactivo la retroalimentación visual (o feedback visual) es toda forma
OR I ENT A CI O NES
gráfica de comunicación que va del sistema en dirección al usuario. A pesar que la
retroalimentación visual es un componente de software difícil de desarrollar y difícil de
diseñar para guiar y hacer fácil la tarea del usuario, la Interacción Humano
Computadora (IHC) como el área de la Ingeniería de Software han propuesto hasta
hoy diversas técnicas para diseñar y desarrollar la retroalimentación visual sin tener
P RO C ES O
un consenso. Este trabajo preconiza los patrones de interacción como mecanismo
unificador entre la Ingeniera de Software y la IHC para diseñar la retroalimentación
visual en función del contexto de la tarea del usuario, y permitir a la vez la
UN I DAD ES
comunicación entre los especialista involucrados en su desarrollo. El presente trabajo
propone como solución un categorización de patrones de interacción que permitan
capturar la experiencia en el diseño de la retroalimentación visual de un SI en término
de los requerimientos del usuario. S OL U CI ON AR I O
Cuando se califica un sistema de interactivo no se puede dejar de lado el estudio de la

retroalimentación visual (visual feedback en inglés) que corresponde a la forma de
comunicación visual que va del sistema en dirección al usuario. La retroalimentación
tiene lugar en la interfaz de la aplicación en forma de expresiones de salida (e.gr.
AN EXO S
ventanas, iconos, mapas sensibles, mensajes de error), a fin de informar al usuario

sobre el efecto de sus acciones y sobre el estado actual del sistema. Para tal efecto,

Guía Didáctica
la retroalimentación debe ser informativa, comprensible y se debe efectuar en un

tiempo razonable a la tarea del usuario.
La retroalimentación visual es un factor que corresponde tanto a la ingeniería de
software como a la IHC pues contribuye respectivamente en la utilidad y la usabilidad
de un sistema interactivo. La utilidad concierne a la funcionalidad del software del
sistema caracterizándolo para lo que fue hecho. La usabilidad concierne a guiar
BI BL I OG RA F ÍA
pertinentemente al usuario en su tarea y hacer que el sistema se fácil de usar. A pesar
de la importancia de este doble rol de la retroalimentación y su presencia predominante
en los actuales Sistemas Interactivos (SI) desafortunadamente no se ha estudiado un
mecanismo de diseño que permita encontrar un compromiso entre los factores de
Ingeniera de Software y de la IHC. De lado de la IHC, se han propuesto un gran
OR I ENT A CI O NES
número de recomendaciones ergonómicas para la retroalimentación visual, pero sin
especificar “el como” diseñar y concretizar la retroalimentación visual en un SI.
Ahora bien, del lado de la Ingeniera de Software numerosas técnicas de programación

visual y herramientas CASE se han propuesto para desarrollar componente de software
P RO C ES O
para la retroalimentación visual. Sin embargo, estos Componentes son fuertemente
dependiente de los detalles de programación (e. gr. lenguaje de codificación y de la
caja de herramientas a utilizar).
UN I DAD ES
Trabajo Autónomo
Desarrollar los diagramas de casos de uso de un sistema ejemplo
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
Autoevaluación 4
UML son las siglas de: _________________________________________
Realice la representación visual de una entidad en un diagrama ER

esquema de información. ( )
BI BL I OG RA F ÍA
un valor ( )
Relacione el concepto con el tipo de diagrama al que hace referencia (1

punto)
a) Muestran el conjunto de estados por los cuales pasa un objeto
OR I ENT A CI O NES
b) Forma esquemática de representar ideas y conceptos en relación.
c) Modelar interacción entre objetos en un sistema según UML.
1. Diagrama de secuencia
2. Diagrama de flujo
3. Diagrama de estado
Opciones de respuesta: A) a2, b1, c3 B) a1, b2, c3

C) a3, b2, c1 D) a3, b1, c2
P RO C ES O
DESARROLLO PRÁCTICO:
Realice un DDE para verificar la validación de Password y Username en un SI.

Precondiciones: error_ingreso<3 caso contrario GUI solicita validación desde el
email registrado para ser validado, se realiza cambio de contraseña (#, carácter
UN I DAD ES
especial, M, n >= 8 caracteres) caso contrario el S.I espera 5 minutos y se bloquea la
cuenta. (2 puntos)
Identifique y explique a que hace referencia el siguiente DDE. (1 punto)
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
6. SOLUCIONARIO (Autoevaluaciones)
Autoevaluación 1
Escriba el acrónimo de los siguientes términos.
a). S/W: Software
b). RAM: Random Access Memory
c). H/W: Hardware
d). PC: Personal Computer
BI BL I OG RA F ÍA
siguiente interrogante.
El análisis y diseño de sistemas se refiere al trabajo de examinar la situación de una
empresa con el propósito de automatizar y mejorar procesos. ( V ).
Una con líneas las respuestas correctas: (1 punto)

a. Proceso objetivo y directo de
obtener información. Entrevista
OR I ENT A CI O NES
b. Se utiliza preguntas abiertas y/o cerradas
c. Se realiza a varias personas de la empresa
utilizando un cuestionario. Encuesta
d. La persona puede ampliarse en la respuesta
Complete:
• Uno delos objetivos de los S.I. es automatizar los procesos manuales de una
organización o empresa.
• Sistema de Información: Sistema cuya finalidad es procesar datos de entrada para
P RO C ES O
producir como salida información oportuna, relevante y confiable.
Complete la siguiente gráfica. (1 punto)
UN I DAD ES
Proceso
Unir con líneas los conceptos que corresponden (2 puntos)
Conjunto de actividades completamente informales
o rigurosamente estructuradas, que definen la
forma en la cual el trabajo es realizado dentro Procesos de negocio S OL U CI ON AR I O
de la organización y con su entorno.
Los Procesos de Negocio son diseñados para

producir un resultado usando los recursos
disponibles del negocio y que tiene un valor
para este.
El material, energía e información que es

consumida y producida por una organización.
AN EXO S
Incluyen a la gente, dinero, equipamiento, Recursos de negocio

tecnología y Know-How. También se incluyen agentes
externos a la organización como proveedores, clientes,
contratistas, autoridades reguladoras, y otros.

Guía Didáctica
Autoevaluación 2
De la siguiente lista cuales son tipos de sistemas informáticos
o Sistemas de automatización de oficinas (OAS)
o Sistemas de herramientas case (SCASE)
o Sistemas de información administrativa (MIS)
o Sistemas de procesamiento de transacciones (TPS)
o Sistemas de soporte para ejecutivos (ESS)
o Sistemas asistidos por la web
o Sistemas de trabajo colaborativo asistido por computadora
BI BL I OG RA F ÍA
siguiente interrogante. (1 punto)
Existen tipos de metodología de desarrollo.
La metodología del ciclo de vida del desarrollo de sistemas (SDLC),
metodologías ágiles y metodologías orientadas a objetos. ( V ).
Complete: Fases de Desarrollo de Sistemas (1 punto)
OR I ENT A CI O NES
1. Identificación de los problemas, oportunidades y objetivos
2. Determinación de los requerimientos de información
3. Análisis de las necesidades del sistema
4. Diseño del sistema recomendado
5. Desarrollo y documentación del software
6. Pruebas y mantenimiento del sistema
7. Implementación y evaluación del sistema
4. Complete: (2 puntos)
P RO C ES O
TPS: son sistemas de información transacciones que se desarrollaron para procesar
grandes cantidades de información para las empresas de negocios rutinarias, como
facturación e inventario.
5. Complete la siguiente tabla. (2 punto)
UN I DAD ES
ACRÓN SIGNIFICADO EN INGLÉS SIGNIFICADO EN
CASTELLANO
TPS Operations Processing Systems S. procesamiento d Transacciones
OAS Office Automation Systems S. de automatización de oficina
S OL U CI ON AR I O
Administrative Information Systems S. de información administrativa
GDSS Decision Support System Sistemas de soporte a decisiones
KWS Knowledge Work Systems S. de Manejo de Conocimiento
DSS Decision support systems Sistemas de soporte dedecisiones
ESS Executive support systems Sistema de Apoyo a Ejecutivos
CSCWS Computer supported co-operative work Trabajo cooperativo asistido por PC
SDLC System Design Life Cycle Ciclo de vida del diseño del sistema
AOO Object Oriented Analysis Análisis Orientado a Objeto
AN EXO S
DFD Data flow diagram diagrama de flujo de datos

GUI Graphical User Interfaces Interfaces gráficas de usuario
UML Unified Modeling Language

Guía Didáctica
Autoevaluación 3
En referencia al lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified
Modeling Language) identifique la siguiente definición:
Especifica una interacción entre un actor y el sistema, de modo tal que
pueda ser entendida por una persona sin conocimientos técnicos, también
permite captar una función visible para los actores.
a) Diagramas de flujo b) Casos de uso
BI BL I OG RA F ÍA
d) Actores d) Diagrama de actividades
Complete el siguiente enunciado. (1 punto)

Utilice la alternativa que considere correcta: Secuencia - Actividades - Flujo – Estado.
Diagramas de estado: Son una herramienta que sirve para modelar cómo afecta un
escenario a los estados que un objeto toma, en conjunto con los eventos que provocan
las transiciones de estado.
OR I ENT A CI O NES
Identifique y seleccione la opción correcta. (1 punto)
¿Cuáles de las siguientes características corresponden a Elementos distintivos de un
diagrama de estado?
1. Las decisiones se representaran por un rombo que designa una doble entrada.
2. Los estados por los que pasa el objeto, se representan con rectángulos de
puntas redondeadas.
3. Al realizar un almacenamiento en un diagrama se utiliza el símbolo de archivo.
P RO C ES O
4. Los nodos inicial y final se representan igual que las actividades de inicio y fin
del diagrama de actividades.
5. Las transiciones entre estados se representan por flechas.
Opciones de respuesta: a) 2,4,5 b) 1,2,3 c) 2,3,4 d) 1,4,5
UN I DAD ES
Escriba V si usted considera que es verdadero y F si lo considera falso a los
siguientes enunciados. (1 punto)
(V) Los Diagramas de flujo muestran la forma en que un grupo de objetos se

comunican (interactúan) entre sí a lo largo del tiempo.
(F) Un Diagrama de Secuencia consta de objetos, mensajes entre estos objetos y una S OL U CI ON AR I O
línea de vida del objeto representada por una línea vertical.
(V) En los diagramas de actividades las bifurcaciones condicionales se especifican con
un rombo colocando la condición de las ramas entre corchetes.
(F) En los diagramas de flujo Las acciones concurrentes se dibujan naturalmente, con
dos barras gruesas, una para indicar el comienzo de la concurrencia.
AN EXO S

Guía Didáctica
Autoevaluación 4
UML son las siglas de: Lenguaje unificado de modelado
Realice la representación visual de una entidad en un diagrama ER
BI BL I OG RA F ÍA
esquema de información. (V)

un valor (V)
Relacione el concepto con el tipo de diagrama al que hace referencia (1

punto)
OR I ENT A CI O NES
a) Muestran el conjunto de estados por los cuales pasa un objeto
b) Forma esquemática de representar ideas y conceptos en relación.
c) Modelar interacción entre objetos en un sistema según UML.
1. Diagrama de secuencia
2. Diagrama de flujo
3. Diagrama de estado
Opciones de respuesta: A) a2, b1, c3 B) a1, b2, c3
P RO C ES O
C) a3, b2, c1 D) a3, b1, c2
DESARROLLO PRÁCTICO:
Realice un DDE para verificar la validación de Password y Username en un SI.
UN I DAD ES
Precondiciones: error_ingreso<3 caso contrario GUI solicita validación desde el
email registrado para ser validado, se realiza cambio de contraseña (#, carácter
especial, M, n >= 8 caracteres) caso contrario el S.I espera 5 minutos y se bloquea la
cuenta. (2 puntos)
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
Identifique y explique a que hace referencia el siguiente DDE. (1 punto)
BI BL I OG RA F ÍA
OR I ENT A CI O NES
El presente diagrama muestra los estados por los que pasa un estudiante tercero de
bachillerato durante todo el proceso de inscripción registro, asignación y posterior
admisión a la institución educativa de educación superior.
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S

Guía Didáctica
8. ANEXOS
EJEMPLO DE ANÁLISIS Y DISEÑO ESTRUCTURADO DE UN SISTEMA SOFTWARE
Ingrese al link para observar el caso de estudio (ejemplo completo)
https://ocw.unican.es/pluginfile.php/1403/course/section/1794/Ejemplo_Estructurad
o.pdf
BI BL I OG RA F ÍA
OR I ENT A CI O NES
P RO C ES O
UN I DAD ES
S OL U CI ON AR I O
AN EXO S


Guia Didactica Analisis y Diseño de Sistemas 2020

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia Didactica Analisis y Diseño de Sistemas 2020

Cargado por

Copyright:

Formatos disponibles

Análisis y diseño de sistemas Informáticos |

Instituto Superior Tecnológico Sucúa | 1

Instituto Superior Tecnológico Sucúa | 2

2.4. Tipos de usuarios y permisos ............................................................... 51

Instituto Superior Tecnológico Sucúa | 3

Trabajo Autónomo ....................................................................................... 56

Instituto Superior Tecnológico Sucúa | 4

Esta asignatura se imparte con el objetivo de incorporar en el profesional en formación

Adelante y ¡éxitos! ¡Ud. está llamado a grandes cosas!

Instituto Superior Tecnológico Sucúa | 5

El docente responsable de la redacción de la presente guía, tiene amplia experiencia

La presente guía está estructurada de la siguiente manera, caratula, índice,

Luego de estas temáticas encontrara el desarrollo teórico practico de los diferentes

una auto evaluación y el cumplimiento de un trabajo autónomo.

Finalmente, se indican los solucionarios a las autoevaluaciones y anexos en donde se

La guía didáctica es un instrumento que ayuda a manejar el texto haciendo

aclaraciones, dando pistas para el ritmo de trabajo, proponiendo actividades para

Instituto Superior Tecnológico Sucúa | 6

4.2 Bibliografía complementaria

 KENDALL, H. & KENDALL, J. “Análisis y Diseño de Sistemas”. 3era. Ed.

 Daniel Cohen Karen. Enrique Asín Lares(2000).Sistemas de información para

4.3 Referencias electrónicas

5. ORIENTACIONES GENERALES PARA EL ESTUDIO

Todos hemos recibido talentos y debemos ponerlos en práctica para no perderlos. Le

Al iniciar el estudio de una asignatura nos encontramos desorientados. No sabemos

A manera de iniciación le hago estas preguntas:

¿Quiere aprender técnicas y métodos de estudio que le ayuden en su vida a conocer

Instituto Superior Tecnológico Sucúa | 7

5.2 Planificación del estudio

Instituto Superior Tecnológico Sucúa | 8

Disponga de un lugar limpio y ordenado. Cuide de las condiciones ambientales en

Instituto Superior Tecnológico Sucúa | 9

Hay que trabajar conjuntamente el texto (modulo), la guía didáctica, consultar en el

No se olvide hacer resúmenes de lo que va leyendo para luego utilizarlos en un repaso

Paralelamente, confeccione fichas de trabajo, cuestionarios personales, etc., anotando

Finalmente, recuerde que sus actividades (Gestión Formativa) corresponden al 30%,

califica sobre 10 puntos. Es una prueba estructurada.

Instituto Superior Tecnológico Sucúa | 10

Quien más trabaja ordenadamente, de más tiempo dispone.

Recuerde aprovechar las videoconferencias, clases presenciales virtuales, tutorías y

Instituto Superior Tecnológico Sucúa | 11

5.4. Apoyo tecnológico

Instituto Superior Tecnológico Sucúa | 12

6. PROCESO DE ENSEÑANZA APRENDIZAJE PARA EL LOGRO DE LAS

sus aprendizajes. El docente es un facilitador o mediador, según el nuevo paradigma

Instituto Superior Tecnológico Sucúa | 13

investigación científica. La investigación representa un rubro importante en el plano

Aprende a hacer, que trata del desarrollo de competencias para la aplicación de

La planificación y evaluación del currículo son concebidas por competencias.

La Interdisciplinariedad. Es un principio rector del enfoque de las nuevas ciencias,

transdisciplinariedad. El Capital Intelectual, a través de la transferencia de

La Didáctica Heterodoxa. Enfatiza en el aprendizaje más que en la enseñanza; en el

conocimientos; en la transferencia de métodos para aprender a aprender, antes que

Instituto Superior Tecnológico Sucúa | 14

Unidad 1: Conceptos básicos

EL ANALISTA DE SISTEMAS DE INFORMACIÓN

Instituto Superior Tecnológico Sucúa | 15

1.- Análisis de sistemas (Analista de información): Es reunir información y

CARACTERÍSTICAS DE SISTEMA DE INFORMACIÓN

Instituto Superior Tecnológico Sucúa | 16

 Suelen lograrse ahorros significativos de mano de obra.

Ejemplos de sistemas de información: facturación, nóminas, cuentas por cobrar,

 Sistemas Expertos de Soporte para la Toma de Decisiones (DEss: