Análisis de Sistemas

¿Qué es análisis de sistemas?
El análisis de sistemas es la ciencia encargada del análisis de sistemas grandes y complejos, y la interacción entre los mismos.


"Se refiere al proceso de examinar la situación de una empresa con el propósito de mejorarla con métodos y procedimientos más adecuados." James A. Senn.

"Tiene como propósito transformar las entradas, las políticas de usuario y el esquema del proyecto en una especificación estructurada. Implica modelar el ambiente del usuario." Edward Yourdon.

"Pretende estudiar sistemáticamente la operación de ingreso de datos el flujo de los mismos y la salida de la información dentro del contexto de una empresa en particular." Kendall & Kendall



Principios de Análisis de Sistema de Información.

  • Debe presentarse y entenderse el dominio de la información de un problema. 
  • Defina las funciones que debe realizar el Software. 
  • Represente el comportamiento del software a consecuencias de acontecimientos externos. 
  • Divida en forma jerárquica los modelos que representan la información, funciones y comportamiento.
El análisis y la especificación de los requisitos pueden parecer dos tareas bastantes simples, pero requieren un flujo de comunicación y de interacción con el cliente de forma efectiva que permita evitar las malas interpretaciones y la falta de información.

El análisis de requisitos del software puede dividirse en 5 áreas fundamentales:
1. Reconocimiento del Problema. El analista debe hacer contacto con el equipo técnico y de gestión de los usuarios con el objetivo de reconocer los elementos básicos del problema y el entorno del sistema tal y como los percibe el usuario/cliente.
2. Evaluación y Síntesis. El analista evalúa el flujo y la estructura de la información, define y elabora las funciones todas las funciones que debe realizar el software y debe llegar a un entendimiento del comportamiento del sistema ante los sucesos que lo estimulan. Tras la evaluación el analista sintetiza una o más soluciones que deben responder a “QUE SE HARA” no al “COMO SE HARA”.
3. Modelización. Para un mejor entendimiento de la solución, el analista crea modelos del sistema para visualizar de mejor manera el flujo de datos y de control, el procesamiento funcional, el comportamiento operacional y el contenido de la información.
4. Especificación. El analista proporciona una representación (escrita y grafica) del software que demuestra que se ha llegado a un entendimiento de cómo debe implementarse con éxito el sistema.
5. Revisión. La documentación del análisis sirve como base para una revisión por parte del cliente y el desarrollador, casi siempre en esta etapa se producen cambios a la función, a la representación de los datos y a los requerimientos. Es importante que el cliente apruebe al ciento por ciento la especificación para continuar con el desarrollo.

La técnica de mas usada para la obtención de requisitos es la entrevista preliminar. Esta entrevista es fundamental ya que da la pauta para el inicio del trabajo, por lo que es importante que comience por un reconocimiento general de lo objetivos que se pretenden y los beneficios que se esperan.

En segundo termino, habrá que buscar un entendimiento del problema que se esta presentando, así como, la opinión del cliente sobre un posible primera solución, así como las restricciones dentro de las cuales se desarrollara esa solución.

En tercer termino, se buscaran los enlaces necesarios para obtener mas información, en caso de ser necesario, sobre todo para soluciones que afectan a mas de un área de la empresa o a mas de un usuario.

Una metodología que nos otorga un enfoque bastante cercano al cliente es el Despliegue de la función de calidad.

Esta técnica, que es parte de la gestión de calidad, se concentra en maximizar la satisfacción del cliente. Esta técnica define tres tipos de requisitos:
Normales: descritos por el cliente y que son fundamentales para la satisfacción del cliente
Esperados: El cliente no los especifica pero los da por sentado, o no los declara de forma explicita, pero resultan generalmente fundamentales.
Innovadores: Estas van mas allá de lo que el cliente espera y son de gran satisfacción para el cliente.
Información basada en textos del libro de ingeniería de software de Roger S. Pressman

El Analista de Sistemas.
Audita de forma sistemática el funcionamiento de la empresa al examinar las funciones de captura y procesamiento de datos, así como la función de emisión de resultados, la cual le permitirá mejorar los procesos de la organización.
Cualidades.
  • Habilidad para comprender conceptos abstractos, reorganizarlos en divisiones lógicas y sintetizar "soluciones" basadas en cada división.
  • Habilidad para entresacar hechos importantes de fuentes conflictivas o confusas.
  • Habilidad para comprender el entorno (medio ambiente) del usuario.
  • Habilidad para aplicar elementos del sistema (hardware y/o software) al entorno de usuario.
  • Habilidad para comunicarse bien de forma verbal y escrita.
  • Habilidad para evitar que "Los árboles no le dejen ver el bosque".               Roger S. Pressman.

Facilidad en el manejo de personas, para poder entrevistar a los usuarios y mediar en desacuerdos y disputas que se ven en el desarrollo de un proyecto. Se necesita tener conocimientos de aplicación para entender y apreciar los asuntos del usuario. Habilidad en computación para entender los usos potenciales de hardware y el software en los asuntos del usuario. Mente lógica y organizada. Ver el sistema desde diferentes perspectivas, poder dividirlo en subsistemas y debe ser capaz de pensar en el sistema en términos abstractos, además de físicos.
Nadie dijo que iba ser un trabajo fácil!
Edward Yourdon.

Determinación de los Requerimientos.
El objetivo del análisis de sistemas es comprender situaciones, no resolver problemas. Por tanto, los buenos analistas hacen hincapié en la investigación y el cuestionamiento para conocer cómo opera el sistema e identificar los requerimientos de los usuarios para modificarlo o proponer uno nuevo. Sólo después de comprender totalmente el sistema, los analistas están en posición de analizarlo y generar recomendaciones adecuadas.
La determinación de requerimientos es el estudio de un sistema para conocer cómo trabaja y donde es preciso efectuar mejoras.
Un requerimiento es una característica que debe incluirse en un sistema. Esto puede ser una forma para capturar o procesar datos, producir información o controlar una actividad de la empresa.
Dado que los analistas no trabajan como gerentes o empleados de los departamentos de usuarios, no tienen los conocimientos, hechos y detalles sobre el sistema que tiene que analizar. Por consiguiente, el primer paso es comprender la situación.

Actividades para la determinación de los requerimientos.
Se identifican tres grandes actividades:
  • Anticipación de Requerimientos: Los conocimientos de los analistas en un área particular y el contacto con sistemas similares al que se encuentra bajo investigación, tienen influencia sobre el estudio que estos realizan. Su experiencia les permite anticipar ciertos problemas o características para un nuevo sistema, por tanto, es probable que la investigación sea ágil debido a la rápida comprensión de los analistas. Tener las bases necesarias para saber que preguntar o que aspecto investigar puede ser de beneficio sustancial para el desarrollo del sistema.
  • Investigación de los Requerimientos: Estudio y documentación del sistema actual. Esta actividad depende de las técnicas para encontrar hechos (entrevistas, cuestionarios, observaciones) y las herramientas para documentarlos (Diagramas de flujos, análisis de decisiones, etc.).
  • Especificación de los Requerimientos: Los resultados obtenidos de la actividad anterior se analizan para determinar las características del nuevo sistema. Esta actividad comprende tres partes:
Análisis de datos basados en hechos reales
Se examinan los datos recopilados durante el estudio, incluidos en la documentación, para determinar el grado de desempeño del sistema y si cumple con las demandas de la organización.
Identificación de los requerimientos esenciales
Características que deben incluirse en el nuevo sistema y que van desde detalles de operación hasta criterios de desempeño.
Selección de estrategias para satisfacer los requerimientos
Métodos que serán utilizados para alcanzar los requerimientos establecidos y seleccionados.
La correcta determinación de requerimientos implica una gran responsabilidad para los analistas, pues el trabajo realizado se verá reflejado más adelante en las características del nuevo sistema. En lo adelante se explica cómo comenzar el estudio y sugiere que preguntas deben formular los analistas poco familiarizados con la organización.

 Requerimientos Básicos.
Comprensión del Proceso.
Siempre se debe comenzar por lo básico. Los analistas hacen preguntas que proporcionan detalles fundamentales relacionados al sistema que sirven para describirlo. Las siguientes preguntas son de utilidad para adquirir la compresión necesaria:
¿Cuál es la finalidad de esta actividad dentro de la empresa?
¿Qué pasos se siguen para llevarla a cabo?
¿Dónde se realizan estos pasos?
¿Quién o quienes lo realizan?
¿Cuánto tiempo tardan en efectuarlos?
¿Con cuanta frecuencia se realizan?
¿Quiénes emplean la información resultante?

Identificación de datos empleados en el proceso y la información generada.
El siguiente paso es detectar que datos se usan para llevar a cabo cada actividad del proceso. Por ejemplo, para hacer una venta el vendedor necesita que el comprador de la cantidad y descripción de cada artículo deseado.
Por otro lado, muchas transacciones comerciales producen información útil en otro proceso del sistema o para otro sistema relacionado. Por ejemplo, para concluir la venta el vendedor creará una factura que contendrá entre otras cosas el nombre del cliente, cantidad, descripción y costo de los artículos vendidos.

Frecuencia y volumen del proceso.
Determinar la repetición de una actividad lleva al analista a considerar más preguntas que revelen la razón y efecto de la frecuencia sobre las demás actividades del proceso. Esta información resulta de vital importancia para descubrir que actividades necesitan urgentemente ser automatizadas.
El volumen de trabajo de una actividad también refleja si debe o no ser automatizada. Existen actividades que ocurren con una baja frecuencia pero su volumen es tal que puede llevar varios días en ser concluidas.

Identificación de Controles.
Toda actividad tiene controles que pueden determinar su inicio o su parada en cualquier punto de su desarrollo. El analista debe determinar:
¿Cuáles son los estándares para arrancar esta actividad?
¿Cuáles estándares aplican en cada paso de la actividad?
¿Cuántos errores se cometen?
¿Cómo se detectan los errores?
¿Cómo se corrigen los errores?

Requerimientos para toda la Organización.
En las empresas, los departamentos dependen unos de otros para realizar sus trabajos. Por lo tanto, los trabajos realizados por un departamento afectará el de los otros. Es necesario investigar como interactúa el sistema bajo investigación con los demás departamentos de la organización.


Entrevistas
Se emplea la entrevista para reunir información de primera fuente. Por lo general, los entrevistados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son entrevistados gerentes o empleados que serán destinatarios de la información que produzca el sistema. La entrevista es la técnica más empleada para recabar hechos y datos relevantes, pero no es ni debe ser la única utilizada, dado el tiempo que implica realizarla, más si se debe llegar a un gran número de usuarios.

El bueno recordar que los entrevistados y los analistas conversan durante una entrevista, es decir, no se hace un interrogatorio a los usuarios. De acuerdo como se lleve, la entrevista puede recolectar información cualitativa del sistema en estudio (opiniones, descripciones subjetivas de una actividad o problema) o puede recoger datos cuantitativos (frecuencia, cantidad, etc.).
Las entrevistas puede ser No Estructuradas y Estructuradas. Las primeras son ideales para obtener datos cualitativos y las segundas pueden componerse de preguntas cerradas (selección múltiple, si/no, cantidades). La habilidad del analista determina qué clase de entrevista usar dentro de la situación en que se encuentre.

Cuestionarios.
Permite a los analistas reunir información relacionada con varios aspectos de un sistema proveniente de un grupo grande de personas. El empleo de formatos estandarizados para la preguntas puede proporcionar datos más confiables que otras técnicas. Los cuestionarios son de amplia distribución y aseguran el anonimato de los encuestados que pueden ser más honestos dada esta condición.

Revisión de Registros
Los registros incluyen manuales de políticas, reglamentos o procedimientos estándares de operación. Quizás estas revisiones no indiquen como se desarrollan realmente las actividades, pero pueden servir de guía al analista de cómo se dan las relaciones formales en su afán de comprender el sistema.

Observación
Con la observación el analista obtiene información de cómo se realizan las actividades de una organización.
Se debe observar:
Como se manejan y se archivan los documentos.
Como se efectúan los procesos. Se siguen todos los pasos especificados en la entrevista o cuestionarios.

Bibliografía:
Senn, James A. Análisis y Diseño de Sistemas de Información.
McGraw Hill, 1992-Segunda Edición.

Lecturas Recomendadas:
Aprendiendo a Escuchar.
Pág. 140 del libro Análisis y Diseño de Sistemas de Información.

Técnicas y herramientas de Representación

Documentación de Procedimientos y Decisiones.
Formalizados o no, escritos o no, todas las organizaciones rigen sus actividades a través de procedimientos y siguiéndolos toman las decisiones. Para un analista, cuando conduce una investigación de sistemas, es de vital importancia documentar cada procedimiento y toma de decisión de tal forma que no existan ambigüedades ni malas interpretaciones.
Cuando se analizan procedimientos y toma de decisiones el primer paso es identificar condiciones y acciones, conceptos comunes para todas las actividades.

Condiciones y variables de decisión.
Toda actividad comienza bajo un estímulo dado bajo determinada condición. Cuando recabamos información sobre los procesos de un sistema nos encontraremos que de acuerdo a una condición se tomará una u otra decisión, por ejemplo, en el proceso de inscripción de un estudiante en la universidad existe la condición de que debe tener el pre matrícula formalizada y también está la condición de que no debe tener deudas pendientes.



La condiciones cambian por esto le llamamos variables de decisión, Puede ser que un estudiante tenga su pre matricula formalizada y pueda realizar su inscripción pero el siguiente no la realizó y no pueda inscribirse, la condición varió de una entidad a otra.



Acciones.

Cuando se conocen todas las condiciones, el siguiente paso del analista es determinar qué hacer cuando se presentan algunas de éstas. Las acciones son las opciones, que comprenden los pasos, actividades o procedimientos, que puede elegir una persona cuando se enfrenta ante un conjunto de condiciones.

En muchos procedimientos el analista debe considerar combinaciones de condiciones y acciones. Para documentarlas de manera efectiva se emplean los árboles de decisión, tablas de decisión y el lenguaje estructurado entre otras herramientas.



Árboles de Decisión.

Es un diagrama que representa en forma secuencial condiciones y acciones: muestra qué condiciones se evalúan en primer lugar, cuales en segundo y así sucesivamente. Este método permite mostrar la relación existente entre cada condición y grupo de acciones. Este diagrama parece las ramas de un árbol, de aquí su nombre.

Consideremos la toma de decisión en un centro de salud para pacientes asegurados que tiene la siguiente narrativa:

· Los pacientes con seguro médico básico deben pagar consultas

· Los pacientes con seguro social están exentos de pago
· Los pacientes sin ningún seguro deben pagar todos los servicios.

Los árboles de decisión no siempre son las mejores herramientas para el análisis de decisiones, cuando en un sistema complejo los pasos y combinaciones de condiciones tienen un tamaño considerable, el gran número de ramas pueden representar un problema para su interpretación más que una guía.

Tablas de Decisión.
Es una matriz de renglones y columnas que indican condiciones y acciones. Está integrada por cuatro secciones:

Condiciones 
  • Identificación de Condiciones
  • Identificación de Acciones 
Reglas de decisión
  • Entradas de condiciones
  • Entrada de Acciones
La identificación de condiciones presenta las que son relevantes para el proceso, las entradas de condiciones indican que valor se debe asociar a una condición. La identificación de acciones lista todos los pasos que se deben seguir cuando se presenta determinada condición y las entradas de acciones muestran las acciones específicas que deben emprenderse cuando una condición o conjunto de ellas son verdaderas.

Si existen n condiciones con valores binarios (verdadero – falso), entonces existirán 2n reglas de decisión distintas, así que si existen dos condiciones existirán cuatro reglas, si son 3 las reglas serán 8.
Siguiendo con la narrativa de pacientes asegurados podremos crear la siguiente tabla de decisión:


Condiciones
Reglas de Decisión
El paciente tiene seguro social
Si
Si
No
No
El paciente tiene seguro médico básico
Si
No
Si
No
Exento de Pago
X
X


Pagar Consulta


X

Pagar todos los servicios



X

Para ampliar sobre los árboles y tablas de decisión leer:

· Herramientas para Documentar Procedimientos y Decisiones, págs. 138-164. Del libro “Análisis y Diseño de Sistemas” de James Senn.

· Tablas de Decisión, págs. 244-246. Del libro “Análisis Estructurado Moderno” de Edward Yourdon.





Técnicas y herramientas de Representación (Modelos)

Modelo: Simulacro a bajo costo de un sistema que se desea estudiar.

Construimos Modelos para:

  • Enfocar características importantes encontradas durante la recolección de hechos y datos. Y a la vez, minimizar las menos importantes.
  • Discutir cambios y correcciones a los requerimientos del usuario, a un bajo costo y con riesgo mínimo.
  • Verificar que se entiende el ambiente del usuario, y que se ha documentado de tal manera que los diseñadores y programadores pueden construir el sistema.
Un modelo puede ser textual, narrativo o gráfico. Los últimos son de mayor aceptación.
Una herramienta de modelado eficiente posee las siguientes caracterizas.
  • Es gráfica, con detalles textuales que sirven de apoyo.
“Una imagen vale más que mil palabras”. Se utilizan gráficos para identificar los componentes de un sistema y su interfaz. Los demás detalles (orden, cantidad, etc.) se presentan en documentos de apoyo.
  • Procura la partición del sistema. Debe permitir que el sistema sea visto en segmento, en forma descendente.

Con frecuencia los sistemas son demasiado grandes y complejos para que sean comprendidos como un todo. Por tal razón, una herramienta de modelado debe permitir la segmentación del sistema en unidades lógicas que puedan ser estudiadas independientemente y puedan asociarse a las demás en los puntos de interface.


Un buen modelo debe proceder de manera descendente. Una porción de la vista global de alto nivel del modelo debe dar al lector una buena idea de los principales componentes de alto nivel y de los interfaces del sistema. Las siguientes porciones del modelo deberán proporcionar información respecto a los componentes detallados de bajo nivel.
  • Reducir la Redundancia.
Debemos evitar la aparición de un mismo elemento en las diferentes porciones del modelo. Si el elemento cambia o simplemente desaparece, entonces tendríamos que modificar una gran parte del modelo.
  • Debe ayudar al lector a predecir el comportamiento del sistema.

Diagrama de Flujo de Datos.
Es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por flujos y almacenes de datos.
El DFD es una de las herramientas más comúnmente usadas, sobre todo en sistemas donde los procesos son de mayor importancia y más complejos que los datos que maneja.

 Componentes de una DFD.
El proceso.
Tiene como sinónimos comunes Burbuja, Función y Transformación. El proceso muestra una parte del sistema que transforma una o más entradas en salidas. El proceso se representa gráficamente por un círculo, aunque algunos analistas prefieren usar un rectángulo con los bordes redondeados.

El proceso se nombra o se describe con una sola palabra, frase u oración sencilla. Regularmente el nombre del proceso describe lo que hace, un buen nombre generalmente incluye un verbo que denota la función a realizar.

El Flujo.
Describe el movimiento de bloques o paquetes de datos de una parte del sistema a otra. Se representa gráficamente por medio de una flecha que entra o sale de un proceso.

En la mayoría de los sistemas los flujos representan datos, es decir, bits, caracteres, mensajes y los diversos otros tipos de información que la computadora puede tratar. El nombre representa el significado del paquete de datos que se mueve a través del flujo.

Almacén.
Modela una colección de paquetes de datos (flujos) en reposo. Se representa gráficamente por dos líneas paralelas o por un rectángulo abierto por su lado derecho.

Por lo general el nombre utilizado para identificar un almacén incluye el plural de los paquetes (flujos) que entran y salen del almacén.
Los profesionales de la informática se refieren a los almacenes como archivos o bases de datos; pero un almacén puede consistir en un conjunto de fichas almacenadas en un archivo de metal, nombres y direcciones de una agenda, asientos de diario General, etc.
Los almacenes se conectan a través de flujos a los procesos. Un flujo que procede de un almacén se interpreta como una lectura o acceso total o parcial a la información del almacén. En caso contrario, cuando un flujo se direcciona hacia un almacén puede significar una de las siguientes operaciones:
· Se están guardando uno o más paquetes nuevos en el almacén.
· Se están borrando o retirando datos del almacén.
· Uno o más paquetes se están actualizando o modificando.

El Terminador.
Representa entidades externas con las cuales el sistema se comunica. Comúnmente un terminador es una persona, grupo u organización fuera del control del sistema que se está modelando que estimula el sistema a iniciar un proceso o recibe informaciones generadas por él. Ejemplo de terminadores lo encontramos en un cliente, un departamento dentro de la misma organización donde está implantado el sistema u otra organización.

La representación gráfica de un terminador es un rectángulo:

Un sistema complejo puede interactuar con docenas de terminadores. Identificarlos adecuadamente es de vital importancia para el analistas por ser estos los que estimulan o se benefician del sistema.


Reglas:
  • Las entidades y los almacenes se comunican sólo si existe un proceso intermedio.
  • Escoger nombres con significado para los procesos.
  • Numerar los procesos y almacenes.
  • Anotar una diagonal en la parte inferior derecha de las entidades duplicadas.
  • Asegúrese que el DFD se lógicamente consistente. Evitar:
  • ¾ Sumideros Infinitos: Procesos de sólo entradas.
  • ¾ Procesos de generación espontánea: Con salidas pero sin entradas
  • ¾ Flujos y procesos no etiquetados.
  • Redibuje el DFD cuantas veces sea necesario, ya sea para corregirlo funcional o estéticamente.
Niveles de un DFD
Diagrama de Contexto: Nivel 0
En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el dibujo.
Resulta de gran utilidad para los niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos DFD de Nivel "0"
Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté especificado por un requisito funcional, siendo en realidad un requisito no-funcional.
Diagrama de Detalle o Expansión: Nivel 2

En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a los caminos principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí en adelante se permiten los flujos entre procesos.
El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo de sistemas. También se recomienda el diagrama de nivel superior.


DICCIONARIO DE DATOS

Definición:

Lista organizada de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y procesos intermedios.

Edward Yourdon



Catalogo o deposito de los elementos de un sistema.

James Senn.



Referencia de los datos recopilados por el analista para guiarse durante el análisis y el diseño. Como documento, recopila, coordina y confirma lo que un término especifico significa para la gente de la organización

Kendall & Kendall


Importancia:
1. Maneja los detalles que no figuran en el Diagrama de Flujo de Datos.
2. Da un significado común a todos los elementos del sistema.
3. Documenta las características del sistema.
4. Facilita el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema.
5. Localizar errores y omisiones en el sistema.

 Contenido de un Diccionario de Datos:
  • Elemento de Datos 
  • Estructura de Datos
Descripciones de Datos:

  • Flujos, Almacenes, Estructuras de Datos, Procesos
  • Flujos: nombre, descripción, fuente, destino, estructura de datos.
  • Almacenes: Nombre, descripción, flujos recibidos, flujos proporcionados, Descripción de datos, volumen, acceso.
  • Estructura de Datos: Nombre, Descripción, Contenido, volumen
  • Notación: = Compuesto de  
       + y (Concatenación)
    ( ) Optativo (puede o no estar presente { } Iteración
    [ ] Selección de alternativas ¦ Separador de alternativas
    ** Comentario @ Campo clave

Comentarios

Publicar un comentario