Este blog está destinado a exponer diversas ideas sobre el enfoque sistémico y su relación con la ingeniería de sistemas.

El enfoque sistémico consiste en la aplicación del pensamiento sistémico en diversas área de conocimiento.

Presentaremos el Pensamiento Sistémico, sus principios y filosofía. Se revisarán las diferencias entre sistemas suaves y sistemas duros.

Para los que estén interesados en aplicaciones que utilizan el enfoque sistémico, pueden consultar dos informes sustentados en la Universidad:

  1. El Diagnóstico del Sistema Organizacional de un Instituto de Educación a Distancia
  2. Análisis de Requerimientos de un Sistema de Inteligencia Comercial para una empresa de publicidad exterior.

Se tratan los siguientes temas (haz click en el tema que quieras ver):

En el marco teórico (haz click aquí) de uno de nuestros informes podrás encontrar información sobre los siguientes temas:

  • El pensamiento sistémico y su aplicación.
  • La Metodología de los Sistemas Suaves de Checkland (el modelo convencional y el análisis de los dos flujos)
  • El Método Suave Riguroso de Hitchins
  • La Relación de las Metodologías Suaves con la Ingeniería de Sistemas
  • El Sistema Organizacional

En próximos posts estaremos ampliando estos temas y agregando nuevos.

En tus trabajos académicos puedes citarnos así:
Blog Sistemigramas, Enfoque Sistémico en Ingeniería. http://sistemigramas.wordpress.com/ (revisado el dd/mm/aa)

Gracias por compartir este blog

Share

¿Se dice Sistemas Blandos o Sistemas Suaves?. Al respecto, nosotros utilizamos el término “Sistemas Suaves”, tomado así de la primera traducción al español de “Systems Thinking Systems Practice” de Peter Checkland y de “Soft Systems Methodology in Action” de Peter Checkland y Jim Scholes, publicados por Editorial Limusa S.A., México DF, 1994. Cabe señalar, que por lo menos la primera traducción contiene errores de fondo, que suponemos en ediciones posteriores hayan sido subsanados.

También hay otros textos, que traducen “Soft Systems” como “Sistemas Blandos”, lo cual nos parece equivalente a “Sistemas Suaves”.

Consultamos el traductor Google, con relación a la traducción al español del término “soft” como “suave” o “blando”, y brinda 10 posibles traducciones, entre las cuales se encuentra “suave” en el tercer lugar y “blando” en el séptimo lugar.

En el diccionario de la Real Academia de la Lengua Española, el término “suave” tiene seis acepciones una de las cuales se refiere al término blando; y el término “blando” tiene diez acepciones una de las cuales hace referencia a suave.

Según el diccionario de sinónimos y antónimos del diario El País (España) ambos términos “suave” y “blando” son sinónimos.

Por los motivos expuestos el término “Sistemas Blandos” nos parece equivalente a “Sistemas Suaves”. La preferencia por este último, nos viene de la traducción de los libros indicada líneas arriba. Sin embargo, el tema sigue abierto, y agradeceremos cualquier comentario que permita aclarar el tema.

Para ver Artículos relacionados Haz click en —>

Gracias por compartir este artículo

Share

Cuando iniciamos este blog, lo hicimos con responsabilidad y solamente con el ánimo de compartir nuestras experiencias y conocimientos. Últimamente hemos recibido algunas consultas y también algunas críticas como: “Deja ya de confundir a los profesionales y estudiantes …. No se dice cuadro pictórico sino pintura rica …. No se dice “situación problema” sino “situación problemática” ….. ten cuidado en los términos que usas para no mal interpreten otras personas ….. Estuve en un evento y el expositor (Nota de Sistemigramas: persona muy respetable por cierto) dijo que el verdadero nombre es Metodología Sistémica Blanda ….. Te aclaro que no existen sistemas suaves y sistemas duros …. Pregunta bien a una persona que conozca sistémica …. “. ¡Epa!. Pero, agradecemos los comentarios, porque permiten aclarar dudas, crear un sano debate de ideas y revisar lo que hemos escrito porque tal vez no hemos sido muy claros explicando algunos conceptos; y, si fuera el caso, reconocer nuestros errores. Felizmente no vivimos en una dictadura, y el mayor beneficio que nos brinda Internet es la posibilidad de poder expresarnos libremente, aunque en algunas partes del mundo actual y en pleno siglo XXI algunos gobiernos quisieran que no existan medios que permitan la libre expresión de las personas. Sin embargo, como la libertad debe ir unida a la responsabilidad (lo que obliga sustentar las afirmaciones con fuentes bibliográficas), en este post hacemos las aclaraciones respectivas.

Algunos afirman que el término correcto para la Metodología de Checkland sería Metodología Sistémica Blanda. Al respecto preferimos utilizar el término Metodología de Sistemas Suaves, término que está ampliamente difundido en español, como puede apreciarse en las traducciones de los libros de Checkland y por consiguiente en la cantidad de resultados de búsqueda en Google utilizando como criterio de búsqueda “metodología de sistemas suaves” (40,200 resultados) superando a la búsqueda del término “metodología sistémica blanda” (8 resultados), según consultas realizadas el 02/Diciembre/2009. En ambos casos se han colocado comillas a los términos usados para la búsqueda.

Asimismo, debe tenerse en cuenta que Checkland llama a su metodología, “Soft Systems Methodology” (SSM) y no tenemos referencias bibliográficas que la haya denominado “Soft Systemic Methodology”. Tampoco este segundo término aparece en los textos de Brian Wilson, Michael C. Jackson, Frank Gregory, Jeremy Rose, entre otros autores que han escrito sobre el tema. Es necesario precisar que la Metodología de Sistemas Suaves es sistémica, porque se hace un estudio considerando la totalidad de un sistema o el sistema contenedor ubicado en un nivel mayor en la jerarquía de sistemas. El término sistemático es utilizado en el sentido de “racional, metódico, realizado de acuerdo a un plan”, mientras que sistémico es “perteneciente al todo, al sistema contenedor”.

Entonces, para el paradigma de la Investigación de Operaciones, del Análisis de Sistemas y de la Ingeniería de Sistemas “duros”, su ontología es “la realidad es sistémica” (en el sentido que existen sistemas definidos en el mundo real) y su epistemología es “la metodología puede ser sistemática” (reduccionista, repetitiva, racional). En contraste para la Metodología de Sistemas Suaves su ontología es “la realidad es problemática” y su epistemología es “la metodología puede ser sistémica”. El término “puede ser” es utilizado porque la condición de “sistémica” y “sistemática” no es absoluta. Por ejemplo, un ingeniero de sistemas “duros” o un analista de sistemas o un gerente puede usar una epistemología sistémica (por ejemplo el Modelo de Sistema Viable, el Método Suave Riguroso, la Dinámica de Sistemas, etc.) que considere los sistemas contenedores, sistemas, sub-sistemas, etc. en una jerarquía y en un esfuerzo de síntesis para no perder de vista el objetivo del sistema de nivel superior, mientras se diseña o desarrolla (en forma sistemática) los sistemas o componentes de nivel inferior. De igual manera, la Metodología de Sistemas Suaves puede ser sistemática (racional, repetitiva) cuando se pasa a la elaboración de modelos conceptuales (cuarto estadio, en la metodología de siete estadios. De acuerdo al Diccionario Vox, un estadio es un momento, periodo o estado que forma parte de una serie o de un proceso), porque se basa en reglas definidas y en el uso del modelo formal de sistemas según lo afirma (Wilson 2001). Por eso, consideramos no usar el término “sistémico” para la Metodología de Checkland, porque ésta puede ser sistémica y también sistemática. Sobre este tema pueden revisar lo señalado por (Rychetnik 1984)

Respecto al uso del término “situación problema” o “situación problemática”, Checkland la denomina “problem situation” (es decir situación problema), en el sentido que es problemática. Transcribimos textualmente uno de los últimos textos de (Checkland 2000): “We had moved away from working with the idea of an ‘obvious’ problem which required solution, to that of working with the idea of a situation which some people, for various reasons, may regard as problematical. We had developed the idea of building models of concepts of purposeful activity which seemed relevant to making progress in tackling the problem situation. Más adelante en el mismo texto, Checkland señala: “By the time the first book about SSM was written (Systems Thinking Systems Practice, 1981) the engineering-like sequence of the 1972 paper was being presented as a cluster of seven activities in a circular learning process: the ‘seven-stage model’. In this model the first two stages entail entering the problem situation, finding out about it and expressing its nature. .. “. Nosotros nos adherimos al término situación problema, conservando el sentido fijado por Checkland.

En relación a los sistemas suaves, ¿en realidad éstos no existen?. Para salir de dudas reproducimos un texto de (Checkland 1980) “… lo segundo implica el desarrollo práctico del pensamiento de sistemas mediante la aplicación de este enfoque en la solución de problemas en el mundo real; esto último involucra el trabajo desarrollando en lo que se denomina sistemas ‘duros’ (‘hard systems) – aquellos que tienen una manifestación ‘concreta’ en la realidad). También compete a esta segunda distinción ……………. los trabajos desarrollados en lo que se denomina sistemas ’suaves’ (’soft’ systems), sistemas que son conceptuales en vez de concretos”. Está claro que los sistemas suaves existen como modelos conceptuales (debajo de la raya heurística en el modelo de siete estadios de la SSM), no en el mundo real o físico.

Sin embargo, es mas adecuado hablar de problemas y situaciones “duros” y suaves”, como lo hace (Hitchins 1992) quien indica en el glosario de términos: Hard. Clearly defined or definable and with evident purpose. (Duro. Claramente definido o definible y con un propósito evidente)”; “Soft. Complex, poorly defined, and without clear singular purpose. (Suave. Complejo, pobremente definido y sin un claro y único propósito)”. Cabe señalar que Hitchins es el creador del Método Suave Riguroso, que también es sistémico.

Referencias:

(Checkland 1980)
Checkland, Peter. “The System Movement and the ‘failure’ of Management Science”. Cybernetics and Systems: An International Journal, 11: 317-324. 1980.

(Checkland 2000)
Checkland, Peter. “Soft Systems Methodology: A thirty years retrospective”. Systems Research and Behavorial Science 17. S11-S58. 2000.

(Hitchins 1992)
Hitchins, Derek. Putting Systems to Work. John Wiley and Sons. 1992.

Para ver Artículos relacionados Haz click en —>

Gracias por compartir este artículo

Share

Los cuadros pictóricos fueron desarrollados particularmente como parte de la Metodología de los Sistemas Sistemas Suaves por (Checkland 1981) y (Checkland y Scholes 1990) para recopilar información sobre una situación problema y como un medio para comunicarse fácilmente con los interesados utilizando símbolos en lugar de palabras. Las figuras son un mejor medio que el texto lineal para expresar relaciones. Las imágenes pueden ayudar a considerar una situación como un todo, con un enfoque holístico, en lugar de ver la situación desde un punto de vista reduccionista.

Cuadro Pictórico IDG

Los cuadros pictóricos se dibujan al inicio de la aplicación de la Metodología de Sistemas Suaves (en la segunda etapa de la metodología, si se está utilizando el modelo clásico de siete etapas) para expresar la situación problema.

Son dibujos que permiten representar las diversas características, incluyendo emociones y comportamientos, de una situación problema, como se perciben, para ser expuestos gráficamente a la vista de todos los interesados (stakeholders).

Una crítica que se le ha hecho al uso de los cuadros pictóricos, viene por parte de algunos autores que manifiestan que podrían no ser tomados en serio al mostrarlos a los directivos de una empresa.

Para superar lo señalado, en el artículo que adjuntamos al presente post, mostramos un ejemplo del uso de los cuadros pictóricos, que recoge el uso del modelo de Interacción y Transformación, que sugiere el uso de sustantivos para designar a las entidades y el uso de verbos para identificar la relación entre las entidades. Además, en el cuadro pictórico se destacan los síntomas o situaciones anómalas detectados.

Se puede ver mayores detalles en el siguiente documento.

Para ver Artículos relacionados Haz click en —>

Gracias por compartir este blog

Share

El Director General de un Instituto de Educación a Distancia tenía algunas inquietudes sobre el futuro del Instituto, sobre continuar con la actual modalidad con lecciones impresas en la que el Instituto tiene éxito o innovar aprovechando las ventajas que pueden dar las Tecnologías de Información. Me preguntó como le podía ayudar la Ingeniería de Sistemas. A simple vista se pensaría que era suficiente con aplicar una solución orientada a utilizar un (VLE) Virtual Learning Enviroment o Plataforma de Aprendizaje como Moodle, Dokeos, Claroline, Atutor u otro y definir una Arquitectura Tecnológica que apoye las actividades del Instituto en la nueva línea de cursos en e-learning.

Pero no se puede ofrecer una solución si previamente no se ha definido el problema. El presente caso involucra personas y tecnología, además hay objetivos que no son fáciles de definir, es decir, es una situación no estructurada, que en la metodología de sistemas suaves se denomina situación – problema; en ésta se debe buscar la respuesta a la pregunta ¿Qué hacer? antes que al ¿Cómo hacer?

Situación Problema

Así comenzó la realización de un diagnóstico aplicando el pensamiento de sistemas suaves. Es un principio de sistemas que para definir un sistema que sirve a otro, primero tenemos que definir y modelar el sistema a servir. Generalmente el sistema a servir es de nivel mayor o incluye al de nivel menor. Por lo que se puede inferir, que para conocer los requerimientos del sistema menor debemos primero conocer los requerimientos del sistema mayor a servir, que en este caso es el sistema organizacional.

En primer lugar: definir el problema. Después, dar la soluciónNota: En la figura SSM es Soft Systems Methodology (Metodología de Sistemas Suaves de Checkland) y RSM es Rigorous Soft Method (Método Suave Riguroso de Hitchins).


Haz click aquí para ver el informe completo

stspHay en la red una gran cantidad de artículos sobre los sistemas suaves (en español), parte de los cuales denota una mala aplicación o una falta de comprensión y dominio de la Metodología de Sistemas Suaves (Soft Systems Methodology o SSM).

Consideramos que en algunos casos la metodología está mal enseñada. Incluso circula por ahí, una pésima traducción al español, del libro mas importante de Checkland “Systems Thinking, Systems Practice” (“Pensamiento de Sistemas, Práctica de Sistemas”). Otro libro de Checkland titulado “Soft Systems Methodology in Action” es traducido por la misma editorial como “La Metodología de los Sistemas Suaves de Acción”. Si el título del libro está mal traducido, que se puede esperar del contenido.

Buscando por la red, nos llamó la atención un ejemplo sobre aplicación de la metodología al caso del suicidio, que incluye fotografías bastante chocantes. Mucho palabreo pero ningún modelo conceptual. No creemos que esta sea la mejor aplicación para un futuro ingeniero de sistemas, pues el autor se identifica como tal y encima con un doctor en sistemas como profesor. Por casos como éste, muchos dicen que la metodología no sirve.

La SSM puede ser aplicada por sociólogos, sicólogos, antropólogos y otros profesionales en su dominio de conocimiento. Pero a los ingenieros se nos pide resultados concretos, y para eso la SSM es muy rigurosa. Apliquemos la SSM a la ingeniería, dejemos a los profesionales de otras áreas que hagan sus propias aplicaciones.

La metodología, para los ingenieros de sistemas y también para los ingenieros informáticos, puede aplicarse a la gestión de empresas, la reingeniería y el mejoramiento de procesos, el análisis de requerimientos de un sistema y de un sistema de información como caso particular, etc.

En la metodología de los sistemas suaves, los sistemas son considerados como construcciones mentales, antes que entidades con una existencia objetiva en el mundo real. Por lo tanto, es importante señalar que la correcta aplicación de esta metodología se basa sobre todo en la elaboración de Definiciones Raíces y en la construcción de Modelos Conceptuales, que siguen reglas definidas y no pueden aplicarse en forma aleatoria.

Soft Systems Methodology - WilsonBrian Wilson (*) señala: “Un ingeniero cuando diseña un artefacto físico utiliza las reglas de diseño que son obtenidas de la teoría resultante de la observación de las regularidades del mundo real (la ciencia) y de la heurística que proviene de la práctica (la experiencia). En una disciplina intelectual ocurre algo similar. Por ejemplo no se puede decir que se está aplicando el cálculo diferencial si no se sigue las reglas para formular ecuaciones diferenciales. Igualmente, no se puede decir que se está aplicando la Metodología de los Sistemas Suaves si no se siguen sus reglas básicas – sus bloques básicos de construcción – que son la Definición Raíz y el Modelo Conceptual”.

Recomendamos a los profesores y estudiantes de ingeniería de sistemas de habla hispana, recurrir directamente a los originales en inglés de los libros mencionados, porque ¿cómo se puede aspirar a ser ingeniero de sistemas, si ni siquiera se ha leído a Peter Checkland?

Existe mucha deformación y mala aplicación de la metodología de sistemas suaves, por tal motivo en los próximos posts les estaremos presentando selecciones de diversos trabajos relacionados con la aplicación de la metodología, basados en textos originales que disponemos y comentaremos para ustedes.

(*) Wilson, Brian. Soft Systems Methodology. John Wiley & Sons Ltd., 2001.

Para ver Artículos relacionados Haz click en —>

Gracias por compartir este artículo

Share

Edgar_Morin_big

Guillermo Giacosa en Perú21, escribe en su columna un artículo sobre el filósofo francés Edgar Morin, quien hace poco estuvo en Lima y dictó una conferencia en la Biblioteca Nacional.

Morin es un filósofo que ha desarrollado la epistemología de la complejidad que se basa en el pensamiento de las tres teorías: (la cibernética, la teoría de sistemas y la teoría de la información).

Click aquí para Ir a la página principal

El Análisis Organizacional es un intento para resolver problemas relacionados con situaciones que se presentan en una organización.

La experiencia acumulada en la aplicación de la Metodología de Sistemas Suaves (SSM) condujo a Checkland a desarrollar la versión de los Dos Flujos de la Metodología, mostrando la realización: El Flujo de Análisis Cultural y el Flujo de Análisis basado en la Lógica, que se aprecia en la siguiente figura.

SSM Dos flujos

Puede haber situaciones relacionadas con los aspectos sociales, interpersonales y culturales presentes en la vida de una organización que no pueden pasarse por alto si el análisis organizacional va tomar en cuenta a las personas involucradas. Éste es el énfasis del flujo cultural de la Metodología de Sistemas Suaves.

Sin embargo hay muchas situaciones que requieren una descripción (para la organización) en términos de los procesos de negocios y como éstos son o cómo deberían llevarse a cabo, y en este post y los próximos desarrollaremos temas relacionados con el flujo de la lógica en la Metodología de Sistemas Suaves. Esta aplicación de la SSM es importante por su vínculo con la Gestión de Procesos de Negocios o Business Process Management (BPM)

La esencia de este enfoque – relacionado con el flujo de la lógica – aplicado al análisis organizacional se ilustra en la siguiente figura:

Unidad Organizacional

La pregunta fundamental en Análisis Organizacional es: ¿Qué es la Unidad Organizacional, qué hace y qué debería estar haciendo?, debe entenderse en forma general ¿qué debería  estar haciendo?  (ahora y en el futuro), ¿hay un camino o una forma mejor para hacer lo que actualmente está haciendo?.

El uso del término Unidad Organizacional puede aplicarse a cualquier escala. Podría ser una corporación, una empresa mediana, una función, un departamento o aún un individuo. La Metodología de Sistemas Suaves es aplicable a cualquier escala.

Usando esta metodología no se busca describir la organización como parte del mundo real. Este intento llevaría a formular una descripción en términos de “Cómo” una Unidad Organizacional está operando. En la Metodología de Sistemas Suaves primero se debe definir el qué y después el cómo. En otras palabras, se busca en primer lugar definir el problema y luego, definir la solución.

Al aplicar la SSM en el Análisis Organizacional se crea un modelo, una posibilidad para responder a la pregunta: ¿qué debería estar haciendo la Unidad Organizacional para tener mejores resultados?. La Metodología permite construir modelos conceptuales (existentes en abstracto, no en el mundo real) para la Unidad Organizacional, porque la SSM es una disciplina intelectual que construye modelos conceptuales que – luego de un posterior debate, una comparación con el mundo real y de la determinación de su viabilidad – pueden ser implementados en la práctica.

Por lo tanto un modelo de la Unidad Organizacional, un modelo conceptual y estará en el lenguaje del “Qué” y no del “Cómo”. Si el modelamiento es adecuado, se tendrá una descripción (un modelo, no existente en el mundo real) en relación a qué debería estar haciendo la Unidad Organizacional y servirá para realizar el análisis organizacional que lleve a un mejoramiento de la situación actual.

(Wil van der Aalst 2003), un experto en gestión de procesos de negocios, señala que un proceso se diseña (o rediseña) en dos pasos: primero, en abstracto – sin considerar todavía la organización y el Sistema de Información que se va a utilizar -; y solo después de ese diseño en abstracto se pasa a considerar el Sistema de Información y la Organización, ambos en paralelo. Se define qué tareas serán realizadas por las personas y cuáles con el apoyo de las TI.

Si la Unidad Organizacional es algo específico, como un proceso químico o una planta de generación de energía, la pregunta ¿Qué debería estar haciendo la Unidad Organizacional? puede ser respondida en base a una de las ramas de las matemáticas – cálculo diferencial, simulación, estadística, etc – La pregunta estará bien respondida cuando el modelo construido represente la conducta de la Unidad Organizacional en el dominio de interés. Esto es un ejemplo de Sistemas Duros o bien definidos.

Si la Unidad Organizacional corresponde al dominio de los Sistemas Suaves (poco estructurados o menos definidos, y donde intervienen personas como un componente muy importante), para responder a la pregunta fundamental del análisis organizacional no se puede usar herramientas con base matemática.

Una Unidad Organizacional que contiene personas representa una situación más compleja que una que no las contiene. Ésta es la diferencia entre duro (“hard”) y suave (“soft”). El ejemplo del proceso químico representa una unidad organizacional bien definida, que puede ser considerada como dura (“hard”).

El centro de interés en la metodología de los sistemas suaves son aquellas situaciones (o Unidades Organizacionales) suaves (“soft”), no estructuradas o que no están claramente definidas.

J. Villacriz Révolo

Referencias
Soft Systems Methodology in Action (Checkland and Scholes 1990)
Soft Systems Methodology (Wilson 2001)
Workflow Management (Wil van der Aalst 2003)
sistemigramas.wordpress.com

Para ver Artículos relacionados Haz click en —>

Gracias por compartir este artículo

Share

¿Son el enfoque sistémico y el pensamiento sistémico, lo mismo? Desde nuestra experiencia podemos responder afirmativamente a esa pregunta. El Pensamiento Sistémico es una disciplina para ver totalidades. Es un marco para ver interrelaciones en vez de cosas, para ver patrones de cambio en vez de “instantáneas estáticas”. Pensar asistémicamente es concentrarse en las “instantáneas” de un problema y en las partes aisladas del sistema [Senge 1990].

Sin embargo mientras que el pensamiento sistémico lo asociamos con la teoría, los principios y la filosofía de sistemas; el enfoque de sistemas lo asociamos con la realización y aplicación práctica del pensamiento sistémico a situaciones concretas.

Click para Ir a la página principal

Es un principio de sistemas que para definir y modelar un sistema que sirve a otro, primero tenemos que definir y modelar el sistema a servir. Generalmente el sistema a servir es de nivel mayor o incluye al de nivel menor. Por lo que se puede inferir, que para conocer los requerimientos del sistema menor debemos primero conocer los requerimientos del sistema mayor a servir. Es decir, que para definir los requerimientos de software, en el campo de las tecnologías de información, primero debemos definir los requerimientos de los niveles mayores en el siguiente orden: nivel organización, proceso de negocio (sistema de trabajo) y sistema de información; para evitar convertir un problema real en un problema virtual.

En este trabajo se aplicará la Metodología Suave Rigurosa empleada a nivel organizacional, dando como resultado el catálogo de problemas , expresados en forma más optimista como Requerimientos de la Organización del área de Marketing y Ventas de la empresa.

A continuación se hará el Análisis de Requerimientos del Sistema de Trabajo, que en este caso es el Sistema de Inteligencia Comercial (SIC), elegido como el proceso de negocio de interés, después de la evaluación respectiva en el capítulo de Diagnóstico. Los requerimientos en este nivel están constituidos por los procesos y/o actividades del sistema (SIC).

Bajando en la jerarquía de sistemas, se hará el Análisis de Requerimientos del Sistema de “Información” del SIC, abreviado SIIC. Los requerimientos para esta capa están constituidos por las categorías de información que necesita para su realización cada proceso/actividad del nivel anterior.

Finalmente, en el nivel siguiente nivel de la jerarquía de sistemas, se hará el Análisis de Requerimientos de Software del Sistema del SIIC, referidos a la parte (generalmente estructurada) del sistema de información que es factible de automatizar (sistemas de información basado en TI). Es decir, la automatización parcial o completa de los procesos y/o actividades que producen las categorías de información que son viables de mecanizar. Llamados también requisitos funcionales. Este nivel será desarrollado detalladamente y completado por el proveedor o consultor seleccionado para implementar el Sistema.

Página siguiente »