Este documento presenta un resumen de los conceptos clave de la visión de sistemas. Introduce los conceptos de sistemas, modelos, abstracción y diferentes categorías de modelos. Explica la diferencia entre los enfoques analítico y sistémico para analizar sistemas. Además, describe los componentes clave de un sistema general como entrada, salida, proceso, almacenamiento y control.

1. Técnicas y Métodos para el
Análisis y Diseño de Sistemas
Alejandro Domínguez
alexdfar@yahoo.com
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.
2

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)
3

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
4

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
5

6. Temario (4)
• EL MODELADO DE LAS EMPRESAS
– La arquitectura de Zachman
6

7. LA VISIÓN DE SISTEMAS
MODELOS
7

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
8

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
9

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)
10

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
11

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
12

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
13

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
14

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
15

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
16

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
17

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
18

19. LA VISIÓN DE SISTEMAS
INTRODUCCIÓN A LA
VISIÓN DE SISTEMAS
19

20. Viviendo con sistemas
El hombre vive y trabaja La tecnología ha producido
dentro de sistemas sociales sistemas físicos complejos
Pero los principios que gobiernan el comportamiento de los
sistemas no se han comprendido del todo
20

21. La definición de “sistema”
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
Un automóvil es un sistema de forma de vida
componentes que trabajan
conjuntamente para proporcionar
transportación
21

22. La no ocurrencia de los sistemas
Si los sistemas son tan importantes:
¿Por qué no aparecen los conceptos
y principios de éstos de forma más
clara en la literatura y en la
educación?
22

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
23

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
24

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
25

26. Enfoque analítico vs. Enfoque
sistémico (1)
Enfoque analítico Enfoque sistémico
Aísla, entonces se concentra en Unifica y se concentra en la
los elementos interacción entre los elementos
Estudia la naturaleza de la Estudia los efectos de las
interacción 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
26

27. Enfoque analítico vs. Enfoque
sistémico (2)
Enfoque analítico Enfoque sistémico
Permanece independiente de la Integra la duración del tiempo y
duración del tiempo; los la irreversibilidad
fenómenos considerados son
reversibles
Valida hechos por medio de Valida hechos a través de la
pruebas experimentales dentro del comparación del comportamiento
cuerpo de una teoría del modelo con la realidad
Es eficiente cuando las Es eficiente cuando las
interacciones son débiles y interacciones son fuertes y no
lineales lineales
27

28. Enfoque analítico vs. Enfoque
sistémico (3)
Enfoque analítico Enfoque sistémico
Utiliza modelos detallados y Utiliza modelos no tan rígidos
rígidos que no son tan útiles en las que son la base de conocimientos
operaciones reales (por ejemplo: y que son útiles en las decisiones
modelos econométricos) y las acciones
Lleva hacia la educación orientada Lleva a la educación
a las disciplinas multidisciplinaria
(juxtadisciplinaria)
Conduce a la acción programada a Conduce a la acción a través de
través de detalles objetivos
Posee el conocimiento de detalles Posee el conocimiento de
de objetivos pobremente definidos objetivos y detalles difusos
28

29. Enfoque analítico vs. Enfoque
sistémico (4)
• 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
29

30. LA VISIÓN DE SISTEMAS
DIFERENTES CLASES DE
SISTEMAS
30

31. El modelo general de sistemas
(1)
• Inputs (entradas, insumos)
Modelo de sistemas
son aceptados en el sistema
• Outputs (salidas, Control
productos) se producen a
través de los procesos Input Output
dentro del sistema Proceso
• También pueden existir
almacenaje intermedio y
control sobre el Almacenaje
funcionamiento del sistema
31

32. El modelo general de sistemas
(2)
SISTEMA
Input
(granos de café)
Almacenaje
Control
Output
Input
(electricidad)
Proceso (calentamiento)
32

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
33

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
34

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
35

36. Inputs y outputs de un sistema
(1)
• Los inputs y
outputs de un Inputs Sistema Outputs Sistema
Output
sistema se pueden 1 Inputs 2
conectar a otros
Input Output
sistemas
Input
• Los outputs de un
sistema pueden Input Sistema Output
ser los inputs de 3
otro
Output
36

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
37

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
38

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
39

40. Entorno y frontera de los sistemas
(3)
• 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
40

41. Entorno y frontera de los
sistemas (4)
Los sistemas Los sistemas
cerrados no abiertos son
tienen inputs aquellos que
u outputs: no son
no tienen cerrados
entorno
• 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
41

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
42

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
43

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
44

45. Subsistemas
SISTEMA • Los sistemas están compuestos
de subsistemas que están
S1 S2 ••• interrelacionados uno con los
otros por medio de sus inputs y
outputs
• Esto proporciona al sistema una
• • • Sn estructura interna
• Cada subsistema es en si
mismo un sistema
45

46. Tipos de conexión entre subsistemas
Conexión indirecta
Conexión directa
(1 y 3)
(1 y 2)
Subsistema 1
Subsistema 1
Subsistema 2
Subsistema 2
Subsistema 3
46

47. Jerarquía de subsistemas y sistemas
Jerarquía de subsistemas
Sistema primario
Subsistema 1 Subsistema 2 Subsistema 3
La descomposición de un sistema en sus subsistemas
se puede visualizar a través de una gráfica
jerárquica de sistemas
47

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
48

49. Cada área funcional es un
sistema
Dirección
Input Proceso Output Input Proceso Output
Subsistema de ventas Subsistema de finanzas
Input Proceso Output Input Proceso Output
Subsistema de manufactura Subsistema de informática
49

50. Cada nivel administrativo es un
sistema
Estándares
Input Proceso Output
Nivel de planeación estratégica
Estándares
Input Proceso Output
Flujo de Nivel de control administrativo
información
Estándares
Flujo de
decisión Input Proceso Output
Nivel de control operacional
50

51. Combinaciones entre subsistemas
Combinación en serie
Subsistema 1 Subsistema 2
Combinación con realimentación (feedback)
Subsistema 1 Subsistema 2
Combinación en paralelo
Subsistema 1
Subsistema 2
Subsistema 3
51

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
52

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
53

54. Desacoplamiento de subsistemas
(1)
• El desacoplamiento se lleva
Requerimientos de production
a cabo introduciendo un
amortiguador o inventario
entre los dos subsistemas
Producción Ventas
• El efecto del
desacoplamiento es proteger
los subsistemas de ventas y
de distribución de las
Inventario variaciones en la
producción
54

55. Desacoplamiento de subsistemas
(2)
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 Ventas
Producción
55

56. Desacoplamiento de subsistemas
(3)
• 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
56

57. Control y realimentación
(feedback) (1)
• Los sistemas tienen objetivos
• Con el fin de asegurar que los objetivos de los
sistemas se cumplan es necesario que exista un
control que opere sobre su funcionamiento
• Los controles a menudo trabajan sobre los estados y
outputs de un sistema. Comparan estos con los
objetivos del sistema, y toman medidas correctivas si
es necesario
57

58. Control y realimentación
(feedback) (2)
El modelo general de control y realimentación es
Estándares
Control
Efector Comparador
Datos/
Decisiones
información
Inputs Sensor
Procesos Outputs
58

59. Control y realimentación
(feedback) (3)
• 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
59

60. Realimentación
• Existen dos tipos de • La realimentación
realimentación positiva generalmente
– La realimentación positiva conduce a la inestabilidad
es aquella en la cual la de los sistemas (e.g.
multiplicación entre los
inputs y outputs es tal que la
crecimiento de bacterias)
salida aumenta con • La realimentación
incrementos de la entrada negativa proporciona un
– La realimentación control de sistema estable
negativa es aquella en la (e.g. sistema de
cual la multiplicación entre calefacción con
los inputs y outputs es tal
que la salida disminuye al termostato)
aumentar la entrada
60

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
61

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
62

63. LA VISIÓN DE SISTEMAS
EL DESARROLLO
HISTÓRICO DE LA TEORÍA
DE SISTEMAS
63

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
64

65. La búsqueda de nuevas
herramientas (2)
65

66. Los pioneros
El neurofisiologista Warren
McCulloch y
el Profesor Jay Forrester
Otros personajes:
A. Rosenblueth
W.B. Cannon
El matemático J.H. Bigelow
Norbert Wiener C. Shannon
66

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
Wiener, permitiendo así la evaluación de los efectos de las acciones y la adaptación
Bigelow, a futuras conductas basadas en desempeños anteriores”
y Rosenblueth
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
El resultado: Cybernetics, or
control and communication in the
animal and the machine
67

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
68

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
69

70. Historia de la palabra
“cibernética” (2)
• 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‖
70

71. Historia de la palabra
“cibernética” (3)
Cibernética tiene la misma
raíz de la palabra gobierno:
el arte de administrar y
dirigir sistemas altamente
complejos
71

72. LA VISIÓN DE SISTEMAS
EL VALOR DE LA
INFORMACIÓN
72

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
73

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
74

75. La información según Wiener
La cantidad de información es el negativo
… así como la información en un
de la cantidad definida comunmente como
sistema es una medida de su grado de
entropía en situaciones similares. Así, los
organización, así la entropía de un
procesos que pierden información son casi
sistema es una medida de su grado de
análogos a los procesos que incrementan
desorganización
la entropía
También, según Wiener, la información está relacionada con
cuestiones de decisión, comunicación y control
75

76. La información según Shannon
La cantidad que de forma única cumple
los requerimientos del concepto de • Así, según Shannon, no
información es aquella que en importa si estamos
termodinámica se conoce como entropía 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
76

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 Información
según Wiener según Shannon
77

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
78

79. El significado de la información
según Shannon
• 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
79

80. Los puntos de vista modernos de
la información
Estudia la relación Estudia el valor de Estudia la
formal entre los los símbolos que información en un
símbolos que representan a la contexto dado, así
representan a la información como en su
información. No utilización para
considera su alcanzar un
significado y su objetivo
valor asociado
80

81. Procesamiento de la
información
I   Ik I  f I1 , I 2 ,  , I n 
Ii Ik k
sistema sistema de Sistema de
selectivo agregación cálculo
I1 I2 I3 In I1 I2 I3 In I1 I2 I3 In
81

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...
82

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
83

84. LA VISIÓN DE SISTEMAS
LOS SISTEMAS DE
INFORMACIÓN
84

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.
85

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
86

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
87

88. Parte externa de un SI (1)
Gobierno Comunidades
Clientes Provedores
ORGANIZACIÓN
Sistema de información
Input Proceso Output
Captura o Clasifica Distribución de
colección de Arregla información
datos llanos Calcula procesada
Realimentación
Agencias reguladoras Competidores
Accionistas Sindicatos
88

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
89

90. Parte interna de un SI (1)
• 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
90

91. Parte interna de un SI (2)
Datos de entrada
Procesos de la aplicación Almacenamiento
y salida utilizando interfaces
con restricciones especificadas de datos
humano-máquina
Terminal para Archivo
entrada maestro
y salida de datos Procesos de
la aplicación: Recuperación
edita, actualiza, de datos
Salida de datos; Almacenamiento
interfaz manual
reporta, pregunta de datos; interfaz
computarizada
Archivo de
Reporte de las Documento a acceso
preguntas (queries) ser actualizado secuencial
Salida de datos;
A aplicaciones
interfaz manual
externas 91

92. Parte interna de un SI (3)
• 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
92

93. Parte interna de un SI (4)
• 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
93

94. Parte interna de un SI (5)
– 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)
94

95. Parte interna de un SI (6)
– 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
95

96. Parte interna de un SI (7)
• 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
96

97. El modelo de sistemas general
de la organización
Clientes Gobierno Comunidades
ORGANIZACIÓN Provedores
Estándares Datos/
Información
Datos/
Información
Procesador
Decisiones de la
Administración información
de fuentes
Datos/información
físicas Hacia
fuentes
Proceso de físicas
Input Output
transformación
Agencias reguladoras Accionistas Sindicatos Competidores
97

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
98

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
99

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)
100

101. Tipos de SI (2)
TIPO DE ENTRADA DE PROCESO SALIDAS DE USUARIOS
SI INFORMACIÓN INFORMACIÓN
ESS Datos agregados; Gráficas; Proyecciones; Altos directivos
internos y externos simulación; respuesta a
interactivo preguntas
DSS Bajo volumen de Interactivo; Reportes Profesionales;
datos; modelos simulación, especiales; análisis personal
analíticos análisis de decisiones; administrativo
respuesta a
preguntas
MIS Datos de Reportes de rutina; Resúmenes y Administradores
transacciones modelos sencillos; reportes de de nivel intermedio
sumarias; alto análisis de bajo excepción
volumen de datos, nivel
modelos sencillos
101

102. Tipos de SI (3)
TIPO DE ENTRADA DE PROCESO SALIDAS DE USUARIOS
SI INFORMACIÓN INFORMACIÓN
KWS Especificaciones Modelación; Modelos; gráficas Profesionales;
de diseño; bases de simulación personal técnico
conocimiento
OAS Documentación; Administración de Documentos; Oficinistas
programas de documentos; horarios; correo
trabajo horarios;
comunicación
TPS Transacciones, Ordenar, listar; Reportes Personal operativo,
eventos mezclar, actualizar detallados, listas, supervisores
resúmenes
102

103. Tipos de SI (4)
TIPO DE Operacional Conocimiento Administrativo Estratégico
DECISIÓN
Estruc-
turada TPS
OAS MIS
Semi-
estruc-
turada DSS
No
estruc- ESS
turada
103

104. Interrelación entre los tipos de
sistemas
• Los TPS son los
productores principales ESS
de la información
requerida por los otros
SI, quienes a su vez
producen información a MIS DSS
otros SI
• Estos diferentes tipos de
sistemas están
comúnmente
desacoplados en muchas OAS TPS
organizaciones
104

105. LA VISIÓN DE SISTEMAS
CONCLUSIONES
105

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
106

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
107

108. La visión de sistemas está
implícita en las organizaciones
• 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
108

109. ENFOQUES DE
DESARROLLO DE LOS SI
LA RESOLUCIÓN DE
PROBLEMAS
109

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
110

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
111

112. Componentes del proceso de
resolución de problemas
Problema
Elementos del sistema conceptual
Estado Soluciones
Estándares deseado alternativas
Resolvedor
de problemas
(directivo)
Estado
Información
actual Restricciones
Solución
112

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
113

114. Problemas versus síntomas (2)
• 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
114

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
115

116. Tipos de problemas (2)
• 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
116

117. Las cuatro dimensiones para la
resolución de problemas
Personas Producto
Con una visión clara y precisa Consiste en estimar la dimensión
de la problemática o con del problema.
disposición de obtener esta Se basa en la técnica
visión “divide y vencerás”
Proceso Tecnología o
Evitar repetición del trabajo herramientas
Controlar la calidad de la solución Es necesario hacer un buen uso
Gestionar riesgos ellas y tener las apropiadas para
Poner atención a los recursos la resolución del problema
Planificar la solución
Enfatizar a quién o a qué va
dirigida la solución
117

118. ENFOQUES DE
DESARROLLO DE LOS SI
METODOLOGÍA PARA
DESARROLLO DE SI
118

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
119

120. Metodología
• 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
Planeación Administración
Control Evaluación
120

121. Consideraciones metodológicas
121

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
122

123. Metodologías de los SI: objetivos
(1)
• 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
123

124. La metodologías de los SI:
objetivos (2)
• 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
124

125. 3
fases
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
125

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
126

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
127

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
128

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
129

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
130

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
131

132. El esfuerzo de definición: Paso
4
• 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
132

133. El esfuerzo de definición: Paso
5 (1)
• Paso 5: analizar las partes del sistema en una
secuencia determinada:
1.
Estándares
3. 4. Procesador
Administración de información
5. 5. Fuentes 6. Proceso de 7. Fuentes 2.
Entradas de entrada transformación de salida Salidas
133

134. El esfuerzo de definición: Paso
5 (2)
La visión de sistemas proporciona la vía para la definición del problema
Analizar la organización como un sistema
1. 2. 3.
Estándares Salidas Administración
Analizar un subsistema dentro de la organización
1. 2. 3.
Estándares Salidas Administración
Analizar un sub-subsistema dentro de la organización
1. 2. 3. 4. Procesador
Estándares Salidas Administración de información
5. Fuentes 5. 6. Proceso de 7. Fuentes
de entrada Entradas transformación de salida
134

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
135

136. El esfuerzo de solución: Paso 7
• 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
136

137. El esfuerzo de solución: Paso 8
• 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
137

138. El esfuerzo de solución: Pasos 9
y 10
• 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
138

139. La visión de sistemas y la toma
de decisiones
Fase Paso Decisión
4 ¿Dónde está el problema?
Esfuerzo ¿Se deben recolectar nuevos datos o ya existen?
de 5 ¿La recolección de datos fue exitosa y suficiente?
definición
¿Cuál es la causa del problema?
6 ¿Cuántas alternativas se deben identificar?
¿Estas alternativas son factibles?
Esfuerzo 7 ¿Qué criterios se deben utilizar?
de ¿Todos los criterios tienen el mismo peso?
solución
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?
10 ¿Quién debe desempeñar la evaluación?
¿Qué tan bien la solución cumple los objetivos?
139

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)
140

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
141

142. Las 5 premisas de Checkland
No existen los problemas objetivos. Si los problemas dependen del intelecto humano,
también las soluciones dependen de él:
Diferentes personas ven diferentes
si se está de acuerdo con los problemas se está
problemas en la misma situación en desacuerdo con la solución
El analista no se puede divorciar
del sistema y los participantes
Muy rara vez los
problemas se presentan
de forma individual,
ni de forma empaquetada,
El área problema se debe ni listos para la solución
investigar y analizar antes de
tomar cualquier decisión sobre
tecnologías computacionales Peter Checkland
142

143. El enfoque de Checkland: la metodología
143

144. La situación del problema (1)
El analista tiene que Una rich picture es una caricatura de
familiarizarse con la los constituyentes y sus relaciones de la La información
situación del problema. situación del problema suave y dura debe
Se debe hacer un intento de ser recolectada
de construcción de una
rich picture
Incluir las
Imponer una preocupaciones,
configuración del temores y
La situación del aspiraciones de los
sistema puede limitar
los tipos de cambios
problema participantes
que se podrían sugerir
Incluir alianzas entre
departamentos o
El analista no debe individuos, así como
imponer algún tipo de deseos y
configuración del presentimientos
sistema en este nivel El analista debe buscar por estructura,
procesos clave, y la interacción entre los
procesos y estructura 144

145. La situación del problema (2)
El propósito de una rich picture es:
Ayudar a visualizar la Evitar la imposición
complejidad de la de una estructura
interacción entre las rígida en la
personas, roles, hechos, apreciación del
observaciones, etc problema
Actuar como una
herramienta de Evitar llevar a cabo
comunicación investigaciones
entre los inútiles sobre el
participantes entendimiento del
problema
145

146. La situación del problema (3)
1. El resolvedor 2. El cliente: la
del problema: persona que paga al
el analista IDENTIFICAR 3
analista
PERSONAJES
IMPORTANTES
3. El poseedor del problema: la
persona o área donde surge el
problema
146

147. El equipo sin
No. De
Después el equipo
es diagnosticado y
EL PROCESO EN SI:
inventario es
regresado
se determina si la
reparación es
Un ejemplo de rich picture. Cortesía de
Al ingresar el equipo
por no ser
patrimonio
viable para ser
reparada en las
María Luisa Serrano
de la
el técnico pregunta instalaciones. Se
institución
por la fecha de informa al jefe. Al jefe se le informa
Informa de las
compra y define si del diagnostico y si se
refacciones que no
está en garantía o cuenta con las
hay en almacén de
no. Si está hace una refacciones necesarias.
DATOS DEL las oficinas
relación e informa al
EQUIPO Y Checa en una lista
jefe. El equipo sin
DEL
garantía pasa almacenada en una hoja
SOLICITANTE
directamente al de exel la existencia de
diagnostico. TECNICO las refacciones y las
entrega al técnico
Cuando existen DIAGNOSTIC JEFE
las refacciones O
SE REPARA Contacta con
el equipo es
el proveedor
reparado. En
dicha
reparación
GARA
interviene el Servicio social de apoyo NTIA
técnico y el Charly se encarga
GARA
servicio social NTIA de solicitar las
de apoyo. facturas para
comprobar que
los equipos estén
Charly solicita en garantía al
El técnico se Cuando el equipo las refacciones almacén central o
encarga de es ingresado cuando no hay
PRUEVA EQUIPO
a compras
coordinar las después de ser en existencia
actividades del reparado o
servicio social de validado por el
apoyo. Ellos están proveedor, se
involucrados prueba antes de
tanto en la ser entregado al
reparación de los usuario. Si el Charly se encarga de preparar el
equipos, la equipo falla equipo que está en garantía y el que
instalación de nuevamente se le Es el equipo recibido que no no se puede reparar, prepara la
periféricos y regresa al cumplió con garantía y no salida del mismo para que el
consumibles y en proveedor. pudo ser reparado por falta proveedor venga por el o Charly lo
ocasiones del de dinero o porque ya no tiene
diagnostico. reparación.
envía personalmente 147

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?
148

149. La definición del sistema
relevante (2)
La sugerencia más aceptada es: acordarlo vía la negociación, esto es a
menudo entre el poseedor y el resolvedor del problema
Adentrarse más a la
situación del problema
Es lo más apropiado para
estimular el Producir una
entendimiento y el definición de raíz
cambio en la EL SISTEMA no es una tarea
organización: el objetivo mecánica. Solo se
final de la metodología
RELEVANTE puede definir por
Se basa en las prueba y error
tareas
fundamentale Su esencia está en
s desarrollar una
definición de raíz
149

150. La definición del sistema
relevante (3)
• Sin embargo existe una • Clientes: personas o grupo de personas que
lista llamada son servidas o que se benefician del sistema
• Actores: personas o tipo de personas que
CATWOE que debe llevan a cabo las actividades esenciales dentro
satisfacer toda del sistema relevante
definición de raíz • Proceso de Transformación: esto es lo que el
sistema realiza (el proceso que convierte inputs
• Todas las componentes en outputs
de CATWOE deben • Visión panorámica (Weltanschauung: world
estar presentes (la view) relevante al sistema
• Dueños (Owners): personas para las cuales el
ausencia de una de ellas sistema es un respuesta. Ellos tienen el poder
requiere de una de cambiar el sistema o hacer que deje de
justificación) existir
• Entorno: es donde el sistema se localiza
150

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
151

152. Modelos conceptuales (2)
Las preguntas
típicas que se
¿El modelo ilustra
deben hacer son:
¿Existe garantía de
una actividad que
estabilidad a largo
tiene algún propósito
plazo?
de continuidad?
¿Existe alguna ¿Existe alguna frontera?
medida de
desempeño?
¿Existe algún ¿Existen
proceso de toma subsistemas
de decisiones? conectados?
152

153. Comparación del modelo
conceptual con el problema (1)
Las diferencias deben
ser resaltadas como
posibles puntos de
discusión
• ¿Porqué existe una discrepancia entre el
Rich Picture modelo conceptual y el mundo real?
vs.
Problema • ¿Las actividades generadas por el modelo
conceptual suceden en el modelo real?
153

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
154

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 155

156. Acciones para mejorar la
situación del problema
Checkland no es muy específico en como se debe
llevar a cabo esto
Cambios en
las políticas,
El resultado del
estrategias
debate de la agenda debe
o procedimientos se
ser un acuerdo para
deben acordar
cambiar las actitudes
dentro de la situación del
problema
Peter Checkland
156

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
157

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
158

159. ENFOQUES DE DESAROLLO
DE LOS SI
LOS MAPAS MENTALES:
UNA TÉCNICA PARA LOS
ESFUERZOS DE SOLUCIÓN
Y DE DEFINICIÓN (2)
159

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
160

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
161

162. Un mapa mental
162

163. Leyes de diagramación mental
• Iniciar siempre el trazo de • Elegir únicamente
un mapa mental con una palabras o imágenes
imagen central que clave
involucre por lo menos • Utilizar imágenes a todo
tres colores lo largo del mapa mental
• Conectar tantas • Agregar símbolos,
ramificaciones a la flechas y colores a fin de
imagen central como sea establecer conexiones y
necesario; añadir grosor a asociaciones entre los
las ramas principales a fin diferentes elementos
de enfatizarlas • Utilizar ayudas
dimensionales
163

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
164

165. Creación de un mapa mental de
generación de ideas o creativo
• Reunir materiales: colores, • Utilizar una palabra o imagen
marcadores, bolígrafos y clave para representar cada idea
papel (éste colocarlo de • Comenzar a diagramar lo más
forma horizontal) rápido posible con el fin de que
• Determinar el foco o el tema las ideas asociadas a la imagen
deseado en forma de imagen fluyan y se sucedan unas tras
• Añadir varios pares de ramas otras sin intentar organizarlas
conectadas a la imagen • Repetir el proceso cuanto sea
central necesario
• A fin de evitar bloqueos • Utilizar una palabra o imagen
añadir abundantes clave sobre cada rama
ramificaciones
165

166. Creación de un mapa mental a
partir de ideas predeterminadas
• Reunir material y poner al • Añadir las ideas básicas a
alcance el material manera de encabezados sobre
preseleccionado (apuntes, las ramas principales
libro, investigaciones, etc. • En el extremo de las ramas
• Seleccionar el tópico, gruesas agregar ramas más
materia, o problema a ser delgadas. A éstas se le
diagramado y crear la imagen asocian los subtemas
central • Añadir más colores y más
• Agregar ramificaciones a esta imágenes para destacar ideas
imagen central y se le da • Utilizar flechas, símbolos y
grosor para destacar su códigos propios para asociar
importancia ideas y favorecer conexiones
166

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
167

168. Un mapa mental para la
organización de software
168

169. Mapa mental para la estructura
de una página Web
169

170. Mapa mental de un manual de
software
170

171. Mapa mental para la página
www.openeng.com
171

172. ENFOQUES DE DESAROLLO
DE LOS SI
GUÍA PARA ELABORAR
POLÍTICAS Y PROCEDIMIENTOS:
UNA TÉCNICA PARA LOS
ESFUERZOS DE SOLUCIÓN Y
DEFINICIÓN (3)
172

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
173

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
174

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
175

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
176

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
177

178. Alcance
• Es el campo de acción • Tiene que ver directamente
sobre el cual la política o con el nombre de la política o
procedimiento tendrá procedimiento y se relaciona
injerencia principalmente con personas,
• Muestra los límites dentro productos, procesos, áreas,
de los cuales se aplicará la máquinas, turnos, etc.
política o procedimiento • No se refiere a las personas
• Muestra donde inician y involucradas en la política o
terminan las actividades, procedimiento, sino a la
responsabilidades y definición de los casos en que
funciones involucradas se utilizará esta política o
procedimiento
178

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
179

180. Responsable de la revisión de la
política o procedimiento
• Es la persona encargada de • Es la persona quien tiene la
editar, revisar y actualizar autoridad formal para
periódicamente el documento asegurar que haya
controlado que se le ha congruencia entre lo que se
asignado, así como los dice y lo que se hace
anexos allí incluidos • Al referirse a él se debe
• No necesariamente es la hacer mención de su puesto
persona que elaboró el y no a su nombre de pila
documento – debe decir gerente de ventas,
– es la persona con mayor jefe de diseño gráfico, gerente
afinidad entre las funciones de general, supervisor de
su puesto y la descripción de la producción, etc.
política o procedimiento
180

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
181

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
182

183. Diagrama de flujo:
consideraciones generales
• Sólo se utilizan para el • Es necesario tenerlo
desarrollo de terminado antes de iniciar
procedimientos, no para el con el desarrollo del
desarrollo de políticas procedimiento
• Es una gráfica que • Permite visualizar todo el
muestra la secuencia flujo de información y el
ordenada de actividades a contexto del
seguir en el procedimiento correspondiente evitando
y la interrelación que así las duplicidades de
existe entre las entidades funciones y las actividades
que no agregan valor al
sistema
183

184. Diagrama de flujo: simbología
Proceso o actividad Datos y/o
Decisión binaria
Proceso alternativo Disco
magnético
Terminal: principio
o final Multidocumento Intercalar
Conector: indica
continuidad del Almacenamiento Ordenar
diagrama de flujo de acceso secuencial
Documento generado Almacenamiento Extracto
por el proceso de acceso directo
Combinar
184

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
185

186. ENFOQUES DE DESAROLLO
DE LOS SI
EL PAPEL DEL ANALISTA
DE SISTEMAS EN LAS
ORGANIZACIONES
186

187. El papel cambiante de los
personajes en los SI (1)
usuario programador computadora
usuario programador operador computadora
analista
usuario de programador operador computadora
sistemas
187

188. El papel cambiante de los
personajes en los SI (2)
administrador especialista
de bases en bases
de datos de datos
analista
usuario de programador operador computadora
sistemas
administrador especialista
de redes de en redes de
computadoras computadoras
188

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
189

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
190

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
191

192. Características del analista (2)
En pocas palabras, el analista debe ser un:
192

193. El papel del analista
193

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)
194

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
195

196. DESARROLLO DE SI
COMPUTARIZADOS
EL CICLO DE VIDA DE LOS
SI
196

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
197

198. El patrón circular del ciclo de
vida
La fase de
utilización
La fase de
planeación
La fase de
implementación
La fase de
análisis
La fase de
diseño
198

199. Papel de poseedor del problema
y del analista de sistemas
Poseedor Analista de
Fase del problema sistemas
Definir el
Planeación Soporte
problema
Conducir el
Análisis Controlar estudio
del sistema
Diseño Controlar Diseñar el sistema
Implementar
Implementación Controlar el sistema
Hacer viable
Utilización Controlar el sistema
199

200. DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE PLANEACIÓN
200

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
201

202. La fase de planeación
COMITÉ DIRECTIVO POSEEDOR DEL ANALISTA DE
DE SI PROBLEMA
Reconocer la SISTEMAS
existencia del
problema
Definir el
problema
Definir los objetivos Consultar
del sistema
Identificar las
restricciones
del sistema
Conducir un estudio
de factibilidad
Prepara una
propuesta para el
estudio del sistema
Aprobar o desaprobar el estudio del proyecto
Establecer un mecanismo de control
202

203. El estudio de factibilidad
• Está compuesto por los factores principales que
afectan directamente al sistema en el
cumplimiento de sus objetivos
Factibilidad técnica
hardware
software
Factibilidad legal
y ética
203

204. Perfil para la propuesta de
estudio del sistema
1. Resumen ejecutivo
2. Introducción
3. Objetivos del sistema y restricciones
4. Posibles sistemas alternativos
5. El proyecto recomendado de estudio del sistema
5.1 Tareas por realizarse
5.2 Requerimientos de recursos humanos
5.3 Calendarización del trabajo
5.4 Costo estimado
6. Impacto esperado del sistema
6.1 Impacto en la estructura de la organización
6.2 Impacto en las operaciones de la organización
6.3 Impacto en las bases de la organización
7. Plan general de desarrollo (análisis, diseño, e
implementación)
8. Resumen
204

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
205

206. Ejemplo de calendarización
Sistema funcional: Ventas
Subsistema: Producto
Modelo: Eliminación de producto
Tiempo estimado
Subtarea Responsabilidad (personas-mes)
1. Identificar el criterio Analista de sistemas 0.75
de eliminación Administrador de producto
2. Identificar los Analista de sistemas
requerimientos de la Administrador de producto 0.25
información de salida Especialista en redes
3. Identificar los Analista de sistemas
requerimientos de los Administrador de bases de 0.50
datos de entrada datos
4. Preparar la Analista de sistemas
documentación del 2.00
nuevo sistema
5. Diseñar la red Especialista en redes 1.50
6. Diseñar la base de datos Administrador de BD 0.50
7. Revisar el diseño Analista de sistemas y AP 0.25
8. Preparar la Programador
documentación del programa 1.00
9. Codificar el programa Programador 1.25
10. Probar el programa Programador y staff de oper. 0.75
11. Aprobar el programa AP y VP de ventas 0.50
12. Preparar la BD Administrador de BD 2.00
13. Capacitar a los usuarios Analista de sistemas 0.50
14. Terminar el modelo Staff de operaciones 0.75
206

207. DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE ANÁLISIS
207

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
208

209. La fase de análisis
COMITÉ DIRECTIVO POSEEDOR DEL ANALISTA DE
DE SI PROBLEMA SISTEMAS
Anunciar el estudio del sistema
Organizar el equipo de desarrollo
Definir las necesidades de información
Definir los criterios de desempeño
Preparar la
propuesta de
diseño
Aprobar o desaprobar el proyecto de diseño
209

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
210

211. Perfil para la propuesta de
diseño
1. Resumen ejecutivo
2. Introducción
3. Definición del problema
4. Objetivos y restricciones del sistema
5. Criterios de desempeño
6. Posibles sistemas alternativos
7. El proyecto recomendado de diseño
7.1 Tareas por realizarse
7.2 Requerimientos de recursos humanos
7.3 Calendarización del trabajo
5.4 Costo estimado
8. Impacto esperado del sistema
8.1 Impacto en la estructura de la organización
8.2 Impacto en las operaciones de la organización
8.3 Impacto en las bases de la organización
9. Plan general de desarrollo (análisis, diseño, e
implementación)
10. Resumen
211

212. DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE DISEÑO
212

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
213

214. La fase de diseño
COMITÉ DIRECTIVO POSEEDOR DEL ANALISTA DE
DE SI PROBLEMA SISTEMAS
Preparar el
diseño detallado
del sistema
Determinar
configuraciones
alternativas
del sistema
Controlar
Evaluar las
configuraciones
alternativas
del sistema
Seleccionar
las mejor
configuración
Preparar la
propuesta de
implementación
Aprobar o desaprobar la
implementación del sistema
214

215. Preparar el diseño detallado del
sistema
HERRAMIENTAS DE
DOCUMENTACIÓN
Modelado de Diagramas entidad-
datos relación
Diccionario de datos
Impresión en papel
o en pantalla
Modelado de Diagramas de flujo
procesos del sistema y del
programa
Diagrama de flujo
de datos
Pseudocódigo
Modelado de Relaciones entre
objetos objetos
Especificación de
clases
215

216. Cuadro comparativo de
metodologías
Metodología Razones del Ayuda Área Método Palabras
desarrollo otorgada claves /
conceptos
Tradicional Necesidad de Desarrollo de Funciones, Represent. Diagramas
sistematizar un sistema subsistemas precisa de las de flujo,
el análisis y de proc. de funciones del matrices de
el diseño datos sistema vía la entrada-
técnicamente división y salida,
eficiente optimización formas de
de las descripción
subfunciones documentada
Estructurada Fallas en el Desarrollo de Funciones, Desarrollo de Diagramas
desarrollo de un sistema sistemas un modelo de flujos de
sistemas técnicamente totales lógico datos,
grandes y la integrado y haciendo diccionario de
falta de modular énfasis en datos
habilidad funciones,
para procesos y
coordinar flujos de
equipos de datos
prog.
Análisis de Desarrollo y Desarrollo de Estructuras Desarrollo de Modelos
datos creciente una de datos un modelo de entidad-
importancia estructura de organizacion datos lógico relación
de la BD adecuada ales con énfasis
tecnología de para soportar en entidades,
BD las relaciones y
aplicaciones estructuras
cambiantes de datos
Checkland Fallas en la Entendimien- Sistemas Desarrollo de Rich pictures,
solución de to de los difusos un modelo CATWOE,
problemas problemas conceptual agenda para
difusos organizacio- de un el cambio
nales sistema ideal
216

217. Perfil para la propuesta de
implementación
1. Resumen ejecutivo
2. Introducción
3. Definición del problema
4. Objetivos y restricciones del sistema
5. Criterios de desempeño
6. Diseño del sistemas
6.1 Descripción sumaria
6.2 Configuración del equipo
7. El proyecto recomendado de implementación
7.1 Tareas por realizarse
7.2 Requerimientos de recursos humanos
7.3 Calendarización del trabajo
5.4 Costo estimado
8. Impacto esperado del sistema
8.1 Impacto en la estructura de la organización
8.2 Impacto en las operaciones de la organización
8.3 Impacto en las bases de la organización
9. Plan general de implementación
10. Resumen
217

218. DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE
IMPLEMENTACIÓN
218

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
219

220. La fase de implementación
COMITÉ DIRECTIVO POSEEDOR DEL ANALISTA DE
DE SI PROBLEMA
Plan de implementación SISTEMAS
Anunciar la implementación
Obtener el
hardware
Obtener el
software
Controlar Controlar Preparar la
base de datos
Preparar las
facilidades físicas
Capacitar a los
participantes
y usuarios
Preparar la
propuesta de
terminación
Aprobar o desaprobar la propuesta de terminación
Terminar el nuevo sistema
220

221. Perfil para la propuesta de
requerimientos (RFP)
1. Carta de petición
2. Objetivos del sistema y restricciones aplicables
3. Diseño del sistema
3.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
221

222. DESARROLLO DE SI
COMPUTARIZADOS
LA FASE DE UTILIZACIÓN
222

223. La fase de utilización
COMITÉ DIRECTIVO POSEEDOR DEL ANALISTA DE
DE SI PROBLEMA SISTEMAS
Auditar el
sistema
Dar
Controlar Controlar mantenimiento
al sistema
Preparar la
propuesta de
reingeniería
Aprobar o desaprobar la
propuesta de reingeniería
223

224. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
INTRODUCCIÓN
224

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
225

226. Consideraciones preliminares
(2)
• 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
226

227. Consideraciones preliminares
(3)
• 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
227

228. Diferentes tipos de ciclos de vida
software
cascada pura codificar y
comercial
existente corregir
diseño por
espiral
herramientas
ciclos de vida
en el desarrollo
de SI
entrega cascadas
evolutiva modificadas
diseño por entrega por prototipo
planificación etapas evolutivo
228

229. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
CASCADA PURA
229

230. El modelo de cascada pura
• 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
230

231. Gráfica del modelo de cascada
pura
Planeación
Análisis
Diseño
Implementación
Utilización
231

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
232

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
233

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
234

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
235

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
236

237. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
CODIFICAR Y CORREGIR
237

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
238

239. Gráfica del modelo codificar y
corregir
codificar y
corregir
Entrega
Especificación
(quizás)
del sistema
(quizás)
239

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
240

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
241

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 242

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
243

244. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
ESPIRAL
244

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 245

246. Gráfica del modelo de espiral
Análisis de riesgo
Recolección de Planificación Análisis de riesgos basado en los
requisitos y requisitos iniciales
planificación
inicial del cliente Análisis de riesgo
basado en la
reacción del
cliente
Planificación
basada en los Prototipo inicial
comentarios del software
del cliente
Hacia el
Evaluación sistema final
del cliente
Prototipo del
siguiente nivel
Sistema de
Evaluación del cliente Ingeniería
ingeniería
246

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
247

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
248

249. Ventajas del modelo de espiral
(2)
• 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
249

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
250

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
251

252. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
CASCADAS MODIFICADAS
252

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 253

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
254

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
255

256. Variantes del modelo de
cascadas modificadas (3)
• 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
256

257. Gráfica del modelo de cascada
con fases solapadas
Planeación
Análisis
Diseño
Implementación
Utilización
257

258. Gráfica del modelo de cascada
con subproyectos
Planeación
Diseño
detallado
Análisis Codificación
y
depuración
Prueba del
Diseño subsistema
Diseño
detallado
Codificación
y
depuración
Diseño Prueba del
detallado subsistema
Codificación
y
depuración
Prueba del
subsistema Prueba del
sistema
258

259. Gráfica del modelo en cascada
con reducción de riesgos
Planeación
Análisis
Diseño
Implementa
ción
Utilización
259

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
260

261. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
PROTOTIPADO
EVOLUTIVO
261

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
262

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
263

264. Gráfica del modelo de
prototipado evolutivo
Inicio
Planeación y análisis
Parada
Producto Diseño
de rápido
Ingeniería
Construcción
Refinamiento
del
del
prototipo
prototipo
Evaluación del
prototipo por el
cliente
264

265. ¿Cuándo utilizar el prototipado
evolutivo?
• 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
265

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
266

267. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
ENTREGA POR ETAPAS
267

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 268

269. Gráfica del modelo de entrega
planeación por etapas
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
269

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
270

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
271

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
272

273. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
DISEÑO POR
PLANIFICACIÓN
273

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
274

275. El modelo de diseño por
planificación (2)
• 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
275

276. Gráfica del modelo de diseño
Planeación
por planificación
análisis
diseño
alta prioridad: diseño detallado,
implementación, utilización
prioridad media-alta: diseño detallado,
implementación, utilización
AGOTAMIENTO prioridad media: diseño detallado,
DEL PLAZO O implementación, utilización entrega
DEL
PRESUPUESTO
prioridad media-baja: diseño
detallado, implementación, utilización
prioridad baja: diseño detallado,
implementación, utilización
276

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
277

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
278

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
279

280. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
ENTREGA EVOLUTIVA
280

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
281

282. El modelo de entrega evolutiva
(2)
• 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
282

283. Gráfica del modelo de entrega
evolutiva
Planeación
Análisis
Entregar la
versión
final
Diseño
Desarrollar
una versión
Agregar la Entregar
realimentación la versión
del cliente
Realimentación
del cliente
283

284. Observaciones al modelo de
entrega evolutiva
• 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
284

285. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
DISEÑO POR
HERRAMIENTAS
285

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
286

287. Gráfica del modelo de diseño
por herramientas
Funcionalidad
soportadas por las
herramientas
Funcionalidad que
no va a estar en el
producto
Funcionalidad
que se va a incluir
Funcionalidad
ideal
287

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.
288

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)
289

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
290

291. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
SOFTWARE COMERCIAL
EXISTENTE
291

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
292

293. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
SELECCIÓN DEL CICLO DE
VIDA
293

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
294

295. Preguntas sobre la selección (1)
• 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?
295

296. Preguntas sobre la selección (2)
– ¿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?
296

297. Preguntas sobre la selección (3)
– ¿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?
297

298. Ventajas y desventajas de los
diferentes modelos (1)
Capacidades del Cascada Codificar y Espiral Cascadas Prototipado
modelo de ciclo de Pura Corregir Modificad Evolutivo
vida as
Trabaja con poca Malo Malo Excelente Medio a Excelente
identificación de los excelente
requerimientos
Trabaja con poca Malo Malo Excelente Medio a Malo a medio
comprensión sobre la excelente
arquitectura
Genera un sistema Excelente Malo Excelente Excelente Medio
altamente fiable
Genera un sistema Excelente Malo a Excelente Excelente Excelente
con amplio desarrollo medio
Gestionar riesgos Malo Malo Excelente Medio Medio
Estar sometido a una Medio Malo Medio Medio Malo
planificación
predefinida
298

299. Ventajas y desventajas de los
diferentes modelos (2)
Capacidades del Cascada Codificar y Espiral Cascadas Prototipado
modelo de ciclo de Pura Corregir Modificadas Evolutivo
vida
Requiere poco tiempo Malo Excelente Medio Excelente Medio
de gestión
Permite Malo Malo a Medio Medio Excelente
modificaciones a excelente
medio camino
Ofrece a los clientes Malo Medio Excelente Medio Excelente
signos visibles de
progreso
Ofrece a la directiva Medio Malo Excelente Medio a Medio
signos visibles de excelente
progreso
Requiere poca Medio Excelente Malo Malo a medio Malo
sofisticación para los
directivos y
desarrolladores
299

300. Ventajas y desventajas de los
diferentes modelos (3)
Capacidades del Entrega Entrega Diseño por Diseño por Software
modelo de ciclo de por Etapas Evolutiva Planificación Herramientas Comercial
vida
Trabaja con poca Malo Medio a Malo a medio Medio Excelente
identificación de excelente
los requerimientos
Trabaja con poca Malo Malo Malo Malo a excelente Malo a
comprensión sobre excelente
la arquitectura
Genera un sistema Excelente Medio a Medio Malo a excelente Malo a
altamente fiable excelente excelente
Genera un sistema Excelente Excelente Medio a Malo N/A
con amplio excelente
desarrollo
Gestiona riesgos Medio Medio Medio a Malo a medio N/A
excelente
Estar sometido a Medio Medio Excelente Excelente Excelente
una planificación
predefinida
300

301. Ventajas y desventajas de los
diferentes modelos (4)
Capacidades del Entrega Entrega Diseño por Diseño por Software
modelo de ciclo por Etapas Evolutiva Planificación Herramientas Comercial
de vida
Requiere poco Medio Medio Medio Medio a Excelente
tiempo de gestión excelente
Permite Malo Medio a Malo a medio Excelente Malo
modificaciones a excelente
medio camino
Ofrece a los Medio Excelente Medio Excelente N/A
clientes signos
visibles de
progreso
Ofrece a la Excelente Excelente Excelente Excelente N/A
directiva signos
visibles de
progreso
Requiere poca Medio Medio Malo Medio Medio
sofisticación para
los directivos y
desarrolladores
301

302. PLANIFICACIÓN DEL CICLO
DE VIDA DE SI
EL CICLO DE MUERTE DE
LOS SI
302

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
303

304. Curva de fallas para el
hardware
La curva de la “tina de baño”
Razón de
fallas “mortalidad infantil” desgaste
Tiempo
Cuando una componente de hardware se
desgasta se reemplaza por una refacción
304

305. Curva idealizada de fallas para
los SI
Razón de
fallas
No existen refacciones para el software
Mucho del software se construye a la medida
La razón de fallas permanece constante
Tiempo
305

306. Curva real de fallas para los SI
Razón de
fallas
Curva real
Curva ideal
Tiempo
Ocurrencia del
primer cambio
306

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
307

308. Gráfica del ciclo de muerte
Ingreso
Periodo de venta Muerte
de licencias Periodo de mantenimiento, económica
instalación, distribución,
soporte del producto, etc.
Tiempo
Periodo de desarrollo. Muerte técnica
Se requiere personal, (no se puede fijar
equipo,licencias, etc. con precisión)
Gasto
No mas
ventas
Inicio de Retirar del
ventas mercado 308

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 309

310. EL MODELADO DE LAS
EMPRESAS
LA ARQUITECTURA DE
ZACHMAN
310

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‖
311

312. La arquitectura de las empresas
(1)
• 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)
312

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
313

314. La gráfica de la arquitectura(1)
• Describe el diseño de • Adicionalmente se incluyen
artefactos que constituyen la entidades que incluyen los
intersección entre aspectos
– los roles en el proceso de – del alcance y visión
diseño (diseñador)
• dueño – el de implementador
• diseñador (subcontratado)
• constructor
– las abstracciones del producto
• de qué (material) está hecho
• cómo (proceso) trabaja
• dónde (la geometría) se
encuentran ubicadas las
componentes
314

315. La gráfica de la arquitectura(2)
DATA What FUNCTION How NETWORK Where
List of Things Important List of Processes the List of Locations in which
OBJECTIVES/ to the business Business Performs the Business Opeerates
SCOPE
(CONTEXTUAL)
Planner ENTITY = Class of Business Process = Class of Business Node = Major Business
Thing Process Location
e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics
ENTERPRISE System
MODEL
(CONCEPTUAL)
Owner Ent = Business Entity Proc = Bus Process Node = Business Location
Reln = Business Relationship I/O = Bus Resources Link = Business Linkage
e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System
SYSTEM Architecture
MODEL
(LOGICAL)
Node = I/S Function
Designer Ent = Data Entity Proc = Application Function (Processor, Storage, etc)
Reln = Data Relationship I/O = User Views Link = Line Characteristics
e.g. Physical Data Model e.g. System Design e.g. System Architecture
TECHNOLOGY
CONSTRAINED
MODEL
(PHYSICAL)
Node = Hardware/Systems
Builder Ent =Segment/Table/etc. Proc = Computer Function Software
Reln =Pointer/Key/etc. I/O = Data Elements/Sets Link = Line Specifications
e.g. Data Definition e.g. Program e.g. Network Architecture
DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Sub-
Contractor Ent = Field Proc = Language Statement Node = Address
Reln = Address I/O = Control Block Link = Protocol
FUNCTIONING
e.g. DATA e.g. FUNCTION e.g. NETWORK
ENTERPRISE
315

316. La gráfica de la arquitectura(3)
• 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
316

317. La gráfica de la arquitectura(4)
PEOPLE TIME MOTIVATION
List of Organizations List of Events Significant List of Business Goals/ SCOPE
Important to the Business to the Business Strategies
Ends/Means = Major Business Planner
People = Major Organizations Time = Major Business Event Goals/Critical Success Factors
e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan
ENTERPRISE
E1
E2
E1.1
MODEL
E1.3
(CONCEPTUAL)
E1.2
A1
People = Organization Unit Time = Business Event End = Business Objective Owner
Work = Work Product Cycle = Business Cycle Means = Business Strategy
e.g. Human Interface e.g. Processing Structure e.g. Business Rule Model SYSTEM
Architecture
E1
E2
MODEL
E1.1
(LOGICAL)
E1.3
E1.2
A1
People = Role Time = System Event End = Structural Assertion
Designer
Work = Deliverable Cycle = Processing Cycle Means = Action Assertion
e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY
E1
E2
MODEL
E1.1
E1.3 (PHYSICAL)
E1.2
A1
Work = Screen Format Time = Execute End = Condition Builder
People = User Cycle = Component Cycle Means = Action
e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Time = Interrupt Sub-
People = Identity End = Sub-condition
Cycle = Machine Cycle Means = Step Contractor
Work = Job
FUNCTIONING
e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
ENTEPRISE
317

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
318

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
319

320. Características de la
arquitectura (3)
• 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
320

321. Características de la
arquitectura (4)
– 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
321

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
322

323. T
M
ER E H T - F E K
N R R ER RW
T I A I CE A O
E S C UA M
P T R
D
A
TA W FT
a UO
ht NN
CI H NO W
w ER
o T K h
W e
re PL
EE
OP W T
o IE
h M W
h
en MT
O IN W
TO
I
VA h
y
SE
COP L fh Ipn
it Ts ot
s ig r
o nm t
a L f re t
it Ps h
s o ee
oc ss Lfo nw
it Li s h
s c i ih
o a nc
to Lf rno
it O a
s g tn
o ai s
i
z L f vs nn
it E Sc
s e i ia
o ng t
t f
i L f u so tt
it B sa r
s s G a
o ie l/
n s
S
SE
CO
P
The Zachman framework
t B spe
h s ses
e ie r
u O
n a
t Ipnt B s
mt h s s
o t e ie
r o u
t
a n tt B s
o u s
hs
e ie
n
( N U tt B s
CEA o u s
T L hs
O T)
X e ie
n B s rm
u sf s
s P
ie e
n or
( NU
CEA
O T)
T L
X
Pe
ln
ar
n E Yaf
N =s
T C
IT lso Fin ls
u =s
n Cf
ct
o a o N M us
o aB s
d jr s
e o ie
= n E e Muo
n a a sa
d n jr . l
s s o G
/M= B / Pe
ln
ar
n
B s ig
u sn
s T
ie h
n B sre
u sc
s Ps
ie o
n s P =oga
e Mrno T=os se
o a atn i e a usv
p jr
l
e O i s m jr ie n
i
z M nE
B t Cl u sc
r ac Fr
ic c a
t Ss t
i e o
Lin
o
ca
to
e e tM
. Sn o
gm d
. ai
c e
l e u sre o
.B scM
gs Ps d
. ie o
n s e
l eL tsto
. oce k
g g Nr
. ii
s w eWwe
. ol M
g r oo
. k
F dl e a Su
.M c l
gs he
. t
e e
r d e u sln
.B s
gs P
. ie a
n ERE
NR
T I
ES
P
ERE
NR
T I
ES
P
MOD
E
L M
OD
EL
( NU
CEA
O T)
C L
P ( NU
CEA
O T)
C L
P
O
w
ne
r EB sn
n u st
t s E
= ie i
n t
y P= ie re
r. B s o
o u sc
c s Ps
n s N B s cn
o u sa
d s Lt
e ie o
=n i
o P =atnt
e O aU
o rno i
p g i n
le iz T= ie v
i eus e
mss n
B E
n t E B sbv
n u sjc
d s Oe
= ie e
n t
i O
w
ne
r
R B se n
e u slt s
l = ie a h
n s R
n i i
o p I = ie ers
/ B s sc
Os s o
u R e
n u L B sne
ik u sk
n s Lg
= ie i a
n W or u
oWd
r
k r ot
=k c
P C B sy
y= ie c
c u sl
l
e s C
n e M= ie tt y
e B sr g
a u sa
n s S
s n e
e ol a o
. L atM
ggD d
. i
c a el eAa A c " e"s t S
. " pinh u
g l t ri te . D e s
. p oc r
i
c te g it u y
. r dt
i
b e
m e u Iee
.H nc
gm r
. atf
n a e re g c
. Ps Su
g ci t te
. o nr r
s u eB su o
., u sl M
gs R d
. ie e e
n l
SE
YM
S
T
SE
YM
S
T A c"
ri te
c u
h r
t
e Ac
ri te
c u
h r
te
MO
DE
L
M
OD
EL (G
LIA
OL
C)
(G
LIA
OL
C)
N I Fin
o / u
d Sc
e
= n t
o
EDn
na t
t tE
=ait
y P= la Fin (o oo ,t
r .A tn c
o p i u
c pon
i
c t
o Ps S e )
re , tae
c r r
s gc P =e
e R
o o
p l
le T= t E
i ey v
ms eSe n
mt E S rAin
n tc l s o
d rtas
= u e
u r
t
De
e r
si
gn R Den
e a lt s
l =aa h
n tR i i
op C Ps C
y=cig l
c re y
l
eo nc
s e De
e r
si
gn
I = riw
/ Ue
Oe ssV L LC tits
ik ie r e
n n a ri
= h sa c
c W ea
oD b
r
k lee
=i rl
v M= n e
e A Atn
a c si
n t
s io sor
T NG e hatM
CLY . P l a o
EOH O gy D d
. s
i
c a e l eS D "
. "s e
g t
.ye s
mn
ig eS A c "
. " s ri t e
g t
.y ec u
mt r
he e reinhu
. P t occ
g s t A te
. ea ri r
n t
e e ol tc
. C Su
g n rt e
. t
r u
o r e ue
.R s
gl D
. e in
g T NG
EO
CLY
H O
MOD
E
L CT E
OA
NI D
SNR
( YL
PIA
H )
SC M
OD
EL
( YL
PIA
H )
SC
N Ha y
o ar s
d r et
e d/ e
= w S m Br
u
ie
l
d
Br
u
ie
l
d ESeae
n e nbt
t g t l/c
= m e.
/
T P C t Fin
r. o en
o m u
c p
= u c
r t
o P =r
e U
o s
p e
l
e T= c
i ext
me Ee
u E Cin
n oo
d n
=di
t
Sr
oe
fa
t
w
R Pre .
e o/y
l = t Kc
n ie /
n e t I =e e F t
/ Sn iem
Or / v o s
c D r
e c a L L pcn
ik ie c t s
n n ea
= Si ii o
f Wc F t
oS o
rk rnm
=e ra
e C C nC
y= pnc
c o ey
l
e mt l
o e M=in
e A
a c
n t
s o
e a eo
. D fi n
g tDi
. ai t
n eP m
. "o "
g g
. rr
a e" tori c "
. Nr c te
g e k hu
. w At r
e eSi A c
. et ri te
g cy h u
. u c r
r te eTg iio
. i i Din
gm f t
. n ne e upcn
. R ea
g l Si t
. ec i
i o
f DE
E D
TAI
L
DE
E D
TA
IL
RS
E E
P N
R-
E RS
E E
P N
R-
E
TN
AS
TI
O TN
AS
TI
O
( T
OF
U-
-
O ( T
OF
U-O
CE
OT
N)
TX CE
OT
N)
TX
S
u
b- S
u
b-
Cc
o t
no
t r
ra EF
n il
t e
=d P Lu S
r. aa tt
o ngm
c ge
= N As
o ds
d de
e r s
= e P =t
e In
o dy
p e
l
e it T= rp
i e tr t
me I u
n E Soin
n un
d bd
= - io
ct
R As
e ds
l= r
n d e I = tl lc
/ C B
On o
oro k L Po
ik r c
n ol
=t s
o Wo
oJ
r b
k
= C M C
y= h y
c ae l
l
e c i
nce M=p
e S
a t
n e
s Cc
o t
no
t r
ra
F TIGe A
UO
NN
C N .D
I F TIG
UO
NN
CN
I
gT
. A e UO
.FT
gNN
. C
I eER
. NO
gT K
. W e RI T
.O ZN
g GA
. A I
NO e CU
. SD
g HL
. EE e TE
.S G
gR Y
. A
T
ERE
NR
T I
ES
P ERE
NR
T I
ES
P
Z a s tf Fer dce (01 1
a nt e r w ven82 5
c I i oa o am 13 3
h n
m t r mA
u k n t- ) -
0 C g J A m ca tnn
o ho . a a a net a
p t h Z n h Iri l
y - n c , m a
r
i h Z n o
323