Técnicas y métodos para sistemas
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Técnicas y métodos para sistemas

  • 15,403 views
Uploaded on

Técnicas y métodos prara el análisis y diseño de sistemas

Técnicas y métodos prara el análisis y diseño de sistemas

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • estudiante de universidad católoca los ángeles de chimbote
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
15,403
On Slideshare
15,402
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
304
Comments
1
Likes
2

Embeds 1

https://twitter.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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