miércoles, 14 de octubre de 2015

Metodológica De Sistemas Suaves (Jesus Barrios)


Metodología de Sistemas Suaves




¿QUÉ ES LA METODOLOGÍA DE SISTEMAS BLANDOS? 
La Metodología de Sistemas Blandos (SSM por sus siglas en inglés) de Peter Checkland es una técnica cualitativa que se puede utilizar para aplicar los sistemas estructurados a las situaciones asistémicas. Es una manera de ocuparse de problemas situacionales en los cuales hay una actividad con un alto componente social, político y humano. Esto distingue el SSM de otras metodologías que se ocupan de los problemas DUROS que están a menudo más orientados a la tecnología.





El SSM aplica los sistemas estructurados al mundo actual de las organizaciones humanas. Pero crucialmente sin asumir que el tema de la investigación es en sí mismo es un sistema simple. El SSM por lo tanto es una manera útil de acercarse a situaciones complejas y a las preguntas desordenadas correspondientes. 

PASOS DE LA METODOLOGÍA DE SISTEMAS BLANDOS. PROCESO

Etapa 1: Situación problema no estructurada.

La etapa inicial consiste simplemente en que los encargados y/o los empleados (propietarios del problema) deciden que son requeridos una revisión o un cambio de tareas y la manera en que debe realizarse y llaman a un analista (facilitador del problema). La gente de la organización acepta que puede haber un problema o ven una posibilidad de mejorar y son de la idea de que se inicie el análisis o la revisión. La metodología de sistemas suaves aporta en principio que el término 'el problema'es inadecuado porque hace que se minimice la visión de la situación. La metodología de los sistemas suaves cree que 'la situación problema' es un termino más apropiado puesto que puede haber muchos problemas que tienen la necesidad percibida a ser solucionados.  

Etapa 2: Situación problema expresada.

La etapa 1 incluyó básicamente las problemáticas, lo que la gente de la organización sospecha que puede haber un problema y/o un posibilidad para la mejora, y pide iniciar el análisis o la revisión. En la etapa 2, el analista recoge y clasifica la información y prové una cierta descripción de la situación problema. Lo siguiente es la información que estamos buscando:  
  • la estructura de la organización: esos factores que no cambian fácilmente (las construcciones, las localizaciones, el ambiente, etc);
  • procesos o transformaciones que se realizan dentro del sistema: muchos de éstos están cambiando constantemente;
  • hechos que son expresados o sentidos por los miembros de organización (quejas, críticas, sugerencias, etc).
Hay muchas estrategias que los analistas pueden emplear cuando recogen los hechos, más allá de enfoques muy informales, no estructurados a las herramientas hasta las muy formales, estructuradas empleadas en análisis tradicional de los sistemas. Algunas de las técnicas son:  
  • Observación del trabajo:
    • identificación de las tareas realizadas
    • identificación de las herramientas empleadas
    • establezca las interacciones entre personas/sistemas
    • produzca registros, anote.
    • descripciones de un"día en la vida "
    • haga los gráficos de estructuras/layouts
    • grabaciones video, si es posible.
    • recoja las muestras de las herramientas usadas para manejar la información
    • coleccione la observación de cada participante
  • Entrevistas:
    • no estructurada, informal ("dígame lo que usted hace")
    • semi estructurada (cuestionario con respuestas ampliables)
    • altamente estructurada (cuestionario con rectángulos a hacer tictac)
    • incidentes críticos
    • grabación audio
  • Talleres y discusión:
    • talleres futuros
    • talleres de la revisión
    • talleres de las resoluciones del conflicto
    • la mofa sube, las simulaciones, juegos de la mente
La etapa 1 y la etapa 2 son una fase de la 'expresión' durante a la cual una tentativa se hace para construir la posible visión enriquecida, no 'el problema' sino la situación que allí se percibe como problema. Es muy importante no reducir nuestro alcance de la investigación demasiado rápido. Si seleccionamos un enfoque muy estructurado tal como un cuestionario bien escogido múltiple al principio de nuestro estudio, y construimos un modelo en base de esos resultados solamente, excluimos probablemente mucha de la información que podrían ser relevante. Pues una estrategia general, por lo tanto, es mejor emplear una selección no estructurada técnicamente desde el principio, y emplear más bien técnicas estructuradas después de que una primera impresión del problema se haya definido, con el fin de sacar la información detallada o de controlar suposiciones. Las técnicas específicas se deben seleccionar siempre para caber adentro con el trabajo de la organización, y cada una que está proveiendo la información debe ser informada acerca de cuál es el propósito del análisis.

Cuando un analista saca la información de los miembros de una organización, éste se comunica con ellos usando el lenguaje natural (español). Esto plantea númerosos problemas y potenciales trampas. El analista debe estar preparado para aceptar que en esta etapa, la información obtenida es incompleta y contiene contradicciones y ambigüedades. El sistema al cual estamos mirando es un sistema suave y por lo tanto la información acerca del sistema es probable que sea cualitativa más bien que cuantitativa.

La Visión Enriquecida.

La visión enriquecida se utiliza para proveer un modelo para pensar acerca del sistema y para ayudar al analista a obtener una apreciación de la situación problema. Es importante notar la diferencia entre visión enriquecida y modelo formal. La visión enriquecida no procura modelar al sistema de una manera particular. Provee una representación de cómo podemos mirar y pensar acerca el sistema. Ésta puede ser refinada conforme nuestra comprensión del sistema llega a ser más clara, dado qué deseamos hacerla más clara. La visión enriquecida mostrada en el cuadro 4 se basa en el estudio del caso Shell "Repensando una función de servicio del grupo Shell ". El círculo representa el límite del sistema, los círculos pequeños representan a los componentes del sistema, mientras que aquellos círculos del exterior son las entidades externas con las cuales el sistema interctúa. Las burbujas representan a las ideas actuales de la gente, en ese grupo de servicio: deseaban saber que tan buena era su organización y cómo evaluar su funcionamiento actual porque deseaban mejorla.

La visión enriquecida es una expresion intelectual e individualista, y por lo tanto no se puede calificar de "correcta" o "incorrecta". Sin embargo, la visión enriquecida debe representar a la estructura, a los procesos y a los hechos de la organización que podrían ser relevantes en la definición de problema, y debe intentar dar una impresión del clima de la organización. Cada analista o equipo desarrollará a su propio estilo la visión enriquecida. Se puede comenzar con la gente o las localizaciones; puede poner objetos, items o hechos o dígitos binarios para intentar agruparlos o encerrarlos en la estructura. La visión enriquecida no es un mapa del modelo del sistema (que se genera en fases posteriores), ni tampoco debe ser un organigrama (la clase de mapa de jerarquía de gestión que las organizaciones utilizan a menudo para describirse a sí mismas).

Los hechos obtenidos se pueden poner en un índice o agrupar según temas o causas. En estudios grandes, las herramientas computarizadas tales como una base de datos o un sistema de hipertexto se pueden utilizar para guardar y manejar la información obtenida.
La necesidad siguiente del análisis de ser realizado en un visión enriquecida para la situación problema expresada:  
  • El rol del análisis de la intervención, es un análisis que identifica deliberadamente las hechos encontrados implicados en la situación y que se piensan como problemáticas.
  • El análisis social, identifica las misiones de la gente completa de la organización, las normas del comportamiento según visualización de esa gente y los valores por los cuales su comportamiento es juzgado.
  • el análisis del poder, se refiere a hechos tales como 'cuáles son los objetos del poder en esta situación' , 'cuál es la materia obtenida' , y 'cómo es la materia pasada'

Ilustración Global de las etapas 1 y 2 de la SSM.

Un diagrama de la transformación fue producido para ilustrar la primera etapa 1 y la etapa 2 en SSM como el mostrado en el cuadro 2:



Proceso de transformación para producir una Visión Enriquecida

La ayuda del propietario del problema es la entrada de información al proceso. El facilitador de problema realizará el análisis del sistema suave y terminará satisfactoriamente con una Visión Enriquecida como producción de este proceso de transformación. El analista utilizará la Visión Enriquecida. para ayudarse en su comunicación con el propietario del problema. Ëste le notificará del conflicto observado del personal y la función. La Visión Enriquecida se utiliza para identificar problemas e informar al propietario de la situación problema más bien que proverle de la solución posible.



Trampas que necesitan ser evitadas

Las trampas siguientes necesitan ser evitadas durante la etapa inicial de SSM: 

  • No reducir el alcance de la investigación muy al principio.
  • La visión enriquecida se ensambla sin la imposición de una estructura y/o de una solución determinada a la situación problema.
  • Pueble tienen difícil de interpretar el mundo de la manera floja, y muestran a menudo un deseo concluído-urgente para la acción.
  • No presionar el análisis en términos de los sistemas en todos.
  • Advertir que habrá muchas versiones posibles del sistema.

Etapa 3: Nombramiento de los Sistemas Relevantes.

Definiciones raíz.

Es necesario prestar atención a la formulación del nombramiento de los sistemas relevantes para escribirlos de manera que un modelo pueda ser construido basado en cada nombramiento. Estos nombramientos se conocen como Definiciones Raíz. El propósito de la definición raíz es expresar el propósito central de un cierto sistema útil de actividad. Es importante que se ponga atención en el desarrollo de las definiciones raíz. Las definiciones raíz correctamente escritas proveen una directriz mucho más simple en la construcción del modelo de un sistema.

Una definición de raíz se expresa como un proceso de la transformación que toma una entidad como entrada de información, cambia o transforma a esa entidad, y produce una nueva forma de la entidad. Una prescripción para desarrollar estos procesos la transformación se muestra en la siguiente tabla, que muestra ejemplos de transformaciones típicas de la operación de un curso de golf. Como usted puede notar, estas transformaciones variarán grandemente, dependiendo de la opinión del mundo que se aplique.

ENTRADA DE INFORMACIÓNPRODUCCIÓNCOMO ES VISTO A LOS OJOS DE:
Pista inusitadaPista ocupada por curso del golf.Arquitecto.
Necesidad por tiempos de la te.La necesidad por tiempos de la te se resuelve.Gestión Del Club.
Bolas nuevas del golf.Utilizado, rascado encima de bolas del golf.Industria del equipo.
Germen de la hierbaHierba madura.Greenskeepers
Alimento crudo.Comidas de calidad.Cocinero de la cocina.
Golfer registrado.Golfer que terminó alrededor en X frota ligeramente.Favorable personal del departamento.
Programa de la lección del golf.Programa facilitado de la lección.Profesional del Club.


Transformaciones una a una que implican opiniones diferentes del mundo.

Producir una definición de raíz es un proceso progresivo de dos pasos.
  1. Un hecho o una tarea se elige de una visión enriquecida
  2. Se define un sistema para realizar la tarea o para dirigir los hechos.
Cada definición raíz implica dos cosas importantes. Lo primero es que debemos implicar cierta visión del mundo. La definición de la opinión del mundo no es siempre trivial. También, no es deseable definir todas las opiniones del mundo. Recuerde que cada visión enriquecida implicará una variedad de opiniones del mundo. Los ojos pueden venir de fuentes tales como oficiales del gobierno, ejecutivo de compañías, encargados del proyecto, empleados, clientes, competidores y medios de noticias. Cada una de estas opiniones del mundo será conectada a unas o más definiciones raíz distintas.

Es importante prestar la atención a la cardinalidad del proceso de la transformación. Cada definición raíz implica una transformación de una entrada en una producción. Suponga que definimos una transformación como el " equipamiento de golf " más " curso del golf " más " mano de obra " (tres entradas de información) para producir "necesidades de golf puestas" más "mercado de golf servido" (dos producciones). Esta transformación " tres a dos " es ambigua, pero se puede resolver con muchas transformaciones una a una que se correspondan más claramente (el equipamiento de golf se transforma en equipamiento de golf usado ).

Etapa 4: Modelos Conceptuales.

Dado una definición raíz de un sistema, un modelo conceptual puede ser modelo conceptual trazado de A es un modelo humano de la actividad que estrictamente se conforma con la definición raíz usando el conjunto mínimo de actividades. Los pensamiento de sistemas se aplican en este desarrollo. 
Pensamiento de Sistemas.



La Ruta del Pensamiento de Sistemas.
 muestra que los pensamiento de sistemas es un proceso iterativo que combina tres conceptos
  • El mundo percibido:Cada uno de nosotros tenemos nuestras propias opiniones del mundo.
  • Ideas:Percibimos el mundo a través del marco de ideas que están internas en nosotros.
  • Metodología: Hay muchas de éstas para pensar acerca del mundo, la SSM es solo una.

Modelación de Sistemas Formales

El Pensamiento de Sistemas Formal se aplica al desarrollo del modelo conceptual. El Modelo Formal del Sistema sirve como una guía de consulta para controlar el modelo conceptual que trazamos. Deje que S represente a un sistema de actividad humana. Bajo el modelo de Sistema Formal, S es un sistema formal si y solamente si cumple los criterios siguientes:
S debe tener una misión.
  • S debe tener una medida del funcionamiento.
  • S debe tener un proceso de toma de decisión
  • S debe tener componentes que interactuan con unos con otros tal que los efectos y acciones son transmitidos a través del sistema.
  • S debe ser acotado por un sistema más amplio con el cual interactua.
  • S se debe limitar del sistema más ancho, basado en el área donde su proceso de toma de decisión tiene poder para hacer cumplir una acción.
  • S debe tener recursos a disposición de su proceso de toma de decisión.
  • S debe tener estabilidad a largo plazo, o la capacidad de recuperarse en el caso de un disturbio.
  • Componentes de S deben ser sistemas que tienen todas las características de S (subsistemas).
El modelo conceptual se puede escribir como gráfico dirigido, similar a una gráfica PERT. Los nodos en el gráfico son actividades que se harán. Estas actividades se basan en los verbos de la definición raíz. La estructuración del sistema se basa en la dependencia lógica. Las dependencias lógicas se muestran como arcos en el gráfico. Un arco en el gráfico significa que la actividad de la fuente es un requisito previo para la actividad de la destinación.

El modelo conceptual para un sistema consiste de un sistema operacional que se cubra - pero limitado por - un proceso de monitoreo. Este sistema operacional consiste en una actividad central y algunas actividades prerequisitos se requieren tal que la actividad central pueda ser hecha. La psicología cognoscitiva sugiere que el cerebro humano pueda hacer frente a 7 +/- 2 conceptos al mismo tiempo. Por lo tanto, debemos apuntar tener 7 +/- 2 actividades dentro de cada sistema operacional. Si esta guía de consulta conduce a actividades que están en un nivel demasiado alto, esas actividades se pueden ampliar a otro nivel. Puesta simplemente, cada actividad general se convierte en una fuente para que una definición raíz sea ampliada al nivel siguiente.

Monitorear un sistema.

Monitorear un sistema operacional consiste en tres actividades:
  • Defina una medida del funcionamiento: Podemos utilizar cualesquiera o las tres para la medida del sistema operacional
    • Eficacia - trabaja
    • Eficiencia - cuánto del trabajo terminó con los recursos consumidos dados
    • Eficacia - son las metas satisfechas.
  • Monitorear las actividades en el sistema operacional, de acuerdo con la métrica definida en etapa 1.
  • Tomar la acción del control: Utilice los resultados de estas métricas para determinar y para ejecutar la acción que controle al sistema operacional.
Sin embargo las tres e mostradas arriba no son las únicas métricas que pueden ser utilizadas. Muchas firmas utilizarán métrica incluyendo las métricas económicas, éticas , elegantes, y otras que pueden ser dependientes en el contexto del trabajo que es hecho.

Etapa 5: Comparar modelos conceptuales con realidad

Ésta es la etapa de regreso al mundo verdadero, pasando sobre la línea punteada. En esta etapa, los modelos conceptuales construidos en la etapa 4 serán comparados con la expresión verdadera del mundo, de la etapa 2. El trabajo puede conducir en esta etapa a la reiteración de la etapa 3 y la 4. Previa experiencia anterior de usar SSM indicó que la comparación no es de hecho una comparación propiamente dicha. Esto será discutido más adelante. Basado en el análisis razonado de esta metodología, hay cuatro maneras de hacer la comparación del número de experiencias.

Antes de que se realice la comparación, varios otros aspectos necesitan ser mencionados. La primera pregunta es cuál es el fin de la etapa 4. Cuando deberá ser tiempo de parar de construir el modelo conceptual y de moverse a la comparación verdadera del mundo. La tentación siempre es complacer la prolongación y elaboración de la construcción del modelo. Es divertido trabajar en modelar y no es tan cómodo traer al modelo a la realidad y engancharse con las dificultades de las situaciones del problema. De hecho, de la experiencia de Checkland, es mejor moverse rápidamente a la etapa de la comparación. Se permitirá refinar el modelo posteriormente cuando tenga que ir de nuevo a la etapa de la conceptualización otra vez.

Antes de que resumamos la etapa 5 de SSM, necesitamos entender la definición de comparación. Generalmente, comparación es una parte importante del pensamiento racional y serio que contiene percibir, predecir y comparar. En SSM, Checkland define la comparación como el punto que las opiniones intuitivas del problema son reunidas con las construcciones de los sistemas por lo que los pensadores de sistemas afirman proveer una profundidad epistemologica y más generalidad de la realidad debajo de los aspectos superficiales; es la etapa de la comparación la que incorpora las hipótesis básicas de los sistemas que los conceptos de los sistemas proveen un medio de prueba de la complejidad de la 'realidad' .

Cuatro maneras de hacer la comparación pueden ser resumidas como sigue:

1. Usar los modelos conceptuales como base para cuestionamientos ordenados

Éste es un tipo de comparación que puede ser hecha cuando la situación verdadera del mundo es muy diferente del modelo conceptual. Los modelos del sistema se utilizan para abrir un debate acerca del cambio. El modelo se utiliza como fuente de preguntas acerca de la situación existente. Se anotan y se contestan las preguntas sistemáticamente. Las respuestas a las preguntas pueden proveer la iluminación al problema percibido.

2. Comparar historia con predicción del modelo

Otro método de comparación es hecho reconstruyendo una secuencia de eventos en el pasado y comparando qué habría sucedido en producirla con lo que habría sucedido si lo modelo conceptual relevante han puesto en ejecución realmente. De esta manera, el significado de los modelos puede ser exhibido y satisfactorio de la comparación puede ser alcanzado. Basado en experiencia de Checkland, esto es un método usado con éxito para un consultor que deseó saber porqué uno el suyo estudia para un cliente había sido un incidente espectacular. En que el caso, el contenido entero del estudio era historia, y el análisis comparó la historia como recordada y registrada en ese entonces por los participantes, con un modelo de sistema de la interacción de consultant/client. Checkland también advirtió que este método de comparación fuera utilizado cuidadosamente de modo que pueda revelar las insuficiencias del procedimiento real y pueda ser interpretado como recriminación ofensiva referente a su último funcionamiento.

3. Comparación Total General

Checkland sugirió que en la ilustración de la metodología en su totalidad, sea generalmente apropiado a la comparación de la etapa 5 general, preguntando qué características de los modelos conceptuales son especialmente diferentes de la actual realidad y porqué. Esta comparación también se discute generalmente con " cuál está " y "Hows" por Checkland. Es la distinción entre 'qué y' cómo cuál hace la palabra 'comparación' una descripción algo cruda de lo que está sucediendo en la etapa 5. Checkland precisa que en la etapa 5, tenemos modelos de sistemas disponibles que ellos mismos derive del nombramiento cuidadoso, en definiciones de la raíz, de los sistemas humanos de la actividad que esperamos es relevante a la situación problema y a su mejora. En la etapa 5, examinamos los modelos junto a la expresión de la situación ensamblada en la etapa 2. que la comparación entre los dos es la estructura formal de los cambios acerca de posibles de una discusión, una discusión del problema celebrada con la gente en cuestión en la situación problema. Para que la discusión sea rica y de amplia extensiona, deseamos preguntar así como si las varias actividades en los modelos perceptibles en el mundo verdadero, - si ella está presente - cómo está bien la están haciendo. También deseamos discutir alternativas posibles a las actividades verdaderas del mundo. Veremos cómo esta comparación será realizada en un estudio de caso ilustrado más adelante. Aquí la comparación de amplia extensiona con excepción de como con como se acentúa y ahora podemos ver porqué la etapa 5 no es una comparación directa.

4. Recubrimiento Modelo

El cuarto método de hacer la etapa 5 es referido como " recubrimiento modelo " por Checkland. Para la comparación, después de terminar la conceptualización basada en la definición elegida de la raíz, hicimos un segundo modelo de qué existe. El segundo modelo tiene como cercanos como posible la misma forma que el modelo conceptual, siendo el objetivo el de re el drenaje que modelen, cambiándolo solamente donde la realidad diferenció del modelo conceptual. Con este método, el recubrimiento directo de un modelo en el otro entonces reveló la discordancía que es la fuente de la discusión del cambio. Con este método, preguntas tales como qué definición raíz es implicada por este sistema? Cómo compara con el que era la base de la conceptualización en la etapa 4?

Los cuatro métodos pueden ayudar a asegurar la comparación en la etapa 5 son conscientes, coherentes y defendibles. Dependiendo de los problemas percibidos, el método determinado se puede utilizar para hacer la comparación, o todas las clases de comparación se pueden realizar con todos estos cuatro métodos. Para el sistema existente, la comparación puede ser hecha con qué existe, pero para un nuevo sistema, la comparación no puede estar con qué existe, sólo con una cierta expectativa redefinida. En este caso, la experiencia anterior implicó que el incrementalism y el ensayo y el error son el enfoque mejor.


Etapas 6 y 7: Poner cambios en ejecución 'factibles y deseables'

En la etapa 6, se identifican y se discuten los cambios factibles y deseables, y serán puestos en la acción en la etapa 7. que el propósito de la etapa de la comparación es generar los cambios acerca de posibles del discusión que se pudieron realizar dentro de la situación percibida del problema. Esto se puede ver claramente con el segundo método de hacer la comparación como discutido arriba.
El resultado de la etapa 6 y 7 para el sistema duro y suave ambos es la creación y la puesta en práctica de un sistema. Generalmente, en estas situaciones más nebulosas del problema, la acción eventual es probable sea menos que la puesta en práctica de un sistema, es más probable que halla la introducción de un cambio más modesto.
Normalmente, hay tres clases de cambios:
  • cambio en la estructura, son cambios realizados a esas partes de realidad que en corto plazo, en el funcionamiento que continúa de cosas, no cambian.
  • cambio en el procedimiento, que son cambios a los elementos dinámicos
  • cambio en la actitud, que es comportamiento apropiado a las varias misiones, así como cambios en la preparación a ciertas clases de comportamiento 'bueno' o de 'malo' concerniente a otros.
Los cambios en estructura y procedimiento son fáciles de especificar y relativamente fácil poner en ejecución. Por lo menos, éstos se pueden hacer por la gente que tiene autoridad o la influencia. Es relativamente difícil cambiar actitud. Es posible en principio intentar traer acerca de cambios de esta clase. Si o no esto está procurada, el esencial principal debe continuamente vigilar actitud si se van los cambios a ser hechos en las situaciones percibidas como problemas de modo que la gente en cuestión en la situación convenga que se ha logrado la mejora . Una de las características importantes en SSM es él énfasis en cambio.

Otra característica importante de SSM es la meta conducida, se concentra en un sistema deseable y cómo alcanzarlo. Checkland indicó que los cambios deben ser sistemáticamente deseables como resultado de la penetración ganada de la selección de las definiciones raíz y de la construcción del modelo conceptual, y deben también ser culturalmente factibles dadas las características de la situación, de la gente en ella, de sus experiencias compartidas y de sus prejuicios. Es duro encontrar cualquier cambio que no resuelvan ambos criterios . Checkland encontró en uno de sus estudios de casos que es importante moverse rápidamente y ligeramente a través de todas las etapas metodológicas, varias veces en caso de necesidad, para ser un puente del técnico entre los 'qué y 'qué pudo ser' . Él también sugirió que para poder tener que incorporar la 'raíz obligáramos a comprometer una situación que propuso cambios tenga que ser cambiante debido a la influencia del poder.

El empleo en la etapa 7 debe poner cambios en ejecución y ponerlos en la acción. Cuando se toma la acción, puede ser que sea directa. Sin embargo, otras situaciones pueden ser encontradas. La introducción de la acción puede cambiar la situación de modo que aunque se ha eliminado el problema originalmente percibido , emerja el nuevo problema. Se recomienda a menudo que un sistema temporal esté utilizado para realizar la tarea bajo supervisión del analista, seguida por una transición a la operación del nuevo sistema. Checkland precisó que esta metodología tiene de hecho no emergente mientras que un acercar algo definió de una vez por todas sostenidamente como problema, pero percibió como problema.  

Hecho por Jesus Barrios 6D02IS


METODOLOGÍA DE JENKINS

METODOLOGÍA DE JENKINS


                   Ingeniería de Sistemas no es una nueva disciplina, ya que tiene sus raíces en la práctica de la Ingeniería Industrial. Sin embargo, enfatiza el desempeño global del sistema como un todo, en contraposición al desempeño de partes individuales del sistema. Una característica importante de la Ingeniería de Sistemas es el desarrollo de modelos cuantitativos, de tal forma que una medida de desempeño del sistema pueda optimizarse.
La palabra “Ingeniería” en Ingeniería de Sistemas se usa en el sentido de “diseñar, construir y operar sistemas”, esto es, “ingeniar sistemas”. Otra de las
Características de la Ingeniería de Sistemas es la posibilidad de poder contemplara través de su metodología, la solución de problemas completamente diferentes que provienen de áreas muy diferentes como la tecnología y la administración, enfatizando sus características comunes a través de isomorfismos que puedan relacionarlos. Es por esto que cuando la Ingeniería de Sistemas se aplica a la solución de problemas complejos, incluye la participación de profesionales en áreas muy diferentes y no sólo la participación de ingenieros. UNA METODOLOGÍA DE INGENIERÍA DE SISTEMAS. Un enfoque de sistemas a la solución de problemas En esta sección se proporcionan las líneas de guía generales que usaría un Ingeniero para confrontar y solucionar problemas. Las diferentes etapas que se describen posteriormente, representan un desglose de las cuatro fases siguientes:

FASE 1: Análisis de Sistemas
El Ingeniero inicia su actividad con un análisis de lo que está sucediendo y por qué está sucediendo, así como también de cómo puede hacerse mejor. De esta manera el sistema y sus objetivos podrán definirse, de forma tal que resuelva el problema identificado.

ANALISIS DE SISTEMAS: Identificación y formulación del problema

Organización del proyecto Definición del sistema, Definición del suprasistema, Definición de los objetivos del suprasistema, Definición de los objetivos del sistema, Definición de las medidas de desempeño del sistema Recopilación de datos e información.
FASE 2: Diseño de Sistemas
Primeramente se pronostica el ambiente futuro del sistema. Luego se desarrolla un modelo cuantitativo del sistema y se usa para simular o explorar formas diferentes de operarlo, creando de esta manera alternativas de solución. Por último, en base a una evaluación de las alternativas generadas, se selecciona la que optimice la operación del sistema.
SISTEMA DISEÑO DE Pronósticos Modelación y simulación del sistema Optimización de la operación del sistema Control de la operación del sistema Confiabilidad del sistema
FASE 3: Implantación de Sistemas
Los resultados del estudio deben presentarse a los tomadores de decisiones y buscar aprobación para la implantación del diseño propuesto. Posteriormente, tendrá que construirse en detalle el sistema. En esta etapa del proyecto se requerirá de una planeación cuidadosa que asegure resultados exitosos. Después de que el sistema se haya diseñado en detalle, tendrá que probarse para comprobar el buen desempeño de su operación, confiabilidad, etc.
SISTEMAS MPLANTACIÓN DE Documentación y autorización del sistema Construcción e instalación del sistema
FASE 4: Operación y Apreciación Retrospectiva de Sistemas
Después de la fase de implantación se llegará al momento de “liberar” el sistema diseñado y “entregarlo” a los que lo van a operar. Es en esta fase donde se
Requiere mucho cuidado para no dejar lugar a malos entendimientos en las personas que van a operar el sistema, y generalmente representa el área más descuidada en el proyecto de diseño. Por último, la eficiencia de la operación del sistema debe apreciarse, dado que estará operando en un ambiente dinámico y cambiante que probablemente tendrá características diferentes a las que tenía cuando el sistema fue diseñado. En caso de que la operación del sistema no sea satisfactoria en cualquier momento posterior a su liberación, tendrá que iniciarse la fase 1 de la metodología, identificando los problemas que absolutizaron el sistema diseñado. APRECIACIÓN RETROSPECTIVA DE SISTEMAS OPERACIÓN Y Operación inicial del sistema Apreciación retrospectiva de la operación del sistema Mejoramiento de la operación del sistema diseñado.


Arellano Keiber

Cauro Mariana

Metodología Espiral
Yeferson Cardenas
Elieth Picon

La Ingeniería de software, se vale y establece a partir de una serie de modelos que establecen y muestran las distintas etapas y estados por lo que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina «modelos de ciclo de vida del software». El primer modelo concebido fue el de Royce, más comúnmente conocido como desarrollo en cascada o desarrollo lineal secuencial. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software se suceden de forma lineal.

PROCESO DE DESARROLLO DE SOFTWARE 

El desarrollo de un software en sí es complejo, es usualmente no viable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una gran combinación de factores que imposibilitan realizar una verificación minuciosa de todas las posibles situaciones de ejecución que se puedan presentar. Poniendo como ejemplo la creación de un sistema operativo, esto es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. 
Un desarrollo de software es imperceptible y por lo general muy abstracto, esto pone trabas en la definición del producto y sus requisitos, más que nada cuando no se tiene precedentes definidos de un desarrollo de software similar. Esta situación va hacer que los requisitos sean difíciles de consolidar con anterioridad. Es por esto que ahora los cambios en los requisitos son inevitables, no sólo después de entregado el producto sino también durante el proceso de desarrollo. Sea cual fuere el proceso utilizado y aplicado al desarrollo del software, casi siempre libremente de este proceso, se debe aplicar un modelo de ciclo de vida. Según varias fuentes consultadas se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrasan y un 26% son totalmente exitosos. Cuando un proyecto de desarrollo de software “fracasa” (28% estadísticamente), muy rara vez es causado por fallas técnicas, principalmente el origen de los fallos y fracasos es la falta de aplicación de una buena metodología o procesos de desarrollo. Una fuerte tendencia, desde hace pocos años, es mejorar las metodologías y procesos, o crear nuevas e incentivar a los profesionales de la informática en su aplicación adecuada, normalmente utilizan sus conocimientos especializados con modelos, paradigmas y procesos obsoletos que ya fueron diseñados.
MODELO ESPIRAL 
El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue cuatro pasos principales:
 1. Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos. 
2. Análisis del riesgo. En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas. 
3. Desarrollar, verificar y validar. En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla.
 4. Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. Con cada iteración alrededor de la espiral, se crean sucesivas versiones del software, cada vez más completas y, al final, el sistema de software ya queda totalmente funcional. 

La diferencia principal entre el modelo espiral y los modelos anteriores (ej.: cascada, evolutivo, incremental, etc.) es la evaluación del riesgo. El riesgo es todo lo que pueda salir mal en un proyecto de desarrollo de software. Por ejemplo, si queremos utilizar un lenguaje de programación para desarrollar un sistema operativo, un riesgo posible es que los compiladores utilizables no produzcan un código objeto eficiente. Los riesgos originan problemas en el proyecto, como el exceso de los costos. Es así que, la disminución de los riesgos es una actividad muy importante. 
Un modelo espiral comienza con la determinación de los objetivos tanto funcionales como de rendimiento. Después se enumeran algunas formas posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles. Luego continuamos con el siguiente paso que es resolver estos riesgos y llevar a cabo las actividades de desarrollo, para finalizar con la planificación del siguiente ciclo de la espiral.

Ventajas

• Reduce riesgos del proyecto
• Incorpora objetivos de calidad
• Integra el desarrollo con el mantenimiento.
Desventajas

• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos
Inconvenientes

Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia.
El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV.
ACOPLAMIENTOS DEL MODELO ESPIRAL

 Los nuevos requerimientos del sistema se definen en todo los detalles posibles, esto implica generalmente el entrevistarse con un número determinado de usuarios que representarán a todos los usuarios tanto externos como internos y otros aspectos del sistema existente. 
Un prototipo preliminar se crea para el desarrollo del nuevo software partiendo de un diseño hecho del sistema que se construyó del prototipo inicial. Esto es generalmente un sistema scaled-down, y representa una aproximación de las características del producto final. 
Un segundo diseño de software es desarrollado por un procedimiento cuádruple:
Evaluación del primer prototipo en términos de sus fuerzas, debilidades, y riesgos; 
·         Definir los requisitos del segundo prototipo; 
·         Planeando y desarrollando el segundo prototipo;
·         Construyendo y probando el segundo prototipo. 
En la opción del cliente, el proyecto completado puede ser abortado si el riesgo se juzga demasiado grande. Los factores de riesgo pudieron implicar los excesos de coste del desarrollo, cálculo erróneo del fusionar los costes, o cualquier otro factor que podría, en el juicio del cliente, dar lugar a un producto final menos que satisfactorio. 

El diseño existente se evalúa de manera semejante al igual que el diseño anterior, y, en caso de necesidad, otro prototipo se desarrolla de él según el procedimiento cuádruple expuesto anteriormente. Se iteran los pasos precedentes hasta que el cliente está satisfecho sabiendo que el diseño mejorado representa el producto final deseado. Además, se construye el sistema final, basado en el diseño mejorado. El sistema final se evalúa y se prueba con todas las de ley. El mantenimiento general se realiza sobre una base continua para prevenir fallas en grande y para reducir al mínimo el tiempo perdido. 



Metodologia de Hall

METODOLOGÍA DE HALL
Nieves Lucena
Yelsy Rodriguez 

   I. INTRODUCCIÓN
Uno de los campos en donde con más intensidad se ha sentido la necesidad de utilizar conceptos y metodologías de ingeniería de sistemas en el desarrollo de tecnología. Esto se debe a que los sistemas técnicos, que sirven para satisfacer ciertas necesidades de los hombres, están compuestos de elementos interconectados entre sí de tal forma que se hace necesario pensar en términos de sistemas, tanto para el desarrollo de nueva tecnología como para el análisis de la ya existente.
II. METODOLOGÍA
Los pasos principales de la metodología de hall son:
·         Definición del Problema
·         Selección de Objetivos
·         Síntesis de Sistemas
·         Análisis de Sistemas
·         Selección del Sistema
·         Desarrollo del Sistemas
·         Ingeniería

1.    DEFINICIÓN DEL PROBLEMA.
Se busca transformar una situación confusa e indeterminada, reconocida como problemática y por lo tanto indeseable, en un estatuto en donde se trate de definirla claramente. Esto sirve para:
a)    Establecer objetivos preliminares.
b)     El análisis de distintos sistemas.
De la definición del problema los demás pasos de la metodología dependen de como haya sido concebido y definido el problema. Si la definición del problema es distinta lo que realmente es, lo más probable es que todo lo que se derive del estudio vaya a tener un impacto muy pobre en solucionar la verdadera situación  problemática.
La definición  del problema demanda tanta creatividad como el proponer soluciones. El número de posibles soluciones aumenta conforme el problema es definido en términos más amplios y que disminuyen al aumentar el número de palabras que denotan restricciones dentro de la restricción.
Existen dos formas en como nacen los problemas que son resueltos con sistemas técnicos.
a)    La búsqueda en el medio ambiente de nuevas ideas, teorías, métodos, y materiales, para luego buscar formas de utilizarlos en la organización.
b)    Estudiar la organización actual y sus operaciones para detectar y definir necesidades.
Estas dos actividades están estrechamente relacionadas y se complementan una a otra.
            INVESTIGACION DE NECESIDADES
Las necesidades caen dentro de tres categorías.
a)    Incrementar la función de un sistema. Hacer que un sistema realice más funciones de las actuales.
b)    Incrementar el nivel de desempeño. Hacer que un sistema sea más confiable. Más fácil de operar y mantener, capaz de adaptarse a niveles estándares más altos.
c)    Disminuir costos, hacer que un sistema sea más eficiente.
INVESTIGACION DEL MEDIO AMBIENTE
Se trata de entender y describir el medio ambiente en donde se encuentra la organización, “entre otras cosas, se realiza un peinado del medio ambiente en búsqueda de nuevas ideas, métodos, materiales y tecnologías que puedan ser utilizadas en la satisfacción de necesidades”. De este último se desprende  que el criterio para decidir si algo que existe en el medio ambiente es útil para la organización está en función de las necesidades de esta última.
2.    SELECCIÓN DE OBJETIVOS.
Se establece tanto lo que esperamos del sistema como los criterios bajo los cuales mediremos su comportamiento y comparemos la efectividad de diferentes sistemas.
Primero se establece que es lo que esperamos obtener del sistema, así como insumos y productos y las necesidades que este pretenda satisfacer.
Ya que un sistema técnico se encuentra dentro de un supra-sistema que tiene propósitos, aquel debe ser evaluado en función de este. No es suficiente que el sistema ayude a satisfacer ciertas necesidades. Se debe escoger un sistema de valores relacionados con los propósitos de la organización, mediante el cual se pueda seleccionar un sistema entre varios y optimizarlo. Los valores más comunes son: utilidad (dinero), mercado, costo, calidad, desempeño, compatibilidad, flexibilidad o adaptabilidad, simplicidad, seguridad y tiempo.
Los objetivos deben ser operados hasta que sea claro como distintos resultados pueden ser ocasionados a ellos para seleccionar y optimizar un sistema técnico.
Cuando un sistema tiene varios objetivos que deben satisfacerse simultáneamente, es necesario definir la importancia relativa de cada uno de ellos. Si cada objetivo debe cumplirse bajo una serie de valores a estos también se debe asignarse un peso relativo que nos permita cambiarlos en el objetivo englobador.
3.    SINTESIS DEL SISTEMA.
Lo primero que se debe hacer es buscar todas las alternativas conocidas a través de las fuentes de información de nuestro alcance. Si el problema ha sido definido ampliamente, el número de alternativas va hacer bastante grande. De aquí se debe obtener ideas para desarrollar distintos sistemas que pueden ayudarnos a satisfacer nuestras necesidades. Una vez hecho esto, se procede a diseñar(ingeniar)distintos sistemas.
            En esta parte no se pretende que el diseño sea muy detallado. Sin embargo, debe de estar lo suficientemente detallado de tal forma que los distintos sistemas puedan ser evaluados.
3.1 DISEÑO FUNCIONAL
El primer paso es listar los insumos y productos del sistema. Una vez hecho esto, se listan las funciones que se tiene que realizar para que dados ciertos insumos se obtengan ciertos productos. Estas funciones se realizan o sintetizan mostrando en un modelo esquemático de las actividades y como estas se relacionan. Todo lo que desea en este punto es ingeniar un sistema que trabaje, la optimización del mismo no importa tanto en este punto.
4.    ANÁLISIS DE SISTEMA
La función de análisis es deducir  todas las consecuencias relevantes de los distintos sistemas para seleccionar el mejor. La información que se obtiene en esta etapa se retroalimenta a las funciones de selección de objetivos y síntesis de sistema. Los sistemas se analizaran en función de los objetivos que se tengan.
4.1 COMPARACIÓN DE SISTEMAS
Una vez que todos los sistemas han sido analizados y sintetizados, el paso siguiente es obtener las discrepancias y similitudes que existen entre cada uno de ellos. Existen dos tipos de comparación:
a)    Comparar el comportamiento de dos sistemas con respecto a un mismo objetivo.
b)    Comparar dos objetivos de un mismo sistema.
Antes que se lleve a cabo la comparación entre distintos sistemas, estos deben ser optimizados, deben estar diseñados de tal forma que se operen lo más eficientemente  posible. No se pueden comparar dos sistemas si aún no han sido optimizados.
5. SELECCIÓN DEL SISTEMA
 Cuando el comportamiento de un sistema de puede predecir con certidumbre y solamente tenemos un solo valor dentro de nuestra función objetivo, el procedimiento de selección del sistema es bastante simple. Todo lo que se tiene que hacer es seleccionar el criterio de selección. Cuando el comportamiento del sistema no se puede predecir con certidumbre y se tienen distintos valores en función de los cuales se va a evaluar el sistema, no existe un procedimiento general mediante el cual se puede hacer la selección del sistema
6. DESARROLLO DEL SISTEMA
El desarrollo del sistema es un sistema sigue básicamente el ciclo que se muestra en la siguiente figura:
En base al diseño que se había hecho el sistema durante la fase de síntesis del sistema, se hace un diseño detallado del mismo, para esto, se puede utilizar la técnica del síntesis funcional, mencionado anteriormente. Una vez que el sistema está en papel, hay que darle vida, desarrollarlo. El número de personas que toman parte en esta operación depende de la magnitud del sistema. Por ejemplo, el production control sistem (PSC) desarrollado por la borroughs tiene invertido alrededor de 50 años-hombres.
Lógicamente, no se puede poner en operación un sistema una vez que haya sido construido. Se tienen que hacer pruebas para deslumbrar problemas no previstos en su funcionamiento. En caso que no funcione como debiese, se debe investigar las razones y tomar acciones correctivas. Estas caen dentro de dos categorías:
a)    Falla de diseño.
b)    Fallas de la construcción.
En el primer caso, debe reportarse que fallas tienen el diseño del sistema para proceder a hacer los cambios. En el segundo caso, debe reportarse que es lo que se construyó mal para proceder a corregirlo.
Una vez que el sistema funcione como se pretendía, y antes que se ponga en operación, deben de desarrollarse documentos de que contengan información sobre su operación, instalación y mantenimientos, entre otros.
7.  INGENIERIA
En esta etapa no consiste en un conjunto de pasos más o menos secuenciales como en otras partes del proceso. Consiste en varios trabajos los cuales pueden ser calificados de la siguiente forma:
a)    Vigilar la operación del nuevo sistema para mejoras en diseños futuros.
b)    Corregir fallas en el diseño,
c)    Adaptar el sistema a cambios del medio ambiente.
d)    Asistencia al cliente.
Esta etapa dura mientas el sistema está en operación.