Técnicas y métodos para sistemas
323
Técnicas y Métodos para el Análisis y Diseño de Sistemas Alejandro Domínguez [email protected] Curso impartido en la Fundación Arturo Rosenblueth, 1997-2000 1
-
Upload
alejandro-dominguez -
Category
Technology
-
view
14.451 -
download
6
description
Técnicas y métodos prara el análisis y diseño de sistemas
Transcript of Técnicas y métodos para sistemas
Técnicas y Métodos para el
Análisis y Diseño de Sistemas
Alejandro Domínguez
Curso impartido en la Fundación
Arturo Rosenblueth, 1997-2000
1
2
Objetivos
• Al término del curso, el alumno:
– Habrá adquirido un entendimiento detallado de la teoría
detrás de los enfoques modernos del desarrollo de
sistemas.
– Tendrá una apreciación detallada de los enfoques
clásicos del desarrollo de sistemas en las
organizaciones.
• Habrá desarrollado habilidades prácticas en la
utilización de técnicas y metodologías de análisis
y diseño.
3
Temario (1)
• LA VISIÓN DE SISTEMAS– Modelos
– Introducción a la visión de sistemas
– Los diferentes tipos y clases de sistemas
– El desarrollo histórico de la teoría de sistemas
– El valor de la información
– Los sistemas de información
– Conclusiones
• ENFOQUES DE DESARROLLO DE SISTEMAS– La resolución de problemas
– Metodología para el desarrollo de SI
– Los sistemas suaves de Checkland: una metodología para los esfuerzos de solución y definición (1)
– Los mapas mentales: una técnica para los esfuerzos de solución y definición (2)
4
Temario (2)
• ENFOQUES DE DESARROLLO DE SISTEMAS
(continuación)
– Guía para elaborar políticas y procedimientos: una técnica para los
esfuerzos de solución y definición (3)
– El papel del analista de sistemas en las organizaciones
• DESARROLLO DE SI COMPUTARIZADOS
– El ciclo de vida de los SI
– La fase de planeación
– La fase de análisis
– La fase de diseño
– La fase de implementación
– La fase de utilización
5
Temario (3)
• PLANIFICACIÓN DEL CICLO DE VIDA DE SI
– Introducción
– Cascada pura
– Codificar y corregir
– Espiral
– Cascadas modificadas
– Prototipado evolutivo
– Entrega por etapas
– Diseño por planificación
– Entrega evolutiva
– Diseño por herramientas
– Software comercial existente
– Selección del ciclo de vida
– El ciclo de muerte de los SI
6
• EL MODELADO DE LAS EMPRESAS
– La arquitectura de Zachman
Temario (4)
7
LA VISIÓN DE SISTEMAS
MODELOS
8
Abstracción y modelos
• Abstracción:
– es el proceso de centrarse en los detalles
esenciales (importantes) de un objeto o situación
(llamados entidades)
– ignora los detalles que no son esenciales (no
importantes) de esa entidad
• Modelos:
– es una abstracción de una entidad
• cualquier representación de los detalles esenciales
(importantes) de esa entidad
• son representaciones de lo que se considera esencial
(importante) acerca de una entidad
9
El contenido de los modelos
• Los modelos se pueden utilizar para capturar
representar información referente a:
– una entidad individual, o un conjunto de entidades
interrelacionadas o interactuando entre ellas
– las características estáticas (no cambiantes en el tiempo) o
dinámicas (cambiantes en el tiempo) de entidades, o un
conjunto de entidades interrelacionadas o interactuando
entre ellas
– puntos de vista simples o complejos de una entidad
– implementaciones diferentes de la misma entidad
10
La localización en los modelos
• Localización:
– es el proceso de ubicar objetos en la proximidad o
alrededor de otros objetos
• Los modelos
– funcionales localizan su información alrededor de las
funciones
– basados en datos localizan su información alrededor de
los datos y sus relaciones entre ellos
– orientados a objetos localizan su información alrededor
de los objetos y situaciones orientadas a objetos (e.g.,
objetos interactuando con otros objetos)
11
Las 6 categorías de los modelos
(1)
• Modelos físicos
– es una representación en 3D de entidades y conjuntos
de entidades
• Modelos textuales y de narración
– son descripciones textuales o narrativas de entidades
y conjuntos de entidades
• Modelos gráficos
– representan gráficamente las características de
entidades y conjuntos de entidades
12
Las 6 categorías de los modelos
(2)
• Modelos matemáticos
– representan las características de las entidades por
medio de ecuaciones matemáticas
• Modelos ejecutables
– Son modelos que son ejecutables en una
computadora
• Otros modelos
– Esta categoría genérica incluye todos los modelos
que no están dentro de las categorías anteriores
13
Utilización de los modelos
• Facilitar el entendimiento
– un modelo es más simple que su
entidad
• Facilitar la comunicación
– a través de un modelo se puede
comunicar información de una forma
rápida y precisa
• Predecir el comportamiento futuro
– esta es una característica principal de
los modelos matemáticos
14
Confección de los modelos
• Las 6 categorías pueden ser
confeccionadas de diferentes formas:
– mezcla de dos o más modelos
– medios mixtos: por ejemplo la utilización de
papel, resortes, tachuelas, etc.
– medios visuales y auditivos tales como vídeo
grabadoras, audio cassettes, películas,
fotografía, etc.
– modelos de realidad virtual
15
Modelos múltiples
• A menudo es útil construir modelos múltiples para
una misma entidad
– Estos modelos para una entidad en el mismo nivel de
abstracción (nivel de detalle) permite un mejor
entendimiento
• Específicamente, un modelo puede mostrar algún detalle que otro
modelo no muestra o que es incapaz de mostrar
– Estos modelos para una entidad en diferentes niveles de
abstracción (diferentes niveles de detalle) permiten
controlar cuánta información se desea mostrar
• Tales modelos permiten revelar progresivamente más detalle acerca
de una entidad como el entendimiento de ellos se incrementa
16
La creación de más de un
modelo
• Si más de un modelo de la misma entidad se
desarrolla para el mismo nivel de abstracción, se
debe mantener en mente
– todos los modelos deben tener el mismo nivel de detalle
– cada modelo debe revelar alguna información que no
revelan los demás modelos
– la terminología debe ser consistente a través de todos
los modelos; e.g., la misma entidad debe tener el mismo
nombre en todos los modelos
– los modelos deben ser consistentes entre ellos
17
Enfoque del curso (1)
• El enfoque del curso es describir como se
aplican los principios de los sistemas de
información en las organizaciones
• El vehículo que se utilizará como base para esta
descripción se denomina
18
Enfoque del curso (2)
• Este modelo consiste de una mezcla de los
modelos textual/narrativo y gráfico que
describe a las organizaciones de una forma
general
• Este modelo toma como marco de trabajo la
19
LA VISIÓN DE SISTEMAS
INTRODUCCIÓN A LA
VISIÓN DE SISTEMAS
20
Viviendo con sistemas
El hombre vive y trabaja
dentro de sistemas socialesLa tecnología ha producido
sistemas físicos complejos
Pero los principios que gobiernan el comportamiento de los
sistemas no se han comprendido del todo
21
La definición de “sistema”
Un automóvil es un sistema de
componentes que trabajan
conjuntamente para proporcionar
transportación
Sistema es un grupo de partes que operan de forma
conjunta para llevar a cabo un propósito común
Un sistema puede incluir personas así
como partes físicas
Una familia es
un sistema de
forma de vida
22
La no ocurrencia de los sistemas
¿Por qué no aparecen los conceptos
y principios de éstos de forma más
clara en la literatura y en la
educación?
Si los sistemas son tan importantes:
23
Surgimiento de los sistemas
La barrera para entender a los sistemas ha sido no sólo la
ausencia de conceptos generales importantes, sino
únicamente:
La dificultad de
indentificar y expresar el
conjunto de principios
universales que expliquen
los éxitos y fallas de los
sistemas de los que somos
parte
24
Descripción de los sistemas
• La mera descripción no ha sido suficiente para exponer
la verdadera naturaleza de los sistemas
• Las matemáticas no han sido adecuadas para manejar la
realidad fundamental de nuestros sistemas sociales
• Hemos sido aplastados por fragmentos de
conocimiento, pero no tenemos forma de estructurar
este conocimiento
25
Los enfoques analítico y
sistémico
Existen dos formas de visualizar la realidad: los
enfoques analítico y sistémico
Estos dos enfoques son
más complementarios
que opuestos. Ninguno
de ellos es reducible al
otro
26
Enfoque analítico vs. Enfoque
sistémico (1)
Enfoque analítico Enfoque sistémico
Aísla, entonces se concentra en
los elementos
Unifica y se concentra en la
interacción entre los elementos
Estudia la naturaleza de la
interacción
Estudia los efectos de las
interacciones
Enfatiza la precisión y los detalles Enfatiza la percepción global
Modifica una variable a la vez Modifica grupos de variables
simultáneamente
27
Enfoque analítico Enfoque sistémico
Permanece independiente de la
duración del tiempo; los
fenómenos considerados son
reversibles
Integra la duración del tiempo y
la irreversibilidad
Valida hechos por medio de
pruebas experimentales dentro del
cuerpo de una teoría
Valida hechos a través de la
comparación del comportamiento
del modelo con la realidad
Es eficiente cuando las
interacciones son débiles y
lineales
Es eficiente cuando las
interacciones son fuertes y no
lineales
Enfoque analítico vs. Enfoque
sistémico (2)
28
Enfoque analítico Enfoque sistémico
Utiliza modelos detallados y
rígidos que no son tan útiles en las
operaciones reales (por ejemplo:
modelos econométricos)
Utiliza modelos no tan rígidos
que son la base de conocimientos
y que son útiles en las decisiones
y las acciones
Lleva hacia la educación orientada
a las disciplinas
(juxtadisciplinaria)
Lleva a la educación
multidisciplinaria
Conduce a la acción programada a
través de detalles
Conduce a la acción a través de
objetivos
Posee el conocimiento de detalles
de objetivos pobremente definidos
Posee el conocimiento de
objetivos y detalles difusos
Enfoque analítico vs. Enfoque
sistémico (3)
29
• Esta tabla, aunque útil y simple, es sólo una
caricatura de la realidad
• La tabla muestra dos enfoques complementarios,
uno de los cuales -el enfoque analítico- ha sido
favorecido desproporcionadamente en nuestro
sistema educativo
Enfoque analítico vs. Enfoque
sistémico (4)
30
LA VISIÓN DE SISTEMAS
DIFERENTES CLASES DE
SISTEMAS
31
El modelo general de sistemas
(1)
• Inputs (entradas, insumos)
son aceptados en el sistema
• Outputs (salidas,
productos) se producen a
través de los procesos
dentro del sistema
• También pueden existir
almacenaje intermedio y
control sobre el
funcionamiento del sistema
Output
Control
Proceso
Almacenaje
Input
Modelo de sistemas
32
El modelo general de sistemas
(2)
Input
(electricidad)
Input(granos de café)
Output
Almacenaje
Control
Proceso (calentamiento)
SISTEMA
33
El modelo de sistemas (3)
• Todos los sistemas tienen
objetivos
• Para la identificación de un
sistema sus objetivos se deben
especificar claramente
• Una vez que los objetivos del
sistema son claros, existe una
forma de medir su desempeño con
el fin de saber cuando está
cumpliendo sus objetivos
34
Objetivos de los sistemas (1)
Algunos sistemas pueden tener objetivos poco claros o que no han sido enunciados de forma adecuada para que la medida de su desempeño sea obvia
• Los sistema evolutivos no tienen objetivos claros• salvo aquellos objetivos que han
sido enunciados para (algunos) de sus componentes
• Ejemplos: sistemas económicos (nacionales e internacionales) y organismos de negocios
35
Objetivos de los sistemas (2)
• Los sistemas diseñados son
aquellos que se han
construido para cumplir
objetivos preestablecidos
• En los sistemas evolutivos
las medidas de desempeño
no siempre se cumplen
• Los sistemas de negocios
son un ejemplo de ambos
tipos de sistemas
36
Inputs y outputs de un sistema
(1)
• Los inputs y
outputs de un
sistema se pueden
conectar a otros
sistemas
• Los outputs de un
sistema pueden
ser los inputs de
otro
Sistema
1
Inputs
Output
Input
Output
Output
Input
OutputOutputs
Inputs
Input
Sistema
2
Sistema
3
37
Inputs y outputs de un sistema
(2)
• Es posible visualizar al
mundo como un aglomerado
de sistemas
• Entonces no existen outputs
que desaparecen
• El interés de las personas
sólo se restringe a algunos
de estos sistemas
38
Entorno y frontera de los sistemas
(1)Los inputs de un sistema provienen de su entorno, mientras que
sus outputs se transfieren hacia él
El entorno de un sistema se define como aquel que está fuera de sus
fronteras, pero que interactúa con el sistema mismo
39
Entorno y frontera de los sistemas
(2)
• El entorno no es un
concepto de
geografía
• La noción de
entorno se define en
términos del
concepto de
frontera
40
• Las características que delinean el alcance de un
sistema forman sus fronteras
– Lo que un observador percibe como un sistema y sus
fronteras queda determinado por lo que este observador
identifica por objetivos del sistema, en combinación con el
área de conocimiento en el cual tiene interés y control
• Así, la idea de un sistema se forma tanto de los hechos
del mundo real y de las percepciones e interés del
observador
Entorno y frontera de los sistemas
(3)
41
Los sistemas
cerrados no
tienen inputs
u outputs:
no tienen
entorno
Los sistemas
abiertos son
aquellos que
no son
cerrados
Entorno y frontera de los
sistemas (4)
• Estrictamente hablando, no existen sistemas cerrados– excepto el universo como un todo
– el término se utiliza a menudo para los sistemas que interactúan débilmente con su entorno
42
Atributos de los sistemas
• Los sistemas están dotados de atributos o
propiedades
• Los atributos pueden ser cuantitativos o
cualitativos. Esta diferenciación determina el
enfoque a utilizarse para medirlos
• Los atributos cualitativos ofrecen mayor dificultad
de definición y medición que los cuantitativos
43
Estados y condición de los
sistemas
• El estado de un sistema
se define por los
atributos (propiedades)
que muestran sus
elementos en un punto
en el tiempo
• La condición de un
sistema está dada por el
valor de los atributos
que lo caracterizan
44
Flujos y conducta de los
sistemas
• Los cambios de un estado a otro por los
que pasan los elementos del sistema da
surgimiento a flujos
• Los flujos se definen en términos de
razones de cambio del valor de los
atributos del sistema
• La conducta de un sistema es el
cambio en los estados del sistema sobre
el tiempo
45
Subsistemas
• Los sistemas están compuestos
de subsistemas que están
interrelacionados uno con los
otros por medio de sus inputs y
outputs
• Esto proporciona al sistema una
estructura interna
• Cada subsistema es en si
mismo un sistema
S1 S2
Sn
• • •
• • •
SISTEMA
46
Tipos de conexión entre subsistemas
Subsistema 1
Subsistema 2
Conexión directa
(1 y 2)
Subsistema 1
Subsistema 2
Subsistema 3
Conexión indirecta
(1 y 3)
47
Jerarquía de subsistemas y sistemas
La descomposición de un sistema en sus subsistemas
se puede visualizar a través de una gráfica
jerárquica de sistemas
Jerarquía de subsistemas
Subsistema 1 Subsistema 2 Subsistema 3
Sistema primario
48
Función de los subsistemas
• Los subsistemas se definen por medio de las
funciones que desempeñan
• El propósito de la descomposición es dividir un
sistema grande en sus partes constituyentes
• Este proceso continua hasta que los subsistemas
resultantes sean de tamaño manejable en el sentido
de su entendimiento
49
Cada área funcional es un
sistema
ProcesoInput Output
Subsistema de ventas
ProcesoInput Output
Subsistema de manufactura
ProcesoInput Output
Subsistema de finanzas
ProcesoInput Output
Subsistema de informática
Dirección
50
Cada nivel administrativo es un
sistema
ProcesoInput Output
Nivel de planeación estratégica
Estándares
ProcesoInput Output
Nivel de control administrativo
ProcesoInput Output
Nivel de control operacional
Estándares
Estándares
Flujo de
información
Flujo de
decisión
51
Combinaciones entre subsistemas
Subsistema 1 Subsistema 2
Combinación en serie
Subsistema 1 Subsistema 2
Combinación con realimentación (feedback)
Combinación en paralelo
Subsistema 1
Subsistema 2
Subsistema 3
52
Desacoplamiento de subsistemas
• La dependencia entre subsistemas se mide a través de
su grado de acoplamiento
• Dos subsistemas están altamente acoplados si un
cambio en los inputs (outputs) de uno de ellos
produce un cambio sustancial en el estado del otro
• Dos subsistemas están altamente desacoplados si
los cambios en los inputs (outputs) de alguno de ellos
tiene poco o ningún efecto en el estado del otro
53
Ejemplo de subsistemas acoplados
Requirimientos de production
Producción Ventas
Para que estos subsistemas acoplados puedan trabajar en
armonía es necesario que exista una comunicación estrecha
entre ellos
54
Desacoplamiento de subsistemas
(1)
• El desacoplamiento se lleva
a cabo introduciendo un
amortiguador o inventario
entre los dos subsistemas
• El efecto del
desacoplamiento es proteger
los subsistemas de ventas y
de distribución de las
variaciones en la
producción
Requerimientos de production
Producción Ventas
Inventario
55
Otra forma de llevar a cabo el desacoplamiento entre
subsistemas es asegurar que uno de ellos trabaje con
capacidad sobrada
Requerimientos de producción
Capacidad
sobrada
Producción
Ventas
Desacoplamiento de subsistemas
(2)
56
• En el ejemplo anterior el efecto de desacoplamiento
conduce a una mayor estabilidad
• El desacoplamiento generalmente conduce a la
estabilidad de los sistemas
• Un cierto grado de estabilidad a través del
desacoplamiento siempre es deseable en cualquier
sistema
• Este grado de estabilidad normalmente se introduce
en la etapa de diseño del sistema
Desacoplamiento de subsistemas
(3)
57
Control y realimentación
(feedback) (1)
• Los sistemas tienen objetivos
• Con el fin de asegurar que los objetivos de lossistemas se cumplan es necesario que exista uncontrol que opere sobre su funcionamiento
• Los controles a menudo trabajan sobre los estados youtputs de un sistema. Comparan estos con losobjetivos del sistema, y toman medidas correctivas sies necesario
58
Control y realimentación
(feedback) (2)
El modelo general de control y realimentación es
Efector Comparador
Procesos
Control
Datos/
informaciónDecisiones
Estándares
Inputs OutputsSensor
59
• En la figura anterior:
– El proceso acepta los inputs y los convierte en outputs
– El sensor monitorea el estado del proceso
– El controlador acepta los datos del sensor y acepta los
estándares del exterior. El controlador genera entonces
ajustes o decisiones que alimentan y afectan el proceso
– El comparador compara los datos con los estándares y
pasa una indicación al efector de la desviación del
estándar de los datos monitoreados
– El efector hace ajustes a la salida generada por el
controlador
Control y realimentación
(feedback) (3)
60
Realimentación
• Existen dos tipos de realimentación– La realimentación positiva
es aquella en la cual la multiplicación entre los inputs y outputs es tal que la salida aumenta con incrementos de la entrada
– La realimentación negativa es aquella en la cual la multiplicación entre los inputs y outputs es tal que la salida disminuye al aumentar la entrada
• La realimentación positiva generalmente conduce a la inestabilidad de los sistemas (e.g. crecimiento de bacterias)
• La realimentación negativa proporciona un control de sistema estable (e.g. sistema de calefacción con termostato)
61
Control
• El mecanismo de control se emplea para comprobar
el buen funcionamiento de los sistemas y para
adaptar su comportamiento a circunstancias
variables, ya sea en su entorno o dentro de ellos
• Así, el propósito principal de los controladores es
asegurar que un sistema esté funcionando de un
modo uniforme, esto implica la prevención de la
ocurrencia de problemas
62
Control y realimentación: los 3
principios básicos
• El estudio del control y la realimentación se llama
cibernética– Las ideas de la cibernética se han aplicado al estudio del
control administrativo de las organizaciones
• Los 3 principios básicos en los que se basan el control
y la realimentación son:– La información y los datos alimentados al controlador deben
ser simples y fáciles de comprender
– La información y los datos alimentados al controlador deben
ser proporcionados a éste de forma regular
– Cada controlador tendrá una esfera de responsabilidad y un
alcance de autoridad
63
LA VISIÓN DE SISTEMAS
EL DESARROLLO
HISTÓRICO DE LA TEORÍA
DE SISTEMAS
64
La búsqueda de nuevas
herramientas (1)
Realimentación entonces
automatización y computadoras
Memoria, reconocimiento
de patrones, IA y robótica
Neurología, percepción y
visión
65
La búsqueda de nuevas
herramientas (2)
66
Los pioneros
El matemático
Norbert Wiener
El neurofisiologista Warren
McCulloch y
el Profesor Jay Forrester
Otros personajes:
A. Rosenblueth
W.B. Cannon
J.H. Bigelow
C. Shannon
67
La máquina inteligente
… con el fin de controlar una determinada acción, la circulación de
información necesaria para controlarla debe formar “un ciclo cerrado
permitiendo así la evaluación de los efectos de las acciones y la adaptación
a futuras conductas basadas en desempeños anteriores”
Wiener,
Bigelow,
y Rosenblueth
El resultado: Cybernetics, or
control and communication in the
animal and the machine
Hemos descubierto el ciclo cerrado
de información necesaria para corregir
cualquier acción —el ciclo cerrado de
realimentación negativa. Podemos generalizar
este descubrimiento en términos
de los organismos humanos
68
Otros trabajos y sus consecuencias
• McCulloch descubrió que para entender el
mecanismo del cerebro (y su simulación por medio
de máquinas) deben cooperar varias disciplinas del
conocimiento humano
• Von Bertalanffy descubrió que un organismo vivo se
puede ver como un todo y que un todo es más que la
simple suma de sus partes
• Forrester creó la Dinámica Industrial: Las industrias
son sistemas cibernéticos, de esta forma se pueden
simular y tratar de predecir su comportamiento
69
Historia de la palabra “cibernética”
(1)
• Cibernética es la disciplina que estudia la
comunicación y el control de los seres vivientes,
así como de las máquinas construidas por el
hombre
• Cibernética es ― el arte de asegurar la eficiencia de
una acción‖ (Louis Couffignal, 1958)
• La palabra ―cibernética‖ fue reinventada por
Wiener en 1948 a partir de la palabra griega
kubernetes: piloto o timón
70
• La palabra fue utilizada por Platón y tuvo el
sentido de ―el arte de la dirección‖ o el ―arte de
gobernar‖
• Ampère utilizó la palabra para denotar ―el estudio
de las formas de gobernar‖
• James Watt y M. Boulton inventaron en 1798 uno
de los primeros mecanismos para controlar la
velocidad de una máquina de vapor: se le llamó
―gobernador‖ o ―bola reguladora‖
Historia de la palabra
“cibernética” (2)
71
Cibernética tiene la misma
raíz de la palabra gobierno:
el arte de administrar y
dirigir sistemas altamente
complejos
Historia de la palabra
“cibernética” (3)
72
LA VISIÓN DE SISTEMAS
EL VALOR DE LA
INFORMACIÓN
73
Etimología de “información”
• Información se deriva de la palabra
en latín informare: dar forma a
– La etimología denota una imposición
de estructura sobre algo indeterminado
• El diccionario Larousse de la
Lengua Española conecta a la
palabra con conocimiento y
comunicación:
– conocimiento de todos los factores que
constituyen el elemento indispensable
para que el mando adopte una decisión
74
El concepto de entropía
• En las ciencias físicas, la entropía asociada con
una situación en una medida del grado de
aleatoriedad
• La segunda ley de la termodinámica enuncia que:
un proceso natural que inicia en un estado de
equilibrio y termina en otro diferente hará que la
entropía del sistema y su entorno se incremente
• Una alta entropía es equivalente a un alto nivel de
caos
75
La información según Wiener
… así como la información en un
sistema es una medida de su grado de
organización, así la entropía de un
sistema es una medida de su grado de
desorganización
La cantidad de información es el negativo
de la cantidad definida comunmente como
entropía en situaciones similares. Así, los
procesos que pierden información son casi
análogos a los procesos que incrementan
la entropía
También, según Wiener, la información está relacionada con
cuestiones de decisión, comunicación y control
76
La información según Shannon
La cantidad que de forma única cumple
los requerimientos del concepto de
información es aquella que en
termodinámica se conoce como entropía
• Así, según Shannon, no importa si estamos comunicando un hecho, un juicio o algo sin sentido
• Todo lo que se transmite en una línea telefónica es información
• Los mensajes ―hola‖ y ―lhao‖ tienen la misma cantidad de información
77
La contradicción
• Existe, entonces, una gran — y confusa —
diferencia entre Shannon y Wiener
• El concepto de información según Shannon
es opuesto al de Wiener
Información
según Wiener
Información
según Shannon
78
El significado de la información
según Wiener
• La señal en un sistema contiene información, la
cual tiene algún significado para los propósitos de
un sistema en particular
• La información enviada o recibida por un sistema
no necesariamente tiene significado fuera de éste
• Así, una proposición lógica verdadera en un
sistema puede ser falsa en otro
79
• La entropía contiene más información que estructura
• La información no se debe confundir con significado
– Ejemplo: el significado de la palabra ―piedra‖ es una
construcción humana que no tiene nada que ver con el objeto
llamado piedra
• Lo que se llama información en un contexto se
convierte en datos en otro, y en ambos tiene diferentes
significados
• Los datos son hechos sin estructura y sin uniformidad
que pueden ser generados indefinidamente,
almacenados, recuperados, actualizados y reconstruidos
El significado de la información
según Shannon
80
Los puntos de vista modernos de
la información
Estudia la relación
formal entre los
símbolos que
representan a la
información. No
considera su
significado y su
valor asociado
Estudia el valor de
los símbolos que
representan a la
información
Estudia la
información en un
contexto dado, así
como en su
utilización para
alcanzar un
objetivo
81
Procesamiento de la
información
sistema de
agregación
I1 I2 I3 In
k
kII
sistema
selectivo
I1 I2 I3 In
Ii Ik
Sistema de
cálculo
I1 I2 I3 In
n21 I,,I,IfI
82
La información como una forma
de vida
• La información es la diferencia que hace la diferencia
• La información es una actividad: la información es un
verbo no un sustantivo
• La información es una acción que ocupa tiempo más
que un estado que ocupa espacio físico
• Desde el punto de vista pragmático: una sociedad
informatizada es una sociedad con conocimiento
• … vivir en plenitud es vivir con la información
adecuada...
83
¿La información tiene valor y
significado?
• Según Shannon existe más información en el caos y la
complejidad que en la estructura
• La experiencia dicta que entre más información es
producida, más caótico es el mundo
• Según Shannon: la información no tiene valor por sí
misma
• El valor de la información está directa o indirectamente
conectado con las acciones humanas
84
LA VISIÓN DE SISTEMAS
LOS SISTEMAS DE
INFORMACIÓN
85
Sistemas de información
• Un sistema de información (SI) proporciona
información del entorno (parte externa) y la parte
interna de una organización
• Esta información, la cual es útil para miembros y
clientes de una organización, tiene que ver con sus
clientes, proveedores, productos, recursos humanos,
recursos materiales, etc.
• La organización puede ser: una empresa, una iglesia,
un hospital, una universidad, un banco, etc.
86
SI formales e informales
• SI formales son aquellos que descansan en
definiciones fijas y aceptadas de datos y
procedimientos para la recolección,
almacenamiento, procesamiento, diseminación, y
utilización de los datos
• SI informales utilizan acuerdos implícitos y
reglas no establecidas de comportamiento
87
SI formales
• El interés es sobre SI formales
• SI formales pueden ser manuales o computarizados
• SI manuales utilizan la tecnología de papel y lápiz
• SI computarizados (SIC) descansan en la
tecnología de hardware y software de las
computadoras para procesar y diseminar la
información
• En lo que sigue cada vez que aparezca el acrónimo
SI se dará por entendido que se refiere a SIC
88
Parte externa de un SI (1)
ORGANIZACIÓN
Sistema de información
InputCaptura o
colección de
datos llanos
ProcesoClasifica
Arregla
Calcula
OutputDistribución de
información
procesada
Realimentación
Clientes
Agencias reguladorasAccionistas
Competidores
Provedores
Gobierno Comunidades
Sindicatos
89
Parte externa de un SI (2)
• Desde un punto de vista externo, un SI es una solución
organizacional y administrativa basada en las tecnología de
la información para afrontar los retos impuestos por el
entorno
• Así, los SI son más que computadoras: requiere del
entendimiento de la organización, la administración y la
tecnología
SI
Administración
90
• La parte interna de un SI está estrechamente
relacionada con la construcción de aplicaciones
• Una aplicación es un conjunto de programas
(instrucciones que ejecutan una tarea bien
definida) que automatizan un proceso de una
organización
• Todas las aplicaciones tienen algunas
características comunes y otras únicas
• Las características comunes son: datos, procesos,
restricciones, e interfaces
Parte interna de un SI (1)
91
Parte interna de un SI (2)
Procesos de
la aplicación:
edita, actualiza,
reporta, pregunta
Terminal para
entrada
y salida de datos
Archivo
maestro
Archivo de
acceso
secuencial
Documento a
ser actualizado
Reporte de las
preguntas (queries)
Datos de entrada
y salida utilizando interfaces
humano-máquina
Procesos de la aplicación
con restricciones especificadas
Almacenamiento
de datos
Recuperación
de datos
Almacenamiento
de datos; interfaz
computarizada
A aplicaciones
externas
Salida de datos;
interfaz manual
Salida de datos;
interfaz manual
92
• Los datos se clasifican en datos de entrada
(inputs) y de salida (outputs)
• El almacenamiento de datos requiere que estos
estén en formato previamente especificado
• La recuperación de datos requiere de ciertos
medios para poner en línea los datos almacenados
• Un proceso es la secuencia de instrucciones o
conjunción de eventos que operan sobre los datos
Parte interna de un SI (3)
93
• Las restricciones son limitaciones sobre el
comportamiento y/o procesamiento de las entidades
• Existen 6 tipos de restricciones:
– Restricciones previas
• son precondiciones que se deben cumplir para que un proceso se
lleve a cabo
– Restricciones posteriores
• son condiciones que se deben cumplir para que un proceso se
complete exitosamente
Parte interna de un SI (4)
94
– Restricciones temporales: se refieren a:
• procesos ejecutados en un momento dado (transferencia de
dinero)
• procesos ejecutados después de un intervalo de tiempo
(activación del protector de pantalla)
• requerimientos externos en cierto tiempo (reportes en papel)
• procesos síncronos (procesos A y B antes del proceso C)
• Tiempos de respuesta (respuesta en tiempo real)
Parte interna de un SI (5)
95
– Restricciones de estructura
• describen las restricciones entre los datos, los meta-datos
(conocimiento acerca de los datos), conocimiento y meta-
conocimiento (conocimiento generado por el sistema) en las
aplicaciones
– Restricciones de control
• están relacionados con el mantenimiento de las relaciones
entre los datos
– Restricciones de inferencia
• están relacionados con la habilidad de generar nuevos hechos
a partir de los anteriores y de sus relaciones entre ellos
Parte interna de un SI (6)
96
• Existen 3 tipos de interfaces:
– Interfaz humana: es el medio por el cual una
aplicación se comunica con los usuarios
– Interfaz manual: son reportes que muestran la
información proporcionada por la computadora
– Interfaz automatizada: es el medio por el cual un
proceso interno o aplicación se comunica con otro
proceso o aplicación
Parte interna de un SI (7)
97
El modelo de sistemas general
de la organización
InputProceso de
transformaciónOutput
ORGANIZACIÓNClientes
Agencias reguladoras Accionistas Competidores
ProvedoresGobierno Comunidades
Sindicatos
de fuentes
físicas Hacia
fuentes
físicas
Administración
Estándares
Procesadorde la
información
Decisiones
Datos/
Información
Datos/información
Datos/Información
98
Niveles organizacionales y SI (1)
• En una organización se pueden distinguir cuatro
niveles organizacionales: Nivel operacional, nivel
de conocimiento, nivel administrativo, y nivel
estratégico
• Para cada nivel existen SI asociados:
– SI operacional: monitorean las actividades elementales
y las transacciones de la organización
– SI de conocimiento: Soporta el conocimiento y los
datos de los trabajadores en una organización
99
Niveles organizacionales y SI (2)
• Para cada nivel existen SI asociados
(continuación):– SI administrativos: Soportan el monitoreo, el
control, la toma de decisiones, las actividades administrativas de administradores intermedios
– SI estratégicos: Soportan las actividades de planeación de largo plazo de los altos directivos
100
Tipos de SI (1)
• Existen 6 tipos de SI para los 4 niveles
organizacionales:
– SI operacionales: Sistemas de procesamiento de
transacciones (TPS)
– SI de conocimiento: Sistemas basados en el conocimiento
(KWS), Sistemas de automatización de oficinas (OAS)
– SI administrativos: Sistemas de administración de la
información (MIS), Sistema de soporte a las decisiones
(DSS)
– SI estratégicos: Sistemas de soporte para ejecutivos (ESS)
101
Tipos de SI (2)
TIPO DE
SI
ENTRADA DE
INFORMACIÓN
PROCESO SALIDAS DE
INFORMACIÓN
USUARIOS
ESS Datos agregados;
internos y externos
Gráficas;
simulación;
interactivo
Proyecciones;
respuesta a
preguntas
Altos directivos
DSS Bajo volumen de
datos; modelos
analíticos
Interactivo;
simulación,
análisis
Reportes
especiales; análisis
de decisiones;
respuesta a
preguntas
Profesionales;
personal
administrativo
MIS Datos de
transacciones
sumarias; alto
volumen de datos,
modelos sencillos
Reportes de rutina;
modelos sencillos;
análisis de bajo
nivel
Resúmenes y
reportes de
excepción
Administradores
de nivel intermedio
102
Tipos de SI (3)
TIPO DE
SI
ENTRADA DE
INFORMACIÓN
PROCESO SALIDAS DE
INFORMACIÓN
USUARIOS
KWS Especificaciones
de diseño; bases de
conocimiento
Modelación;
simulación
Modelos; gráficas Profesionales;
personal técnico
OAS Documentación;
programas de
trabajo
Administración de
documentos;
horarios;
comunicación
Documentos;
horarios; correo
Oficinistas
TPS Transacciones,
eventos
Ordenar, listar;
mezclar, actualizar
Reportes
detallados, listas,
resúmenes
Personal operativo,
supervisores
103
Tipos de SI (4)
ESS
MISOAS
TPS
DSS
Operacional Conocimiento Administrativo EstratégicoTIPO DE
DECISIÓN
Estruc-
turada
Semi-
estruc-
turada
No
estruc-
turada
104
Interrelación entre los tipos de
sistemas
ESS
MIS
OAS TPS
DSS
• Los TPS son los
productores principales
de la información
requerida por los otros
SI, quienes a su vez
producen información a
otros SI
• Estos diferentes tipos de
sistemas están
comúnmente
desacoplados en muchas
organizaciones
105
LA VISIÓN DE SISTEMAS
CONCLUSIONES
106
La visión de sistemas y los
negocios
• La visión de sistemas considera a las operaciones
de negocios como sistemas embebidos dentro de
su entorno
• Lo anterior es una forma muy abstracta de pensar,
pero tiene un gran valor potencial para los
directivos de las empresas
107
La importancia de la visión de
sistemas
• La visión de sistemas:
– evita que el directivo se pierda en la complejidad de la
estructura organizacional y en los detalles del trabajo
– reconoce la necesidad de tener buenos objetivos
– enfatiza la importancia de todas las partes y su
actuación como un todo dentro de la organización
– reconoce las interconexiones de las organizaciones con
su ambiente
– hace énfasis en la información obtenida por
realimentación
108
• Si a un directivo se le pregunta si tiene una visión
de sistemas de la empresa existen dos posibles
respuestas:
– No
– No lo se. Nunca lo he pensado
• Sin embargo, reconocen la importancia de los 5
puntos anteriores
La visión de sistemas está
implícita en las organizaciones
109
LA RESOLUCIÓN DE
PROBLEMAS
ENFOQUES DE
DESARROLLO DE LOS SI
110
¿Qué es un problema?
• Un problema es una condición que tiene el
potencial de causar un daño o producir
beneficios excepcionales
• La resolución de problemas es el acto de
responder a problemas de tal forma que
suprima los efectos dañinos o capitalicen las
oportunidades para obtener un beneficio
• La importancia de la resolución de problemas
no se basa en el tiempo invertido sino en sus
consecuencias
111
La toma de decisiones y la
resolución de problemas
• Una decisión es la selección de una estrategia o
acción
• La toma de decisiones es el acto de seleccionar la
estrategia o acción que el directivo cree le ofrecerá
la mejor solución al problema
112
Componentes del proceso de
resolución de problemas
Solución
Resolvedor
de problemas
(directivo)
Problema
Estándares
Información
Soluciones
alternativas
Restricciones
Elementos del sistema conceptual
Estado
deseado
Estado
actual
113
Problemas versus síntomas (1)
• Los síntomas son condiciones producidas
por el problema
– muchas veces el directivo visualiza los
síntomas más que los problemas
• Los síntomas aparecen después de la
realimentación
• Los síntomas son como la parte visible de
un iceberg
– el directivo tiene que ir más allá para localizar
la causa del problema
114
• El problema es la causa para obtener bajos
beneficios
• Un problema se puede visualizar como la causa
de una perturbación, o la causa de una
oportunidad
Problemas versus síntomas (2)
115
Tipos de problemas (1)
• Un problema estructurado consiste de elementos
y relaciones entre elementos que son entendidos
del todo por el resolvedor de problemas
– cuando esto sucede el posible expresar el problema por
medio de un modelo matemático
• Un problema no estructurado consiste de
elementos y relaciones entre elementos que no son
entendidos del todo por el resolvedor de
problemas
– la cuantificación de este tipo de problemas es difícil,
sino imposible
116
• En la realidad existen pocos problemas
completamente estructurados o completamente no
estructurados en una organización
– los problemas más comunes son los llamados
semiestructurados
• Un problema semiestructurado es aquel que
contiene algunos elementos o relaciones entre
ellos que son entendidos del todo por el resolvedor
de problemas
Tipos de problemas (2)
117
Las cuatro dimensiones para la
resolución de problemas
PersonasCon una visión clara y precisa
de la problemática o condisposición de obtener esta
visión
ProductoConsiste en estimar la dimensión
del problema.Se basa en la técnica“divide y vencerás”
Tecnología oherramientas
Es necesario hacer un buen usoellas y tener las apropiadas para
la resolución del problema
ProcesoEvitar repetición del trabajo
Controlar la calidad de la soluciónGestionar riesgos
Poner atención a los recursosPlanificar la solución
Enfatizar a quién o a qué vadirigida la solución
118
ENFOQUES DE
DESARROLLO DE LOS SI
METODOLOGÍA PARA
DESARROLLO DE SI
119
La necesidad de una
metodología eficiente y eficaz
• Las presiones del mercado
• Entregas retrasadas
• Fricciones
• Cancelaciones de proyectos
• Presiones en los tiempos de
entrega
120
Metodología
Planeación Administración
Control Evaluación
• Para desarrollar e implementar SI se requieren de
metodologías
• Metodología: una colección de procedimientos,
técnicas, y herramientas de modelado que ayudan en la
resolución de problemas
121
Consideraciones metodológicas
122
Técnicas y herramientas
• Cada metodología hace uso de técnicas y herramientas
particulares, y técnicas y herramientas particulares
pueden ser útiles a varias metodologías
• Una técnica es una forma de llevar a cabo una
actividad particular en el proceso de desarrollo de
sistemas
• Una metodología en particular puede recomendar
técnicas para llevar a cabo estas actividades
• Cada técnica puede utilizar una o varias herramientas
123
• Una metodología para los SI, en un intento de
hacer uso efectivo de las tecnologías de
información, y de las técnicas y herramientas
disponibles
• Objetivos
– Detectar de forma precisa los requerimientos de los SI
– Proporcionar un método sistemático de desarrollo: el
progreso de desarrollo debe ser monitoreado de forma
efectiva
– Proporcionar indicaciones de cualquier cambio que sea
necesario realizar en el proceso de desarrollo
Metodologías de los SI: objetivos
(1)
124
• Objetivos (continuación)
– Producir un SI bien documentado y de fácil
mantenimiento
– Proporcionar un SI dentro de los tiempos estipulados y
con los costos adecuados
– Proporcionar un SI adecuado para todos los afectados
por él
La metodologías de los SI:
objetivos (2)
125
La metodología (1)
• A pesar de que existen muchos enfoques, todos siguen
el mismo patrón fundamental
• Se pueden distinguir 10 pasos divididos en 3 fases
• Cada fase consiste de un tipo particular de esfuerzo que
se debe realizar:
– Esfuerzo de preparación ayuda a localizar el problema
– Esfuerzo de definición ayuda a identificar el problema y su
entendimiento
– Esfuerzo de solución ayuda a identificar soluciones
alternativas, evaluarlas, seleccionar la mejor, implementar
esa solución, y asegura la resolución del problema
3
fases
126
La metodología (2)
• Fase I: esfuerzo de preparación
– Visualizar a la organización como un
sistema
– Identificar el entorno del sistema
– Identificar los subsistemas de la
organización
• Fase II: esfuerzo de definición
– Proceder de un nivel de sistemas a uno
de subsistemas
– Analizar las partes del sistema en una
secuencia determinada
127
La metodología (2)
• Fase III: el esfuerzo de la
solución
– Identificar soluciones alternativas
– Evaluar las soluciones alternativas
– Seleccionar la mejor solución
– Implementar la solución
– Asegurarse que la solución es
efectiva
128
El esfuerzo de preparación
• Los tres pasos:
– no tienen por que llevarse a cabo en orden
– de forma conjunta producen el marco necesario para
entender el problema
– su implementación puede tomar un tiempo considerable
129
El esfuerzo de preparación:
Pasos 1 y 2
• Paso 1: Visualizar a la organización
como un sistema
– esto se logra con la utilización del
modelo de sistemas general presentado
anteriormente
– debe hacerse especial énfasis en ver
cómo la organización se ajusta al modelo
• Paso 2: Identificar el entorno del
sistema
– Se deben identificar los ocho elementos
que componen el entorno del sistema
130
El esfuerzo de preparación:
Paso 3
• Paso 3: Identificar los subsistemas
de la organización
– cada área funcional y cada nivel
administrativo es un subsistema
– se puede hacer una división por
subsistemas si se observan la fuentes
de información
131
El esfuerzo de definición
• Consiste en:
– estar consciente que el problema existe o está por
existir (identificación del problema)
– conocer a fondo el problema con el fin de diseñar
una solución (entendimiento del problema)
• Hace uso extensivo de la realimentación
• Se divide en dos pasos:
– proceder de un nivel de sistema a uno de subsistema
– analizar las partes del sistema en una secuencia
determinada
132
• Paso 4: proceder de un nivel de sistemas a
uno de subsistemas
– el sistema puede ser la organización o una unidad
de la organización, por lo que se debe proceder
nivel por nivel en la jerarquía de sistemas
– el sistema puede existir en cualquier nivel
• no es necesario iniciar con la organización como un
sistema
– existen dos subpasos primordiales:
• identificar la posición del sistema e relación con su
entorno
• analizar el sistema en términos de sus subsistemas
El esfuerzo de definición: Paso
4
133
• Paso 5: analizar las partes del sistema en una
secuencia determinada:
El esfuerzo de definición: Paso
5 (1)
3.
Administración
1.
Estándares
6. Proceso de
transformación
4. Procesador
de información
7. Fuentes
de salida
2.
Salidas
5.
Entradas
5. Fuentes
de entrada
134
El esfuerzo de definición: Paso
5 (2)La visión de sistemas proporciona la vía para la definición del problema
3.
Administración
1.
Estándares
6. Proceso de
transformación
4. Procesador
de información
7. Fuentes
de salida
2.
Salidas
5.
Entradas
5. Fuentes
de entrada
3.
Administración
1.
Estándares
2.
Salidas
3.
Administración
1.
Estándares
2.
Salidas
Analizar la organización como un sistema
Analizar un subsistema dentro de la organización
Analizar un sub-subsistema dentro de la organización
135
El esfuerzo de solución: Paso 6
• Paso 6: identificar soluciones alternativas
– una técnica informal para esta identificación es
la denominada lluvia de ideas
• cada participante presenta sus puntos de vista y estos
son discutidos
– una técnica más formal es llevar a cabo una
sesión JAD (joint application design)
• El grupo de discusión es guiado por un líder
(denominado facilitador) y las ideas se redactan de
forma sistemática por un grupo de escribas
– otras técnicas se mostraran en las siguientes
secciones
136
• Paso 7: evaluar las
soluciones alternativas
– todas las soluciones deben
evaluarse bajo los mismos
criterios de evaluación
– se deben considerar las
ventajas y desventajas de
cada alternativa de solución
El esfuerzo de solución: Paso 7
137
• Paso 8: seleccionar la mejor
solución
– Existen tres formas para determinar
la mejor alternativa: análisis, juicio y
negociaciones
– El énfasis en el desarrollo de los SI
se basa en el análisis, sin ignorar del
todo el juicio y la negociación
El esfuerzo de solución: Paso 8
138
• Paso 9: implementar la solución
– normalmente requiere de ciertos conocimientos
técnicos o especializados que son realizados por
terceros
• Paso 10: asegurarse que la solución es efectiva
– cuando la solución no cumple con los objetivos de
desempeño del sistemas es necesario retomar los
pasos necesarios y determinar donde estuvo el error
– se reconsideran los pasos necesarios
– se repite este proceso hasta que la solución se
alcance
El esfuerzo de solución: Pasos 9
y 10
139
La visión de sistemas y la toma
de decisiones
Fase Paso Decisión
4 ¿Dónde está el problema?
¿Se deben recolectar nuevos datos o ya existen?Esfuerzode
definición5 ¿La recolección de datos fue exitosa y suficiente?
¿Cuál es la causa del problema?
6 ¿Cuántas alternativas se deben identificar?
¿Estas alternativas son factibles?
7 ¿Qué criterios se deben utilizar?
¿Todos los criterios tienen el mismo peso?
8 ¿Existe información suficiente para la selección?
9 ¿Cuándo se debe implementar la solución?
¿Cómo se debería implantar la solución?
Esfuerzode
solución
10 ¿Quién debe desempeñar la evaluación?
¿Qué tan bien la solución cumple los objetivos?
140
ENFOQUES DE DESAROLLO
DE LOS SI
LOS SISTEMAS SUAVES DE
CHECKLAND: UNA
METODOLOGÍA PARA LOS
ESFUERZOS DE SOLUCIÓN Y
DE DEFINICIÓN (1)
141
La visión de Checkland
• Reconoce que las
personas tienen
diferentes percepciones
de los problemas y del
sistema en el cual se
desempeñan: los
problemas son difusos
142
Las 5 premisas de Checkland
Peter Checkland
No existen los problemas objetivos.
Diferentes personas ven diferentes
problemas en la misma situación
Si los problemas dependen del intelecto humano,también las soluciones dependen de él:
si se está de acuerdo con los problemas se estáen desacuerdo con la solución
Muy rara vez los
problemas se presentan
de forma individual,
ni de forma empaquetada,
ni listos para la soluciónEl área problema se debe
investigar y analizar antes de
tomar cualquier decisión sobre
tecnologías computacionales
El analista no se puede divorciar
del sistema y los participantes
143
El enfoque de Checkland: la metodología
144
La situación del problema (1)
La situación del
problema
El analista tiene que
familiarizarse con la
situación del problema.
Se debe hacer un intento
de construcción de una
rich picture
Una rich picture es una caricatura de
los constituyentes y sus relaciones de la
situación del problema
La información
suave y dura debe
de ser recolectada
Incluir las
preocupaciones,
temores y
aspiraciones de los
participantes
Incluir alianzas entre
departamentos o
individuos, así como
deseos y
presentimientos
El analista debe buscar por estructura,
procesos clave, y la interacción entre los
procesos y estructura
El analista no debe
imponer algún tipo de
configuración del
sistema en este nivel
Imponer una
configuración del
sistema puede limitar
los tipos de cambios
que se podrían sugerir
145
El propósito de una rich picture es:
Ayudar a visualizar la
complejidad de la
interacción entre las
personas, roles, hechos,
observaciones, etc
Evitar la imposición
de una estructura
rígida en la
apreciación del
problema
Evitar llevar a cabo
investigaciones
inútiles sobre el
entendimiento del
problema
Actuar como una
herramienta de
comunicación
entre los
participantes
La situación del problema (2)
146
IDENTIFICAR 3
PERSONAJES
IMPORTANTES
1. El resolvedor
del problema:
el analista
2. El cliente: la
persona que paga al
analista
3. El poseedor del problema: la
persona o área donde surge el
problema
La situación del problema (3)
147
DATOS DEL
EQUIPO Y
DEL
SOLICITANTE
DIAGNOSTIC
OSE REPARA
GARA
NTIA
Contacta con
el proveedor
GARA
NTIA
J E F E
Servicio social de apoyo
TECNICO
PRUEVA EQUIPO
Al ingresar el equipo
el técnico pregunta
por la fecha de
compra y define si
está en garantía o
no. Si está hace una
relación e informa al
jefe. El equipo sin
garantía pasa
directamente al
diagnostico.
Después el equipo
es diagnosticado y
se determina si la
reparación es
viable para ser
reparada en las
instalaciones. Se
informa al jefe. Al jefe se le informa
del diagnostico y si se
cuenta con las
refacciones necesarias.
Cuando existen
las refacciones
el equipo es
reparado. En
dicha
reparación
interviene el
técnico y el
servicio social
de apoyo.
Informa de las
refacciones que no
hay en almacén de
las oficinas
Checa en una lista
almacenada en una hoja
de exel la existencia de
las refacciones y las
entrega al técnico
Charly se encarga
de solicitar las
facturas para
comprobar que
los equipos estén
en garantía al
almacén central o
a compras
Charly se encarga de preparar el
equipo que está en garantía y el que
no se puede reparar, prepara la
salida del mismo para que el
proveedor venga por el o Charly lo
envía personalmente
Es el equipo recibido que no
cumplió con garantía y no
pudo ser reparado por falta
de dinero o porque ya no tiene
reparación.
El equipo sin
No. De
inventario es
regresado
por no ser
patrimonio
de la
institución
Charly solicita
las refacciones
cuando no hay
en existencia
Cuando el equipo
es ingresado
después de ser
reparado o
validado por el
proveedor, se
prueba antes de
ser entregado al
usuario. Si el
equipo falla
nuevamente se le
regresa al
proveedor.
El técnico se
encarga de
coordinar las
actividades del
servicio social de
apoyo. Ellos están
involucrados
tanto en la
reparación de los
equipos, la
instalación de
periféricos y
consumibles y en
ocasiones del
diagnostico.
EL PROCESO EN SI:Un ejemplo de rich picture. Cortesía de
María Luisa Serrano
148
La definición del sistema
relevante (1)Visualizar al problema desde el punto de vista sistémico:
De aquí surge la idea de sistema relevante
El sistema
relevante se extrae
de la rich picture,
y no siempre es
claro cuál es el
sistema relevante
No existe una respuesta exacta a la pregunta
¿qué o cuál es el sistema relevante?
149
La sugerencia más aceptada es: acordarlo vía la negociación, esto es a
menudo entre el poseedor y el resolvedor del problema
EL SISTEMA
RELEVANTE
Adentrarse más a la
situación del problemaEs lo más apropiado para
estimular el
entendimiento y el
cambio en la
organización: el objetivo
final de la metodologíaSe basa en las
tareas
fundamentale
sSu esencia está en
desarrollar una
definición de raíz
Producir una
definición de raíz
no es una tarea
mecánica. Solo se
puede definir por
prueba y error
La definición del sistema
relevante (2)
150
• Sin embargo existe una
lista llamada
CATWOE que debe
satisfacer toda
definición de raíz
• Todas las componentes
de CATWOE deben
estar presentes (la
ausencia de una de ellas
requiere de una
justificación)
• Clientes: personas o grupo de personas que
son servidas o que se benefician del sistema
• Actores: personas o tipo de personas que
llevan a cabo las actividades esenciales dentro
del sistema relevante
• Proceso de Transformación: esto es lo que el
sistema realiza (el proceso que convierte inputs
en outputs
• Visión panorámica (Weltanschauung: world
view) relevante al sistema
• Dueños (Owners): personas para las cuales el
sistema es un respuesta. Ellos tienen el poder
de cambiar el sistema o hacer que deje de
existir
• Entorno: es donde el sistema se localiza
La definición del sistema
relevante (3)
151
Modelos conceptuales (1)
Modelo conceptual: modelo lógico de las actividades o procesos clave que
se deben llevar a cabo con el fin de satisfacer la definición de raíz del
sistema
No es un modelo del mundo real:
más bien consiste de lo que
lógicamente es requerido por la
definición de raíz
Cuando el modelo está completo, debe de probarse con el fin
de que cumpla con el modelo general del sistema
152
Las preguntas
típicas que se
deben hacer son:¿El modelo ilustra
una actividad que
tiene algún propósito
de continuidad?
¿Existe alguna
medida de
desempeño?
¿Existe algún
proceso de toma
de decisiones?
¿Existen
subsistemas
conectados?
¿Existe alguna frontera?
¿Existe garantía de
estabilidad a largo
plazo?
Modelos conceptuales (2)
153
Comparación del modelo
conceptual con el problema (1)
Rich Picture
vs.
Problema
Las diferencias deben
ser resaltadas como
posibles puntos de
discusión
• ¿Porqué existe una discrepancia entre el
modelo conceptual y el mundo real?
• ¿Las actividades generadas por el modelo
conceptual suceden en el modelo real?
154
Comparación del modelo
conceptual con el problema (2)
• No se debe criticar la forma en
que actualmente se llevan a cabo
las cosas, sino que debe de
crearse una lista de tópicos: una
agenda para el cambio
• La agenda para el cambio debe
ser discutida con los actores en la
situación del problema
155
Cambios factibles y deseables
Establezca debates como ejercicio para adentrase
más en la situación
El analista debe dirigir las
discusiones hacia los cambios que
son sistemáticamente deseables y
culturalmente factibles
Las discusiones no deben
ignorar la cultura
organizacional dentro dela cual
los participantes han vivido y
trabajado
156
Acciones para mejorar la
situación del problemaCheckland no es muy específico en como se debe
llevar a cabo esto
Peter Checkland
Cambios en
las políticas,
estrategias
o procedimientos se
deben acordar
El resultado del
debate de la agenda debe
ser un acuerdo para
cambiar las actitudes
dentro de la situación del
problema
157
Observaciones sobre la
metodología
• Los pasos anteriores no necesariamente se tienen que
llevar a cabo de forma secuencial
• A menudo es necesario retomar un paso anterior para
su revisión
• Es un error pensar que después de que todos los pasos
han sido cubiertos el problema quede del todo claro
• No es una metodología para resolver problemas, sino
que ayuda a mejorar la visión del problema a través
del entendimiento organizacional, el aprendizaje y el
cambio
158
Critica a la metodología de
Checkland
• No es comprensible del todo, principalmente en los
últimos pasos
• Es fuerte en los primeros pasos
• Se considera más como una metodología de
entrada (front-end) para llevar a cabo el análisis de
problema y es previa al análisis técnico que
conduce a un SI computarizado
• No es conocida por todos los diseñadores de
sistemas
159
ENFOQUES DE DESAROLLO
DE LOS SI
LOS MAPAS MENTALES:
UNA TÉCNICA PARA LOS
ESFUERZOS DE SOLUCIÓN
Y DE DEFINICIÓN (2)
160
Introducción
• Un mapa mental representa lo que
se encuentra en la mente de una
persona acerca de un tópico
particular
• Un mapa mental contiene
palabras clave, símbolos, y
figuras conectadas por líneas
• La forma, el color, y el contenido
de un mapa mental debe ser fácil
de recrear y de recordar
161
Definición
• Un mapa mental:
– es un diagrama que por medio de colores,
lógica, ritmo visual, números, imágenes y
palabras clave, reúne los puntos
importantes de un tema
– indica, de forma explícita, la forma que
éstos elementos se relacionan entre sí
• Equivale a conseguir en un diagrama
no lineal una réplica de la forma
natural de pensar
162
Un mapa mental
163
Leyes de diagramación mental
• Iniciar siempre el trazo de
un mapa mental con una
imagen central que
involucre por lo menos
tres colores
• Conectar tantas
ramificaciones a la
imagen central como sea
necesario; añadir grosor a
las ramas principales a fin
de enfatizarlas
• Elegir únicamente
palabras o imágenes
clave
• Utilizar imágenes a todo
lo largo del mapa mental
• Agregar símbolos,
flechas y colores a fin de
establecer conexiones y
asociaciones entre los
diferentes elementos
• Utilizar ayudas
dimensionales
164
Tipos de mapas mentales
• Mapa mental de generación de ideas o creativo
– organiza las ideas propias
– profundiza en conocimientos y experiencia previos a fin
de reorganizarlos y observarlos desde una nueva
perspectiva
– facilita el pasar a la acción
• Mapa mental a partir de ideas predeterminadas
– organiza las ideas propias o ajenas
– parte de cualquier clase de conocimiento o experiencia
previos a fin de transformarlos en una réplica con
estructura funcional
165
• Reunir materiales: colores,
marcadores, bolígrafos y
papel (éste colocarlo de
forma horizontal)
• Determinar el foco o el tema
deseado en forma de imagen
• Añadir varios pares de ramas
conectadas a la imagen
central
• A fin de evitar bloqueos
añadir abundantes
ramificaciones
Creación de un mapa mental de
generación de ideas o creativo
• Utilizar una palabra o imagen
clave para representar cada idea
• Comenzar a diagramar lo más
rápido posible con el fin de que
las ideas asociadas a la imagen
fluyan y se sucedan unas tras
otras sin intentar organizarlas
• Repetir el proceso cuanto sea
necesario
• Utilizar una palabra o imagen
clave sobre cada rama
166
Creación de un mapa mental a
partir de ideas predeterminadas
• Reunir material y poner al
alcance el material
preseleccionado (apuntes,
libro, investigaciones, etc.
• Seleccionar el tópico,
materia, o problema a ser
diagramado y crear la imagen
central
• Agregar ramificaciones a esta
imagen central y se le da
grosor para destacar su
importancia
• Añadir las ideas básicas a
manera de encabezados sobre
las ramas principales
• En el extremo de las ramas
gruesas agregar ramas más
delgadas. A éstas se le
asocian los subtemas
• Añadir más colores y más
imágenes para destacar ideas
• Utilizar flechas, símbolos y
códigos propios para asociar
ideas y favorecer conexiones
167
Apartados de código
• Son claves propias que, en forma
de taquigrafía mental, ilustran
asociaciones entre
– la información evitando la
redundancia de las palabras
– términos
– flechas conectoras
• Son fundamentales en la
estrategia de construcción del
mapa mental
168
Un mapa mental para la
organización de software
169
Mapa mental para la estructura
de una página Web
170
Mapa mental de un manual de
software
171
Mapa mental para la página
www.openeng.com
172
GUÍA PARA ELABORAR
POLÍTICAS Y PROCEDIMIENTOS:
UNA TÉCNICA PARA LOS
ESFUERZOS DE SOLUCIÓN Y
DEFINICIÓN (3)
ENFOQUES DE DESAROLLO
DE LOS SI
173
Política
• Una política es:
– Una decisión unitaria que se aplica a todas las
situaciones similares
– Una orientación clara hacia donde deben dirigirse todas
las actividades de un mismo tipo
– La manera consistente de tratar a las entidades
– Un lineamiento facilita la toma de decisiones en
actividades rutinarias
– Lo que la dirección desea que se haga en cada situación
definida
– Aplicable al 90-95% de los casos. Las excepciones
deben ser autorizadas por alguien de nivel superior
174
Proceso, método y
procedimiento
• Proceso
– Conjunto de elementos que interactúan para
transformar insumos, en bienes o productos terminados
– Está formado por materiales, métodos, procedimientos,
recursos humanos y materiales, y el entorno
• Método
– Guía detallada que muestra secuencial y ordenadamente
como una entidad realiza un trabajo
• Procedimiento
– Guía detallada que muestra secuencial y ordenadamente
como dos o más entidades realizan un trabajo
175
Documento controlado
• Es toda aquella política o procedimiento que se ha
formalizado dentro del sistema a través de
asignarle un código e incluirla(o) dentro de los
manuales de políticas y procedimientos
176
Contenido del manual de
políticas y procedimientos
• Propósito
• Alcance
• Definiciones
• Responsable de la revisión de la política o
procedimiento
• Revisión de la política o procedimiento
• Documentos aplicables y/o anexos
• Diagrama de flujo
• Procedimiento
• Lista de distribución
177
Propósito
• Es la explicación funcional de lo
que se pretende alcanzar con la
aplicación de la correspondiente
política o procedimiento
• Muestra de manera clara, precisa y
sin ambigüedades, lo que se está
buscando alcanzar con la
implantación de dicha política o
procedimiento
• Debe redactarse en un máximo de
un párrafo
178
Alcance
• Es el campo de acción
sobre el cual la política o
procedimiento tendrá
injerencia
• Muestra los límites dentro
de los cuales se aplicará la
política o procedimiento
• Muestra donde inician y
terminan las actividades,
responsabilidades y
funciones involucradas
• Tiene que ver directamente
con el nombre de la política o
procedimiento y se relaciona
principalmente con personas,
productos, procesos, áreas,
máquinas, turnos, etc.
• No se refiere a las personas
involucradas en la política o
procedimiento, sino a la
definición de los casos en que
se utilizará esta política o
procedimiento
179
Definiciones
• Son las explicaciones a los términos, abreviaturas o
símbolos utilizados en los documentos controlados,
con el propósito de estandarizar el lenguaje utilizado
dentro del sistema
• Se requieren cuando los términos que se manejan son
poco usuales o su uso cotidiano es indiscriminado y
cada quien los utiliza para designar diferentes cosas
• Deben ser desarrolladas en consenso con los usuarios
de los términos o conceptos correspondientes
180
Responsable de la revisión de la
política o procedimiento
• Es la persona encargada de
editar, revisar y actualizar
periódicamente el documento
controlado que se le ha
asignado, así como los
anexos allí incluidos
• No necesariamente es la
persona que elaboró el
documento
– es la persona con mayor
afinidad entre las funciones de
su puesto y la descripción de la
política o procedimiento
• Es la persona quien tiene la
autoridad formal para
asegurar que haya
congruencia entre lo que se
dice y lo que se hace
• Al referirse a él se debe
hacer mención de su puesto
y no a su nombre de pila
– debe decir gerente de ventas,
jefe de diseño gráfico, gerente
general, supervisor de
producción, etc.
181
Revisión de la política o
procedimiento
• Consiste en definir la periodicidad, la frecuencia y
los casos en que se deberá hacer una revisión
formal para mejorar las políticas o procedimientos
• La política general de revisión es llevar a cabo ésta
cada vez que haya modificaciones en el sistema
182
Documentos aplicables y/o
anexos
• Son aquellas fuentes de
información
complementarias y de
apoyo que sirven de
referencia a una política
o procedimiento
• No es necesario que se
agreguen en los
documentos
controlados
183
Diagrama de flujo:
consideraciones generales
• Sólo se utilizan para el
desarrollo de
procedimientos, no para el
desarrollo de políticas
• Es una gráfica que
muestra la secuencia
ordenada de actividades a
seguir en el procedimiento
y la interrelación que
existe entre las entidades
• Es necesario tenerlo
terminado antes de iniciar
con el desarrollo del
procedimiento
• Permite visualizar todo el
flujo de información y el
contexto del
correspondiente evitando
así las duplicidades de
funciones y las actividades
que no agregan valor al
sistema
184
Diagrama de flujo: simbología
Proceso o actividad
Decisión binaria
Terminal: principio
o final
Conector: indica
continuidad del
diagrama de flujo
Documento generado
por el proceso
Datos
Proceso alternativo
Multidocumento
y/o
Intercalar
Almacenamiento
de acceso secuencial
Disco
magnético
Almacenamiento
de acceso directo
Ordenar
Extracto
Combinar
185
Procedimiento y lista de
distribución
• Procedimiento
– Guía detallada que muestra secuencialmente como dos
o más entidades realizan su trabajo
• Lista de distribución
– Es la lista de las áreas que utiliza o pueden utilizar la
política o procedimiento
186
EL PAPEL DEL ANALISTA
DE SISTEMAS EN LAS
ORGANIZACIONES
ENFOQUES DE DESAROLLO
DE LOS SI
187
El papel cambiante de los
personajes en los SI (1)
usuario programador computadora
usuario programador computadoraoperador
usuario programador computadoraoperadoranalista
desistemas
188
El papel cambiante de los
personajes en los SI (2)
usuario programador computadoraoperadoranalista
desistemas
administradorde basesde datos
administradorde redes de
computadoras
especialistaen basesde datos
especialistaen redes de
computadoras
189
Responsabilidades del analista
(1)
• Entender y comunicarse con los usuarios para establecer sus
requerimientos
• Tener un conocimiento experto de las computadoras
• Ser un buen comunicador
• Pensar en términos del punto de vista del usuario así como
del programador
• Proporcionar especificaciones al programador
• Investigar y analizar los sistemas existentes así como la
utilización de la información y los requerimientos
190
Responsabilidades del analista
(2)
• Juzgar cuándo es factible desarrollar un SI para el
área de estudio
• Diseñar el nuevo sistema, especificar los
programas, el hardware, los datos, las estructuras,
el control, y otros procedimientos
• Probar y evaluar la instalación del nuevo sistema,
supervisar la generación de documentos que
describan su funcionamiento y desempeño
191
Características del analista
• El analista:
– puede provenir de áreas técnicas o de negocios
– debe poseer un grado académico o ser un profesional calificado
– puede surgir del área de programación
– debe observar el entorno y las prácticas laborales del área
dentro de la cual el SI será utilizado
– debe manejar conflictos diplomáticamente
– debe tener habilidades administrativas
– debe mostrar creatividad y tener la habilidad de pensar
lateralmente
– debe transpirar confianza y controlar su entusiasmo
192
Características del analista (2)
En pocas palabras, el analista debe ser un:
193
El papel del analista
194
El comité directivo de SI
• Lleva a cabo tres funciones principales:
– establecer políticas que aseguren el soporte computacional
para alcanzar los objetivos estratégicos de la organización
– tener funciones de control y auditoria en todos los
aspectos de creación de los SI
– resolver conflictos que surjan en la creación y utilización de
los SI
• Está formado por
– miembros permanentes (ejecutivos de la organización)
– miembros temporales (administradores de bajo nivel y
consultores)
195
El equipo de desarrollo
• Equipo de desarrollo
– la parte del comité directivo de SI que está
relacionado con los detalles de desarrollo
– consiste en una combinación de usuarios,
especialistas de la información, especialistas en
cómputo, y un auditor interno
• Las actividades del equipo de desarrollo
está dirigido por un líder de proyecto quien
provee dirección a través del desarrollo del
SI
196
EL CICLO DE VIDA DE LOS
SI
DESARROLLO DE SI
COMPUTARIZADOS
197
Las fases del ciclo de vida
• En muchos aspectos cada SI es similar a un
organismo vivo: nace, crece, madura, muere
• Este proceso evolutivo se llama ciclo de vida de
los SI, y consiste de las siguientes fases:
– planeación
– análisis
– diseño
– implementación
– utilización
198
El patrón circular del ciclo de
vida
La fase de
implementación
La fase de
utilizaciónLa fase de
planeación
La fase de
análisisLa fase de
diseño
199
Papel de poseedor del problema y del analista de sistemas
Fase
Planeación
Análisis
Diseño
Implementación
Utilización
Poseedordel problema
Definir el
problema
Controlar
Controlar
Controlar
Controlar
Analista desistemas
Soporte
Conducir elestudio
del sistema
Diseñar el sistema
Implementarel sistema
Hacer viableel sistema
200
DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE PLANEACIÓN
201
Beneficios de la planeación
• Tanto el comité directivo de SI y el equipo de
desarrollo deben buscar los siguientes beneficios
– definir el alcance del proyecto
– encontrar las áreas problemáticas potenciales
– definir la sucesión de tareas
– proporcionar bases para el control
• El poseedor del problema debe invertir tiempo en
la planeación con la mentalidad de que ésta
proporcionará dividendos más tarde en el ciclo de
vida
202
La fase de planeaciónCOMITÉ DIRECTIVO
DE SIPOSEEDOR DEL
PROBLEMAANALISTA DE
SISTEMAS
Establecer un mecanismo de control
Aprobar o desaprobar el estudio del proyecto
Prepara unapropuesta para el
estudio del sistema
Conducir un estudiode factibilidad
Identificar lasrestriccionesdel sistema
Definir los objetivosdel sistema
Definir elproblema
Reconocer laexistencia del
problema
Consultar
203
El estudio de factibilidad
• Está compuesto por los factores principales que
afectan directamente al sistema en el
cumplimiento de sus objetivosFactibilidad técnica
hardwaresoftware
Factibilidad legaly ética
204
Perfil para la propuesta de
estudio del sistema
1. Resumen ejecutivo2. Introducción3. Objetivos del sistema y restricciones4. Posibles sistemas alternativos5. El proyecto recomendado de estudio del sistema
5.1 Tareas por realizarse5.2 Requerimientos de recursos humanos5.3 Calendarización del trabajo5.4 Costo estimado
6. Impacto esperado del sistema6.1 Impacto en la estructura de la organización6.2 Impacto en las operaciones de la organización6.3 Impacto en las bases de la organización
7. Plan general de desarrollo (análisis, diseño, e implementación)
8. Resumen
205
Aprobar o desaprobar el estudio
del proyecto
• Preguntas típicas:
– ¿el sistema propuesto cumplirá con sus objetivos?
– ¿es el estudio del proyecto la mejor forma de conducir
el análisis del sistema?
• Si la respuesta a estas preguntas es afirmativa
entonces se continua con el estudio
• Si la respuesta es negativa repetir nuevamente el
proceso o abandonar el proyecto
206
Ejemplo de calendarizaciónSistema funcional: Ventas
Subsistema: ProductoModelo: Eliminación de producto
Subtarea ResponsabilidadTiempo estimado(personas-mes)
1. Identificar el criterio
de eliminación
2. Identificar los
requerimientos de la
información de salida
3. Identificar los
requerimientos de los
datos de entrada
4. Preparar la
documentación del
nuevo sistema
5. Diseñar la red
6. Diseñar la base de datos
7. Revisar el diseño
8. Preparar la
documentación del programa
9. Codificar el programa
10. Probar el programa
11. Aprobar el programa
12. Preparar la BD
13. Capacitar a los usuarios
14. Terminar el modelo
Analista de sistemas
Administrador de producto
Analista de sistemas
Administrador de producto
Especialista en redes
Analista de sistemas
Administrador de bases de
datos
Analista de sistemas
Especialista en redes
Administrador de BD
Analista de sistemas y AP
Programador
Programador
Programador y staff de oper.
AP y VP de ventas
Administrador de BD
Analista de sistemas
Staff de operaciones
0.75
0.25
0.50
2.00
1.50
0.50
0.25
1.00
1.25
0.75
0.50
2.00
0.50
0.75
207
DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE ANÁLISIS
208
Análisis de sistemas
• Es el estudio de un sistema existente con el
propósito de diseñar uno nuevo o mejorado
• Durante esta fase el analista de sistemas continúa
el trabajo con el poseedor del problema, mientras
que el comité directivo de sistemas sigue tomando
el papel de decisión en los puntos cruciales
209
La fase de análisisCOMITÉ DIRECTIVO
DE SIPOSEEDOR DEL
PROBLEMAANALISTA DE
SISTEMAS
Aprobar o desaprobar el proyecto de diseño
Anunciar el estudio del sistema
Organizar el equipo de desarrollo
Definir las necesidades de información
Definir los criterios de desempeño
Preparar lapropuesta de
diseño
210
Anunciar el estudio del sistema
• Siempre se requiere la cooperación de todos los recursos
humanos de la organización (en menor o mayor grado)
• El principal problema es cómo el nuevo SI afecta a su
empleo
• Este problema se puede combatir si se anuncia
– a los empleados las razones claras para la creación del sistema
– cómo el nuevo sistema beneficiará tanto a la organización
• Deben existir reuniones personales y grupales, así como
comunicados por diversos medios
211
Perfil para la propuesta de
diseño1. Resumen ejecutivo2. Introducción3. Definición del problema4. Objetivos y restricciones del sistema5. Criterios de desempeño6. Posibles sistemas alternativos7. El proyecto recomendado de diseño
7.1 Tareas por realizarse7.2 Requerimientos de recursos humanos7.3 Calendarización del trabajo5.4 Costo estimado
8. Impacto esperado del sistema8.1 Impacto en la estructura de la organización8.2 Impacto en las operaciones de la organización8.3 Impacto en las bases de la organización
9. Plan general de desarrollo (análisis, diseño, e implementación)
10. Resumen
212
DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE DISEÑO
213
Diseño de sistemas
• Es la determinación de los procesos y los datos
que se requieren para el nuevo sistema
• Si el SI se basa en computadoras, entonces el
diseño incluye una especificación de los tipos de
equipos que se utilizaran
• En esta fase del ciclo de vida, el analista de
sistemas tiene una responsabilidad mayor
214
La fase de diseñoCOMITÉ DIRECTIVO
DE SIPOSEEDOR DEL
PROBLEMAANALISTA DE
SISTEMAS
Aprobar o desaprobar laimplementación del sistema
Preparar lapropuesta de
implementación
Seleccionarlas mejor
configuración
Evaluar lasconfiguraciones
alternativasdel sistema
Determinarconfiguraciones
alternativasdel sistema
Preparar el diseño detallado
del sistema
Controlar
215
Preparar el diseño detallado del
sistema
HERRAMIENTAS DEDOCUMENTACIÓN
Modelado dedatos
Diagramas entidad-relación
Diccionario de datos
Impresión en papelo en pantalla
Modelado deprocesos
Diagramas de flujodel sistema y delprograma
Diagrama de flujode datos
Pseudocódigo
Modelado deobjetos
Relaciones entreobjetos
Especificación declases
216
Cuadro comparativo de
metodologíasMetodología Razones del
desarrolloAyuda
otorgadaÁrea Método Palabras
claves /conceptos
Tradicional Necesidad desistematizarel análisis yel diseño
Desarrollo deun sistemade proc. dedatostécnicamenteeficiente
Funciones,subsistemas
Represent.precisa de lasfunciones delsistema vía ladivisión yoptimizaciónde lassubfunciones
Diagramasde flujo,matrices deentrada-salida,formas dedescripcióndocumentada
Estructurada Fallas en eldesarrollo desistemasgrandes y lafalta dehabilidadparacoordinarequipos deprog.
Desarrollo deun sistematécnicamenteintegrado ymodular
Funciones,sistemastotales
Desarrollo deun modelológicohaciendoénfasis enfunciones,procesos yflujos dedatos
Diagramasde flujos dedatos,diccionario dedatos
Análisis dedatos
Desarrollo ycrecienteimportanciade latecnología deBD
Desarrollo deunaestructura deBD adecuadapara soportarlasaplicacionescambiantes
Estructurasde datosorganizacionales
Desarrollo deun modelo dedatos lógicocon énfasisen entidades,relaciones yestructurasde datos
Modelosentidad-relación
Checkland Fallas en lasolución deproblemasdifusos
Entendimien-to de losproblemasorganizacio-nales
Sistemasdifusos
Desarrollo deun modeloconceptualde unsistema ideal
Rich pictures,CATWOE,agenda parael cambio
217
Perfil para la propuesta de
implementación
1. Resumen ejecutivo2. Introducción3. Definición del problema4. Objetivos y restricciones del sistema5. Criterios de desempeño6. Diseño del sistemas
6.1 Descripción sumaria6.2 Configuración del equipo
7. El proyecto recomendado de implementación7.1 Tareas por realizarse7.2 Requerimientos de recursos humanos7.3 Calendarización del trabajo5.4 Costo estimado
8. Impacto esperado del sistema8.1 Impacto en la estructura de la organización8.2 Impacto en las operaciones de la organización8.3 Impacto en las bases de la organización
9. Plan general de implementación10. Resumen
218
DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE
IMPLEMENTACIÓN
219
Implementación
• Es la adquisición e integración de las fuentes
conceptuales y físicas que producen al sistema
• En esta fase se requiere la participación de las tres
entidades:
– el comité directivo de SI
– el poseedor del problema
– el analista de sistemas
220
La fase de implementaciónCOMITÉ DIRECTIVO
DE SIPOSEEDOR DEL
PROBLEMAANALISTA DE
SISTEMAS
Aprobar o desaprobar la propuesta de terminación
Capacitar a losparticipantes
y usuarios
Preparar lasfacilidades físicas
Preparar labase de datos
Obtener elsoftware
Obtener elhardware
Controlar
Plan de implementación
Anunciar la implementación
Controlar
Preparar lapropuesta determinación
Terminar el nuevo sistema
221
Perfil para la propuesta de
requerimientos (RFP)
1. Carta de petición
2. Objetivos del sistema y restricciones aplicables
3. Diseño del sistema3.1 Descripción sumaria
3.2 Criterios de desempeño
3.3 Configuración del equipo
3.4 Documentación sumaria del sistema
3.5 Volumen estimado de transacciones
3.6 Tamaño estimado de los archivos
4. Itinerario de instalación
222
DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE UTILIZACIÓN
223
La fase de utilizaciónCOMITÉ DIRECTIVO
DE SIPOSEEDOR DEL
PROBLEMAANALISTA DE
SISTEMAS
Aprobar o desaprobar lapropuesta de reingeniería
Preparar lapropuesta dereingeniería
Darmantenimiento
al sistema
Auditar elsistema
ControlarControlar
224
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
INTRODUCCIÓN
225
Consideraciones preliminares
(1)
• Todo esfuerzo en el desarrollo de SI conlleva un
ciclo de vida
• Un modelo de ciclo de vida es un modelo
prescriptivo de lo que pasaría entre la primera idea
y el funcionamiento del sistema
• Existen varios modelos del ciclo de vida
• El modelo de ciclo de vida apropiado puede
orientar el proyecto y ayudar a asegurar que cada
paso se acerque más a la consecución del objetivo
226
• Dependiendo del modelo de ciclo de
vida seleccionado
– se puede aumentar la velocidad de
desarrollo
– mejorar la calidad, el control y el
seguimiento del proyecto
– minimizar gastos y riesgos
– mejorar las relaciones con el usuario
Consideraciones preliminares
(2)
227
• La selección ineficaz de un modelo de
ciclo de vida puede ser una fuente
constante de
– ralentización del trabajo
– trabajo repetitivo, innecesario y frustrante
• Se pueden producir estos últimos
efectos si no se elige un modelo de
ciclo de vida
Consideraciones preliminares
(3)
228
ciclos de vida
en el desarrollo
de SI
cascada pura codificar y
corregir
espiral
cascadas
modificadas
prototipo
evolutivoentrega por
etapas
diseño por
planificación
entrega
evolutiva
diseño por
herramientas
software
comercial
existente
Diferentes tipos de ciclos de vida
229
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
CASCADA PURA
230
• Es el predecesor de todos los modelos de
ciclo de vida y ha servido de base para
otros modelos
• En este modelo, un proyecto progresa a
través de una secuencia ordenada de etapas,
partiendo desde su concepto inicial hasta la
prueba del mismo
• El proyecto realiza una revisión al final de
cada etapa para determinar si está
preparado para pasar a la siguiente
El modelo de cascada pura
231
Implementación
Utilización
Planeación
Análisis
Diseño
Gráfica del modelo de cascada
pura
232
Ventajas del modelo de Cascada
Pura (1)
• Se utiliza correctamente para ciclos en los que
– se tiene una definición estable del producto
– cuando se esta trabajando con metodologías y técnicas
conocidas
• Puede constituir una elección correcta para el
desarrollo rápido cuando se está
– construyendo una versión de mantenimiento bien
definida de un producto existente
– migrando un producto existente a una nueva plataforma
• Ayuda a minimizar los gastos de la planificación
porque permite realizarla sin problemas
233
Ventajas del modelo de cascada
pura (2)
• Funciona bien
– con proyectos complejos bien definidos
• debido a que se pueden obtener beneficios al enfrentarse a la
complejidad de forma ordenada
– cuando los requerimientos de calidad dominan sobre los
de costos y de planificación
• Evita una fuente común de errores importantes
– eliminando los cambios que se pueden producir a
medio camino
• Presenta el proyecto con una estructura que ayuda
a minimizar el esfuerzo inútil
234
Desventajas del modelo de
cascada pura (1)
• Dificultad para especificar
claramente los requerimientos al
comienzo del proyecto (no
permite flexibilidad en los
cambios)
• Para un proyecto de desarrollo
rápido, el modelo de cascada
puede suponer una cantidad
excesiva de documentación
235
Desventajas del modelo de
cascada pura (2)
• Si se intenta mantener la flexibilidad, la
actualización de la especificación se puede
convertir en un trabajo a tiempo completo
• No es imposible volver atrás utilizando el
modelo de cascada pura, pero si difícil
• Genera pocos signos visibles de progreso
hasta el final
– esto puede dar la impresión de un desarrollo
lento, incluso sin ser verdad
236
Observaciones al modelo de
cascada pura
• Es el modelo más conocido y ofrece una
velocidad de desarrollo aceptable en algunas
circunstancias
– otros modelos, sin embargo, proporcionan una
velocidad de desarrollo superior
• Los inconvenientes del modelo hacen que
sea, a menudo, poco apropiado para un
proyecto de desarrollo rápido
– incluso en los casos en los que las ventajas del
modelo superan los inconvenientes, los modelos
de cascada modificada pueden funcionar mejor
237
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
CODIFICAR Y CORREGIR
238
El modelo codificar y corregir
• Es un modelo poco útil, pero bastante común
• Si no se ha seleccionado explícitamente otro
modelo, por omisión se estará utilizando este
modelo
• Cuando se utiliza se empieza con una idea general
de lo que se necesita construir
– se puede tener una especificación formal, o no tenerla
– se utiliza cualquier combinación de diseño, código,
depuración y métodos de prueba no formales que sirven
hasta que se tiene el producto listo para entregarlo
239
Gráfica del modelo codificar y
corregir
codificar y
corregir
Especificación
del sistema
(quizás)
Entrega
(quizás)
240
Ventajas del modelo codificar y
corregir (1)
• No conlleva ninguna gestión
• No se pierde tiempo en
– la planificación
– en la documentación
– en el control de la calidad
– en el cumplimiento de los estándares
– en cualquier otra actividad que no sea la
codificación pura
241
Ventajas del modelo codificar y
corregir (2)
• Como se pasa directamente a
codificar, se pueden mostrar
inmediatamente indicios de
progreso
• Requiere poca experiencia:
cualquier persona que haya escrito
alguna vez un programa de
computadora está familiarizada con
el modelo de codificar y corregir
242
Desventajas del modelo codificar
y corregir
• Resulta peligroso para otro tipo
de proyectos que no sean
pequeños
• Aunque no suponga gestión
alguna, tampoco ofrece medios
de evaluación del progreso
– se codifica justo hasta que se
termina
• No proporciona medios de
evaluación de la calidad o de
identificación de riesgos
243
Observaciones al modelo
codificar y corregir
• Puede resultar útil para proyectos pequeños que se
intentan liquidar poco después de ser construidos
– programas pequeños de demostración de conceptos
– para demostraciones de duración corta
– prototipos desechables.
• No tiene cabida en un proyecto de desarrollo
rápido, excepto para estos pequeños proyectos
señalados
• Es un modelo no formal que se utiliza
normalmente porque es simple, pero no porque
funcione bien
244
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
ESPIRAL
245
El modelo de espiral
• Es un modelo orientado a riesgos que divide un
proyecto en miniproyectos
– cada miniproyecto se centra en uno o más riesgos
importantes hasta que todos éstos estén controlados
• El concepto ―riesgo‖ puede referirse a
– requerimientos y arquitecturas poco comprensibles
– problemas de ejecución importantes
– problemas con la tecnología subyacente
• Después de controlar todos los riesgos importantes,
el modelo finaliza del mismo modo que el modelo
de ciclo de vida en cascada
246
Planificación Análisis de riesgos
Evaluación del cliente Ingeniería
Recolección de requisitos y
planificación inicial del cliente
Planificación basada en los comentarios del cliente
Evaluación del cliente
Análisis de riesgo basado en los
requisitos iniciales
Análisis de riesgo basado en la reacción del
cliente
Prototipo inicial del software
Prototipo del siguiente nivel
Sistema de ingeniería
Hacia el sistema final
Gráfica del modelo de espiral
247
Combinaciones del modelo de
espiral
• Primera combinación
– iterar para reducir los riesgos hasta que se hayan
reducido a un nivel aceptable
– finalizar el esfuerzo de desarrollo con un ciclo de vida
en cascada u otro modelo de ciclo de vida no basado en
riesgos
• Segunda combinación
– se pueden incorporar otros modelos de ciclo de vida
como iteraciones dentro del modelo en espiral
• por ejemplo, una iteración de prototipado que permita la
investigación de alguno de los riesgos
248
Ventajas del modelo de espiral
(1)
• Mientras los costos suben, los riesgos
disminuyen
– cuanto más tiempo y dinero se emplee,
menores serán los riesgos
• que es exactamente lo que se quiere en un
proyecto de desarrollo rápido
• Proporciona al menos tanto control de
gestión como el modelo en cascada
tradicional
– se tienen los puntos de verificación al
final de cada iteración
249
• Como el modelo está orientado
a riesgos, proporciona con
anterioridad indicaciones de
cualquier riesgo insuperable
• Es posible descubrir si el
proyecto no se puede realizar
por razones técnicas u otras
razones
– y esto no supondrá un costo
excesivo
Ventajas del modelo de espiral
(2)
250
Desventajas del modelo de
espiral
• La única desventaja del modelo en
espiral es que se trata de un modelo
complicado
• Requiere de una gestión concienzuda,
atenta, y que exige conocimientos
profundos
• Puede ser difícil definir hitos objetivos
de comprobación que indiquen si está
preparado para pasar al siguiente nivel
de la espiral
251
Observaciones al modelo de
espiral
• El modelo de espiral es un modelo de ciclo de vida
orientado a riesgos
• Este se puede combinar con otros modelos de
ciclo de vida
• La principal ventaja de este modelo es que
mientras los costos suben, los riesgos disminuyen
252
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
CASCADAS MODIFICADAS
253
El modelo cascadas modificadas
• El mayor problema del modelo de cascada
pura es que trata las fases del ciclo de vida
como etapas secuenciales disjuntas
• Es posible corregir los inconvenientes más
importantes en el modelo de cascada pura
con pequeñas modificaciones
– puede modificarse de forma tal que las etapas se
solapen
– se puede reducir el énfasis sobre la
documentación
– se puede permitir más regresión
254
Variantes del modelo de
cascadas modificadas (1)
• Cascada con fases solapadas
– puede evitar algunos inconvenientes del
modelo de cascada pura al solapar sus etapas
• por ejemplo, sugiere que se debería tener bien
hecho el diseño global y quizás a medio hacer el
diseño detallado antes de considerar completo el
análisis de requerimientos
– puede reducir sustancialmente la
documentación necesaria entre etapas
255
Variantes del modelo de
cascadas modificadas (2)
• Cascada con subproyectos
– puede permitir la ejecución de algunas de
las tareas de la cascada en paralelo
(subproyectos), siempre que se haya
realizado una cuidadosa planificación
256
• Cascada con reducción de riesgos
– incorpora una espiral en lo alto de la cascada para
controlar el riesgo de los requerimientos
– incorpora una espiral para las demás etapas de
desarrollo
– a este nivel es posible
• desarrollar un prototipo de interfaz de usuario
• tener entrevistas con los usuarios
• observar cómo los usuarios interactúan con algún sistema
previo
• utilizar otros métodos que se consideren apropiados para la
identificación de los requerimientos
Variantes del modelo de
cascadas modificadas (3)
257
Planeación
Análisis
Diseño
Implementación
Utilización
Gráfica del modelo de cascada
con fases solapadas
258
Gráfica del modelo de cascada
con subproyectosPlaneación
Análisis
Diseño
Diseño detallado
Prueba del subsistema
Diseño detallado
Prueba del subsistema
Diseño detallado
Codificación y
depuración
Prueba del subsistema
Prueba del sistema
Codificación y
depuración
Codificación y
depuración
259
Planeación
Análisis
Diseño
Implementa
ción
Utilización
Gráfica del modelo en cascada
con reducción de riesgos
260
Desventajas de las variantes
• Modelo de cascada con fases solapadas
– debido al solapamiento entre las etapas, los hitos son
más ambiguos, y esto hace más difícil trazar el progreso
correctamente
– la realización de actividades en paralelo puede suponer
una mala comunicación, suposiciones incorrectas e
ineficacia
• Modelo de cascada con subproyectos
– presencia de interdependencias imprevistas
• Modelo de cascada con reducción de riesgos
– Ninguno
261
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
PROTOTIPADO
EVOLUTIVO
262
El modelo de prototipado
evolutivo (1)
• Es un modelo de ciclo de vida en el
que se desarrolla el concepto del
sistema a medida que avanza el
proyecto
• Normalmente se comienza
desarrollando los aspectos más
visibles del sistema
263
El modelo de prototipado
evolutivo
• Se presenta la parte ya desarrollada
del sistema al cliente y se continúa
el desarrollo del prototipo en base
la realimentación que se recibe del
cliente
• El ciclo continúa hasta que el
prototipo se convierte en el
producto final de ingeniería
264
Gráfica del modelo de
prototipado evolutivo
Inicio
ParadaPlaneación y análisis
Diseño
rápido
Construcción
del
prototipo
Evaluación del
prototipo por el
cliente
Refinamiento
del
prototipo
Producto
de
Ingeniería
265
• Cuando los requerimientos cambian con
rapidez
• Cuando el cliente es reacio a especificar
el conjunto de los requerimientos
• Cuando ni el analista ni el cliente
identifican de forma apropiada el área de
aplicación
• Cuando los desarrolladores no están
seguros de la arquitectura o los
algoritmos adecuados a utilizar
¿Cuándo utilizar el prototipado
evolutivo?
266
Desventajas del modelo de
prototipado evolutivo
• Imposibilidad de conocer al inicio del
proyecto lo que se tardará en crear un
producto aceptable
– incluso no se sabe cuántas iteraciones se
tendrán que realizar
– esta aproximación puede convertirse
fácilmente en una excusa para realizar el
desarrollo con el modelo de codificar y
corregir
267
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
ENTREGA POR ETAPAS
268
El modelo de entrega por etapas
(implementación incremental)
• El sistema se muestra al cliente en etapas
refinadas sucesivamente
• A diferencia del modelo de prototipado
evolutivo, se conoce exactamente qué es
lo que se va a construir cuando se procede
a construirlo
• Lo que hace diferente a este modelo es
que el sistema no se entrega como un todo
al final del proyecto, sino que éste se
entrega por etapas sucesivas a lo largo del
proyecto
269
Gráfica del modelo de entrega
por etapasplaneación
análisis
diseño
etapa 1: diseño, implementación, utilización
etapa 1: diseño, implementación, utilización
etapa 1: diseño, implementación, utilización
270
Ventajas del modelo de entrega
por etapas (1)
• Permite proporcionar una funcionalidad útil
en las manos del cliente antes de entregar el
100% del proyecto
• Con una planificación cuidadosa, es posible
entregar las prestaciones más importantes al
principio, y el cliente puede comenzar a
usar el sistema en ese punto
271
Ventajas del modelo de entrega
por etapas (2)
• Proporciona signos tangibles de
progreso en el proyecto, y se
generan con enfoques menos
incrementales
– estos signos de progreso pueden ser un
valioso aliado para mantener la presión
de planificación a un nivel apropiado
272
Desventajas del modelo de
entrega por etapas
• No funciona sin una
planificación adecuada tanto
para niveles técnicos como
para niveles de gestión
273
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
DISEÑO POR
PLANIFICACIÓN
274
El modelo de diseño por
planificación (1)
• Es similar al modelo entrega por etapas
– la diferencia radica en que no siempre se conoce al principio
si se tendrá el producto para la última entrega
• Se pueden tener cinco etapas planificadas
– pero sólo se llega a la tercera etapa debido a que se tiene
una fecha límite que no se puede cambiar
275
• Uno de los elementos críticos de este modelo es
priorizar los requerimientos y planificar sus etapas
– de tal forma que las primeras contengan los
requerimientos de mayor prioridad
– los requerimientos de baja prioridad se dejan para más
tarde
El modelo de diseño por
planificación (2)
276
Gráfica del modelo de diseño
por planificación Planeación
análisis
diseño
alta prioridad: diseño detallado, implementación, utilización
prioridad media-alta: diseño detallado, implementación, utilización
prioridad media: diseño detallado, implementación, utilización entrega
prioridad media-baja: diseño detallado, implementación, utilización
prioridad baja: diseño detallado, implementación, utilización
AGOTAMIENTO
DEL PLAZO O
DEL
PRESUPUESTO
277
Ventajas del modelo de diseño
por planificación
• Puede ser una estrategia válida para asegurar que
se tiene un producto listo a entregar en una fecha
determinada
• Esta estrategia es particularmente útil para las
partes del producto que no se quieren realizar en el
camino crítico
278
Desventajas del modelo de
diseño por planificación
• Si no se completan todas las etapas, se desperdiciará
tiempo en la especificación, arquitectura y diseños
de prestaciones que no se van a entregar
• Si se ha gastado tiempo en una gran cantidad de
requerimientos incompletos que no se van a
entregar, se debería tener tiempo para resumir en
uno o dos requerimientos más completos
279
Observaciones al modelo de
diseño por planificación
• La decisión radica en la respuesta a la pregunta
¿cuánta confianza se tiene en la habilidad para la
planificación?
– si se tiene mucha confianza, esta aproximación es
ineficiente
– si se tiene una menor confianza, esta aproximación podría
ser excelente
280
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
ENTREGA EVOLUTIVA
281
El modelo de entrega evolutiva
(1)
• Es un modelo que se encuentra entre el
prototipado evolutivo y la entrega por etapas
– se desarrolla una versión del producto
– se muestra al cliente
– se refina el producto en función de los
comentarios del cliente
• El parecido entre ambos modelos depende
de hasta qué punto se lleva a cabo una
planificación para adaptarse a las solicitudes
de los clientes
282
• Si se planifica para adaptarse a la
mayoría de las solicitudes, la
entrega evolutiva se parecerá más
al prototipado evolutivo
• Si se planifica para adaptarse a
pocas solicitudes de
modificación, la entrega
evolutiva se aproximará a la
entrega por etapas
El modelo de entrega evolutiva
(2)
283
Gráfica del modelo de entrega
evolutivaPlaneación
Análisis
Diseño
Entregar la versión
final
Desarrollar una versión
Entregar la versión
Realimentación del cliente
Agregar la realimentación
del cliente
284
• Las diferencias principales entre el prototipado
evolutivo y la entrega evolutiva son más de énfasis
que de aproximación fundamental
– en el prototipado evolutivo, el énfasis inicial se
encuentra en los aspectos visibles del sistema; después
se vuelve atrás y se completan los huecos de las bases
del sistema
– en la entrega evolutiva, el énfasis inicial se pone en el
núcleo del sistema, que está constituido por funciones
de bajo nivel que probablemente no van a ser
modificadas por la realimentación del cliente
Observaciones al modelo de
entrega evolutiva
285
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
DISEÑO POR
HERRAMIENTAS
286
El modelo de diseño por
herramientas
• En este modelo la idea es incluir una prestación
(funcionalidad) dentro del producto sólo si las
herramientas de software existentes la soportan
directamente. Si no está soportada, se deja
• Ejemplos de herramientas son
– las librerías de código y clases
– generadores de código
– lenguajes de desarrollo rápido y otras herramientas
software que reducen de manera espectacular el tiempo
de implementación
287
Funcionalidad soportadas por las
herramientas
Funcionalidad que se va a incluir
Funcionalidad ideal
Funcionalidad que no va a estar en el
producto
Gráfica del modelo de diseño
por herramientas
288
Ventajas del modelo de diseño
por herramientas
• Este modelo se puede combinar con otros modelos
– Primer ejemplo de combinación
• construir una espiral inicial para identificar las capacidades de las
herramientas software existentes
• identificar los requerimientos básicos
• determinar si la aproximación del diseño por herramientas es viable
– Segundo ejemplo de combinación
• utilizar una aproximación del diseño por herramientas para
implementar un prototipo de prueba
– realizando un prototipo sólo de las capacidades que se pueden
implementar fácilmente con herramientas
• implementar el software real utilizando la entrega por etapas, la
entrega evolutiva y el diseño por planificación.
289
Desventajas del modelo de
diseño por herramientas
• Se pierde mucho control sobre el producto
• Puede que no sea posible llevar a cabo la
implementación de todos los requerimientos
que se desean, y que no se puedan implementar
otros requerimientos exactamente de la forma
que se quiere
• Depende en buena medida de los productores
de software comercial (tanto de sus estrategias
de productos como de su estabilidad financiera)
290
Observaciones al modelo de
diseño por herramientas
• Al utilizar este modelo no será posible implementar
toda la funcionalidad que se considera ideal incluir
– sin embargo, si selecciona las herramientas con cuidado,
puede implementar la mayor parte de la funcionalidad que
se desea
• Cuando el tiempo es una restricción, se podría
implementar más funcionalidad de la que se obtiene
con otra aproximación
– sin embargo, será la funcionalidad que las herramientas
permiten una implementación de forma más sencilla, no la
funcionalidad que se considera ideal
291
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
SOFTWARE COMERCIAL
EXISTENTE
292
El modelo de software comercial
existente
• El software comercial disponible raramente va
a satisfacer todas las necesidades del cliente
• Se deben considerar los siguientes puntos
– está disponible de forma inmediata
– en el lapso de tiempo entre que se adquiere el
software comercial y en el que se puede tener
preparada la entrega del sistema de creación
propia, los usuarios pueden
• aprender a trabajar con las limitaciones del producto
• revisar el software comercial para adaptarlo aún más a
las necesidades de cada uno
293
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
SELECCIÓN DEL CICLO DE
VIDA
294
Observaciones sobre la selección
• Distintos proyectos tienen necesidades diferentes
– incluso si todos necesitan ser desarrollados lo más
rápido posible
• No existe ―un modelo de ciclo de vida de
desarrollo rápido‖
– debido a que el modelo más efectivo depende del
contexto en el que se utilice
• Determinados modelos de ciclo de vida son
considerados más rápidos que otros
– pero cada uno de ellos será más rápido en determinadas
situaciones y más lento en otras
295
• Un modelo que a menudo trabaja bien puede
suceder que no funcione bien si no se utiliza
correctamente
• Para seleccionar el modelo más conveniente
se debe responder a las siguientes preguntas:
– ¿Me compenetro con el cliente para la
especificación de los requerimientos al comienzo
del problema?
– ¿Es probable que el entendimiento de las dos
partes cambie significativamente a medida que se
avance en el proyecto?
Preguntas sobre la selección (1)
296
– ¿Comprendo bien la arquitectura del sistema?
– ¿Es probable que necesite llevar a cabo modificaciones
importantes en la arquitectura a mitad del proyecto?
– ¿Cuánta fiabilidad necesito?
– ¿Cuánto tiempo extra necesito para planificar y diseñar
durante el proyecto para las versiones futuras?
– ¿Cuántos riesgos conlleva el proyecto?
– ¿Estoy sometido a una planificación predefinida?
– ¿Necesito poder realizar modificaciones a medio
camino?
Preguntas sobre la selección (2)
297
– ¿Necesito proporcionar a mis clientes signos
visibles de progreso durante el proyecto?
– ¿Necesito ofrecer a la directiva signos visibles
de progreso durante el proyecto?
– ¿Cuánta sofisticación necesito para utilizar el
modelo de ciclo de vida con éxito?
Preguntas sobre la selección (3)
298
Capacidades del
modelo de ciclo de
vida
Cascada
Pura
Codificar y
Corregir
Espiral Cascadas
Modificad
as
Prototipado
Evolutivo
Trabaja con poca
identificación de los
requerimientos
Malo Malo Excelente Medio aexcelente
Excelente
Trabaja con poca
comprensión sobre laarquitectura
Malo Malo Excelente Medio a
excelente
Malo a medio
Genera un sistema
altamente fiable
Excelente Malo Excelente Excelente Medio
Genera un sistema
con amplio desarrollo
Excelente Malo a
medio
Excelente Excelente Excelente
Gestionar riesgos Malo Malo Excelente Medio Medio
Estar sometido a una
planificación
predefinida
Medio Malo Medio Medio Malo
Ventajas y desventajas de los
diferentes modelos (1)
299
Capacidades del
modelo de ciclo de
vida
Cascada
Pura
Codificar y
Corregir
Espiral Cascadas
Modificadas
Prototipado
Evolutivo
Requiere poco tiempode gestión
Malo Excelente Medio Excelente Medio
Permite
modificaciones a
medio camino
Malo Malo a
excelente
Medio Medio Excelente
Ofrece a los clientes
signos visibles de
progreso
Malo Medio Excelente Medio Excelente
Ofrece a la directiva
signos visibles de
progreso
Medio Malo Excelente Medio a
excelente
Medio
Requiere poca
sofisticación para los
directivos y
desarrolladores
Medio Excelente Malo Malo a medio Malo
Ventajas y desventajas de los
diferentes modelos (2)
300
Capacidades del
modelo de ciclo de
vida
Entrega
por Etapas
Entrega
Evolutiva
Diseño por
Planificación
Diseño por
Herramientas
Software
Comercial
Trabaja con poca
identificación delos requerimientos
Malo Medio aexcelente
Malo a medio Medio Excelente
Trabaja con poca
comprensión sobrela arquitectura
Malo Malo Malo Malo a excelente Malo a
excelente
Genera un sistema
altamente fiable
Excelente Medio a
excelente
Medio Malo a excelente Malo a
excelente
Genera un sistema
con ampliodesarrollo
Excelente Excelente Medio aexcelente
Malo N/A
Gestiona riesgos Medio Medio Medio aexcelente
Malo a medio N/A
Estar sometido a
una planificaciónpredefinida
Medio Medio Excelente Excelente Excelente
Ventajas y desventajas de los
diferentes modelos (3)
301
Capacidades del
modelo de ciclo
de vida
Entrega
por Etapas
Entrega
Evolutiva
Diseño por
Planificación
Diseño por
Herramientas
Software
Comercial
Requiere poco
tiempo de gestión
Medio Medio Medio Medio a
excelente
Excelente
Permite
modificaciones a
medio camino
Malo Medio a
excelente
Malo a medio Excelente Malo
Ofrece a los
clientes signos
visibles de
progreso
Medio Excelente Medio Excelente N/A
Ofrece a la
directiva signos
visibles de
progreso
Excelente Excelente Excelente Excelente N/A
Requiere poca
sofisticación para
los directivos y
desarrolladores
Medio Medio Malo Medio Medio
Ventajas y desventajas de los
diferentes modelos (4)
302
PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
EL CICLO DE MUERTE DE
LOS SI
303
Características de los diferentes
tipos de ciclos de vida
• Todos se concentran el desarrollo previo a la
entrega
• Los SI no se manufacturan en el sentido clásico
sino que se desarrollan por un proceso de
ingeniería
– no existe calibración de los SI como en el caso de las
máquinas
– no se puede agregar más gente al desarrollo de un SI si
se quiere aumentar la producción
• Los SI no se desgastan pero si se deterioran
304
Curva de fallas para el
hardware
Tiempo
Razón de
fallas
La curva de la “tina de baño”
“mortalidad infantil” desgaste
Cuando una componente de hardware sedesgasta se reemplaza por una refacción
305
Curva idealizada de fallas para
los SI
Tiempo
Razón de
fallas
La razón de fallas permanece constante
No existen refacciones para el software
Mucho del software se construye a la medida
306
Curva real de fallas para los SI
Tiempo
Razón de
fallas
Ocurrencia del
primer cambio
Curva ideal
Curva real
307
El ciclo de muerte de los SI
• Se enfoca sobre el costo de mantener un sistema
más que en la economía de desarrollar uno nuevo
• La premisa primordial es que el mantenimiento de
un SI entregado (para un estándar dado de
calidad):
– cuesta dinero
– tiene que ser compensado con los beneficios que se
obtienen del mismo
308
Gráfica del ciclo de muerte
Ingreso
Gasto
Periodo de desarrollo.Se requiere personal,equipo,licencias, etc.
Periodo de ventade licencias Periodo de mantenimiento,
instalación, distribución,soporte del producto, etc.
Muerteeconómica
TiempoMuerte técnica
(no se puede fijarcon precisión)
Retirar delmercado
No masventas
Inicio deventas
309
Características del modelo del
ciclo de muerte
• Se puede utilizar como modelo del efecto de muchas
de las decisiones planeadas a menudo de forma
aislada durante un proyecto de SI
• Una vez que el modelo es instalado se permite que la
muerte del SI sea conocida y planeada de forma
explícita
• Ejemplos de decisiones de planeación son:
– Cuando el costo de diseño excede el ingreso pronosticado
– Cuando el tiempo de desarrollo pierde el marco del
mercado
– Cuando se debe remplazar
310
LA ARQUITECTURA DE
ZACHMAN
EL MODELADO DE LAS
EMPRESAS
311
Antecedentes
• A principios de los años 80’s
– existía poco interés en el modelado de
las empresas
– la utilización de modelos y
formalismos estaba limitada a algunos
aspectos de desarrollo de aplicación
dentro de la comunidad de los SI
• Lo anterior provocó llevar a cabo
investigaciones que resultaron en el
―MARCO DE TRABAJO PARA
LA ARQUITECTURA DE LOS SI‖
312
• El marco de trabajo evolucionó a el
―MARCO DE TRABAJO PARA LA
ARQUITECTURA DE LAS EMPRESAS‖
• Zachman define:
– Una arquitectura es un conjunto de artefactos
de diseño, representaciones descriptivas, que
son relevantes para la descripción de un objeto
que puede ser producido acorde a
requerimientos (calidad) y sujeto a
mantenimiento en un periodo de tiempo de su
vida útil (cambio)
La arquitectura de las empresas
(1)
313
La arquitectura de las empresas
(2)
• Es una estructura lógica para clasificar y
organizar las descripciones representativas de
una empresa
– las cuales son significantes para la administración
de la empresa misma y los desarrollos de SI
empresariales
• Se derivó de estructuras análogas encontradas
en áreas de arquitectura e ingeniería
– estas áreas clasifican y organizan el diseño de
artefactos creados sobre procesos de diseño y
producción de productos físicos complejos
314
La gráfica de la arquitectura(1)
• Describe el diseño de
artefactos que constituyen la
intersección entre
– los roles en el proceso de
diseño
• dueño
• diseñador
• constructor
– las abstracciones del producto
• de qué (material) está hecho
• cómo (proceso) trabaja
• dónde (la geometría) se
encuentran ubicadas las
componentes
• Adicionalmente se incluyen
entidades que incluyen los
aspectos
– del alcance y visión
(diseñador)
– el de implementador
(subcontratado)
315
La gráfica de la arquitectura(2)
OBJECTIVES/
SCOPE
ENTERPRISE
MODEL
MODEL
(LOGICAL)
SYSTEM
TECHNOLOGY
CONSTRAINED
DETAILED
REPRESEN-
TATIONS
FUNCTIONING
ENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = Field
Reln = Address
e.g. DATA
e.g. Physical Data Model
Ent =Segment/Table/etc.
Reln =Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Entity
Reln = Data Relationship
e.g. Semantic Model
Ent = Business Entity
Reln = Business Relationship
List of Things Important
to the business
ENTITY = Class of Business
Thing
List of Processes the
Business Performs
Process = Class of Business
Process
e.g. Application Architecture
I/O = User Views
Proc = Application Function
e.g. System Design
I/O = Data Elements/Sets
Proc = Computer Function
e.g. Program
I/O = Control Block
Proc = Language Statement
e.g. FUNCTION
e.g. Business Process Model
Proc = Bus ProcessI/O = Bus Resources
List of Locations in which
the Business Opeerates
Node = Major Business
Location
e.g. Business Logistics
System
Node = Business LocationLink = Business Linkage
e.g. Distributed System
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
e.g. System Architecture
Node = Hardware/SystemsSoftware
Link = Line Specifications
e.g. Network Architecture
Node = Address
Link = Protocol
e.g. NETWORK
Architecture
Planner
Builder
Designer
Sub-
Contractor
Owner
What How Where
MODEL
(PHYSICAL)
(OUT-OF-
CONTEXT)
(CONTEXTUAL)
(CONCEPTUAL)
316
• Adicionalmente se deben incluir las
interrogantes primitivas: quién, cuándo, y
porqué
• Estas interrogantes se muestran como
columnas adicionales que, en el caso de las
empresas, describen
– quién hace el trabajo
– cuándo las cosas deben suceder
– porqué existen varias formas de hacerlo
La gráfica de la arquitectura(3)
317
Builder
SCOPE
MODEL
ENTERPRISE
MODEL
Designer
SYSTEM
DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Sub-
Contractor
FUNCTIONING
ENTEPRISE
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-conditionMeans = Step
e.g. STRATEGY
e.g. Rule Design
End = ConditionMeans = Action
e.g. Business Rule Model
End = Structural AssertionMeans = Action Assertion
e.g. Business Plan
End = Business ObjectiveMeans = Business Strategy
List of Business Goals/Strategies
Ends/Means = Major Business
Goals/Critical Success Factors
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing CycleTime = System Event
e.g. Control Structure
Cycle = Component CycleTime = Execute
e.g. Timing Definition
Cycle = Machine Cycle
Time = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business EventCycle = Business Cycle
List of Organizations
People = Major Organizations
People = Organization UnitWork = Work Product
e.g. Human Interface
People = Role
Work = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = IdentityWork = Job
e.g. ORGANIZATION
Architecture
Planner
Owner
to the BusinessImportant to the Business
E1
E1.1
E2
A1
E1.2
E1.3
E1
E1.1
E2
A1
E1.2
E1.3
E1
E1.1
E2
A1
E1.2
E1.3
e.g. Work Flow Model
(LOGICAL)
(CONCEPTUAL)
(PHYSICAL)
TECHNOLOGY
MODEL
La gráfica de la arquitectura(4)
318
Características de la
arquitectura (1)
• Es un esquema de clasificación genérica para el
diseño de empresas o artefactos; i.e.,
descripciones de cualquier objeto complejo
• El esquema permite centrarse en aspectos
selectos de un objeto sin perder el sentido de
perspectiva contextual u holística
319
Características de la
arquitectura (2)
• Adicionalmente permite:
– simplificar el entendimiento y comunicación
– centrarse en variables independientes para
propósitos analíticos
– tener cuidado en las relaciones contextuales que
son significantes para preservar la integridad del
objeto
320
• En resumen arquitectura es:– sencilla
• fácil de entender (no técnico y puramente lógico)
• contiene tres perspectivas (dueño, diseñador, constructor) y
tres abstracciones (material, funcionamiento, geometría)
• cualquier persona técnica o no técnica puede entenderlo
– entendible• mantiene en perspectiva a toda la empresa
• cualquier situación puede ser mapeada a él para entender
donde se ajusta dentro de la empresa como un todo
– un lenguaje• ayuda a concebir conceptos complejos y permite comunicarlos
con pocas palabras no técnicas
Características de la
arquitectura (3)
321
– una herramienta de planeación
• ayuda a hacer mejores elecciones de tal forma que nunca
permite hacer elecciones en el vacío
• permite ubicar objetos en el contexto de la empresa y ver un
rango total de alternativas
– una herramienta para la resolución de problemas
• permite trabajar con abstracciones
• simplifica y aísla variables sin perder el sentido de la
complejidad de la empresa como un todo
– neutral
• es independiente de herramientas y metodologías y por lo tanto
cualquier herramienta o metodología puede mapearse a él con
el fin de conocer que hacen y que no hacen
Características de la
arquitectura (4)
322
Conclusiones
• La arquitectura de las empresas
– no es ―la respuesta‖
– es una herramienta ... una herramienta
para pensar
– si se emplea con sabiduría, debería de ser
de gran ayuda para la administración
técnica y no técnica de la complejidad y
dinámica de la era de la información
empresarial
323
The Zachman framework
e.g. DATA
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE(CONTEXTUAL)
MODEL(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEM
MODEL(LOGICAL)
TECHNOLOGY
MODEL(PHYSICAL)
DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = FieldReln = Address
e.g. Physical Data Model
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Entity
Reln = Data Relationship
e.g. Semantic Model
Ent = Business Entity
Reln = Business Relationship
List of Things Important
to the Business
ENTITY = Class ofBusiness Thing
List of Processes the
Business Performs
Function = Class of
Business Process
e.g. "Application Architecture"
I/O = User ViewsProc .= Application Function
e.g. "System Design"
I/O = Screen/Device Formats
Proc.= Computer Function
e.g. "Program"
I/O = Control BlockProc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business Process
I/O = Business Resources
List of Locations in which the Business Operates
Node = Major BusinessLocation
e.g. Logistics Network
Node = Business Location
Link = Business Linkage
e.g. "Distributed System
Node = I/S Function(Processor, Storage, etc)Link = Line Characteristics
e.g. "System Architecture"
Node = Hardware/SystemSoftware
Link = Line Specifications
e.g. "Network Architecture"
Node = AddressesLink = Protocols
e.g. NETWORK
Architecture"
Planner
Owner
Builder
ENTERPRISEMODEL
(CONCEPTUAL)
Designer
SYSTEMMODEL
(LOGICAL)
TECHNOLOGYCONSTRAINED
MODEL(PHYSICAL)
DETAILEDREPRESEN- TATIONS (OUT-OF CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural AssertionMeans =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing CycleTime = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine CycleTime = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization Unit
Work = Work Product
e.g. Human Interface
People = RoleWork = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = IdentityWork = Job
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What How Where Who When Why
Copyright - John A. Zachman, Zachman International
SCOPE(CONTEXTUAL)
Architecture
e.g. STRATEGYENTERPRISE
e.g. Business Plan
TM
Zachman Institute for Framework Advancement - (810) 231-0531
