Introducción al Análisis y Diseño de Sistemas

Teoría General de Sistemas

Introducción a la Teoría General de Sistemas

La Teoría General de Sistemas (TGS) plantea la existencia de un orden superior por sobre el mundo empírico que percibimos. La idea central es descubrir las leyes que rigen este orden:

• Ley universal - orden universal
• Descripción de la realidad (componente subjetivo y construcción social)

Premisas y supuestos de la TGS:

1. Orden y regularidad antes que aleatoriedad.
2. El carácter ordenado es propicio para su abordaje.
3. Ley de leyes.
4. Importancia de la lógica y la matemática (Contar, medir, comparar).
5. Inducción.

Pensamiento Lineal

• Definir el problema.
• Buscar las causas relacionadas en forma directa.
• Idear una solución para erradicar la causa.
• Implementar la solución.
• Puede no resultar.
• Reduce incertidumbre.
• No evalúa qué otros efectos introdujo.

Pensamiento Sistémico

1. Analizar la situación, identificar y definir el problema.
2. Buscar las causas.
3. Buscar posibles soluciones.
4. Elegir la alternativa de solución para implementar.
5. Diseñar la solución.
6. Implementar la solución.
7. Evaluar los resultados (Concordante con Ciclo de Deming).

Problema - Solución (Ciclo de Deming)

(Actuar, planear, hacer, verificar)

La Organización como Sistema

Modelo contextual de la organización:

• Competidores
• Clientes
• Proveedores
• Productos/servicios sustitutos

Análisis FODA:

• Fortalezas
• Oportunidades
• Debilidades
• Amenazas

Clasificación de las organizaciones según:

• Tamaño
• Sectores de la economía
• Fines de lucro
• Etc.

Misión: Razón de ser de la organización.

Estrategia: Determinación de metas y adopción de cursos de acción y administración de recursos para lograrlas.

Visión: “Imagen de lo que los miembros de la empresa quieren que ésta sea, o llegue a ser” - Karl Albretch.

Arquitectura organizacional: (estructura centrada en procesos)

Capas interrelacionadas:

1. Objetivos - Estrategias
2. Procesos de negocio
3. Sistemas de información
4. Datos
5. Infraestructura tecnológica

Funciones: Actividades primarias y actividades de soporte. Creación de valor.

: Introducción al Análisis de Sistemas

¿Qué es el Análisis de Sistemas?

Análisis: Distinción y separación de las partes de un todo hasta llegar a conocer sus principios o elementos. (Fuente: RAE)

Sistema de Información:

Definición I: Dado un sistema de referencia, una organización humana, por ejemplo, el sistema de información es un sistema finito de componentes, que a través de las operaciones que se realizan, representa su comportamiento.

Definición II: Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna de las siguientes categorías: Personas, Datos, Actividades o técnicas de trabajo, Recursos materiales.

Definición de Sistema

1. Conjunto de elementos o partes que se reúnen para un objetivo en común, al cual todos contribuyen cumpliendo un objetivo particular y donde el resultado final es mucho más que la suma de las partes.
2. Es una entidad cuya existencia y funciones se mantienen como un todo por la interacción de sus partes.
3. Es un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan formando un todo unitario y complejo.
4. Es un conjunto finito y limitado de partes, elementos o variables, todos ellos llamados subsistemas, interrelacionados dinámicamente, que interactúan en un período de tiempo determinado, con un objetivo común. Esto genera un comportamiento sinérgico, en el cual el todo es superior a la suma de las partes.

Pensamiento Sistémico

• Estamos rodeados de sistemas (sociales, políticos, comerciales, urbanos, ideológicos, etc.).
• Microsistemas, macrosistemas, subsistemas contenidos en otros.
• Para mejorar nuestra calidad de vida, debemos entender cómo funcionan.
• Se pueden observar patrones de conexión entre partes.
• Se pueden observar mismos principios en sistemas diferentes.
• Establecer si el sistema es simple o complejo.
• Crecimiento ilimitado de un sistema implica imposibilidad de control, por lo que se divide en partes.
• Propiedades emergentes: no se encuentran en las partes.
• Complejidad estática o complejidad dinámica.

Ingeniería de sistemas: Enfoque interdisciplinario cuyo objetivo es el estudio de los sistemas de información y a través de ellos comprender la realidad. Aborda la complejidad, modela y representa los mismos con herramientas propias. Aparece por los avances del conocimiento humano (tecnología). Integra teorías, conceptos, principios, técnicas, normativas y procedimientos de las ciencias para resolver problemas. Centrada en la comprensión de la realidad.

Ingeniería de software: Disciplina tecnológica y de administración que se ocupa de la producción y evolución sistémica de productos de software de calidad bajo tiempo y costos estimados. El conocimiento final es mayor que el inicial, esto significa que no sólo se aplicaron pasos o métodos preexistentes sino que se generó conocimiento. Centrada en la construcción del software.

Ciclo de Vida del Sistema

Etapas:

1. Investigación preliminar
2. Recolección de datos
3. Reporte de requerimientos
4. Plan del proyecto
5. Estudio de factibilidad
6. Análisis de requerimientos detallados (SRS o ERS)
7. Diseño de solución
8. Codificación del software
9. Testing individual e integrado
10. Conversión de datos preexistentes
11. Implantación del sistema
12. Capacitación de usuarios
13. Puesta a punto y mantenimiento
14. Evaluación post-mortem

Producto - Artefacto

• Acta de proyecto
• Especificación del alcance
• Plan proyecto
• Documento factibilidad
• Especificación funcional
• Diseño de alto nivel
• Acta de release, código fuente
• Software probado
• Plan de migración de datos
• Acta de entrega
• Manual de usuario
• Documento fortalezas - debilidades

Roles

Analista

El analista es un investigador, ya que el análisis es un proceso de descubrimiento. Investiga cómo se toman las decisiones, indaga los problemas del negocio, define las necesidades de los usuarios, se comunica con stakeholders, captura el conocimiento del dominio, descubre circuitos de la información, interpreta y aprende las costumbres de la organización (cultura), separa los juicios y subjetividades, identifica las fuerzas dentro de la organización y resuelve conflictos.

Competencias requeridas:

• Capacidad de análisis e indagación
• Trabajo en equipo
• Buena comunicación oral y escrita
• Predisposición

Diseñador

Es el creador y constructor de la solución.

Competencias requeridas:

• Posee base de conocimiento tecnológico
• Conoce tecnología disponible
• Traza los planos (modelos)
• Crea soluciones
• Identifica las fortalezas y debilidades de las alternativas de solución
• Establece la solución más adecuada a la problemática actual

Workflow

Workflow se refiere al flujo de trabajo a seguir para la consecución de una tarea o trabajo predeterminado. Se define como un sistema de secuencias de tareas de un proceso de negocio. Su definición y control puede ser manual, informatizado o mixto. Organiza y controla tareas, recursos y reglas necesarias para completar el proceso de negocio.

• Las nuevas tendencias, a la hora de regular las organizaciones, hacen del Workflow una herramienta clave para lograr mayor agilidad y aumentar la descentralización de las actividades administrativas y comerciales.
• La evolución de Workflow consiste en buscar la máxima automatización de los procesos de trabajo y el control total de las diferentes etapas, durante las cuales los documentos, la información o las tareas pasan de un participante a otro, según unas normas o procedimientos previamente definidos.
• A lo largo del tiempo, se han ido desarrollando diversas aplicaciones de software, muchas de ellas han evolucionado a partir de sistemas de gestión de imagen, sistemas de gestión de documentos, sistemas de correo electrónico o de bases de datos.

Beneficios:

• Ahorro de tiempo y mejora de la productividad y eficiencia de la empresa, debido a la automatización de muchos procesos de negocio.
• Mejora el control de procesos a través de la normalización de los métodos de trabajo. (Procesos definidos)
• Mejor atención y servicio al cliente; un incremento en la coherencia de los procesos da lugar a una mayor previsibilidad en los niveles de respuesta a los clientes.
• Mejora en los procesos; mayor flexibilidad de acuerdo con las necesidades empresariales.
• Optimización de la circulación de información interna con clientes y proveedores.
• Integración de procesos empresariales.

: Diagrama de Actividades y Workflow

¿Qué es una actividad?

Es una ejecución no atómica en curso, produce un cambio en el estado del sistema o la devolución de un valor. Puede estar compuesta por otras actividades o acciones (unidad atómica).

¿Qué es un Diagrama de Actividades?

Es un modelo que representa comportamiento mediante un flujo de datos y flujo de control. Lo usamos para modelar procesos de negocio.

• Muestra el flujo de control entre distintas actividades, cumpliendo una finalidad.
• Destaca la actividad a lo largo del tiempo.
• Los utilizamos para modelar procesos de negocio.
• Se construyen usando un lenguaje gráfico: UML.
• UML (Unified Modeling Language) es el “Lenguaje Unificado de Modelado”, respaldado por el OMG.
• El consorcio OMG (Object Management Group) es una organización que promueve el uso de las tecnologías orientadas a objetos, estableciendo y manteniendo estándares como: UML, BPMN, XMI, etc.

Requerimientos y Requisitos

Definiciones

Requerimiento: Necesitar. Dicho de una persona: Solicitar, pretender, explicar su deseo.

Requisito: Circunstancia o condición necesaria para algo.

1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
2. Una condición o capacidad que debe estar presente en un sistema o componente del sistema para satisfacer un contrato, especificación u otro documento formal.
3. Una representación documentada de una condición o capacidad.

Clasificación de los Requerimientos

1. Requerimientos Funcionales (RF): Describen los servicios que el sistema proporcionará y las funciones que será capaz de realizar.
2. Requerimientos No Funcionales (RNF): Definen las restricciones o características de cómo se brindará determinada funcionalidad. Pueden incluir aspectos como rendimiento, confiabilidad, usabilidad, mantenibilidad y portabilidad.

Documentación de los Requerimientos con calidad (RF y RNF)

La definición de los requerimientos debe realizarse considerando las siguientes características (SMART por sus siglas en inglés):

• Específico (Specific): Sin ambigüedad, conciso, claro, simple, detallado.
• Medible (Measurable): Evaluar el grado de satisfacción alcanzado (pruebas a realizar, criterios utilizados).
• Alcanzable (Attainable): Técnicamente factible.
• Realizable (Realizable): Se puede llevar a cabo con los recursos disponibles (personas, capacidades, infraestructura, tiempo).
• Rastreable (Traceable): Admite seguimiento desde origen, a través de la especificación, diseño, implementación y pruebas.

Ingeniería de Requerimientos

Disciplina que se encarga de la administración de los requerimientos que se ocupa de descubrir, analizar, documentar y validar estos servicios y restricciones, desarrollando estas actividades en forma sistémica, para definir los requerimientos de un sistema con alta calidad y eficiente empleo de recursos. Se estima que el conocimiento final es mayor que el inicial, esto significa que no sólo se aplicaron pasos o métodos preexistentes, sino que se generó conocimiento. Centrada en los requerimientos.

Es el proceso sistemático de desarrollar requerimientos a través de un proceso interactivo y cooperativo de análisis del problema, documentación de los resultados de las observaciones en variadas formas de representación, chequeando la precisión del conocimiento obtenido.

Elicitación de Requerimientos

Definiciones

Requerimiento: Un requerimiento es una característica del sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema. Se relaciona con las necesidades del usuario y las estrategias del negocio.

Elicitación: Elicitación de requerimientos (requisitos): Es el proceso de adquirir [elicit = sonsacar en inglés] todo el conocimiento relevante necesario para producir un modelo de los requerimientos de un dominio de problema u organización. (Sinónimo = Educción).

Stakeholder: Involucrado en el proyecto. Significa apostador en inglés. Es alguien que puede perder o ganar con el proyecto. Incluye a los usuarios.

Características y problemas de la Elicitación: Es una actividad humano-intensiva y principalmente de carácter social más que tecnológico. Se plantean conflictos de origen psicológico y social.

Pre-requisitos

Debemos conocer:

• Una perspectiva organizacional
• La contribución de los sistemas a las organizaciones
• Automatizar los procesos de negocios reduciendo costos
• Comunicación directa con los tomadores de decisiones
• Negocio: objetivo, visión, misión
• Alineación de los sistemas de información con el objetivo del negocio

Características y Problemas de la Elicitación

Caracterización de Problemas

Existen problemas de articulación cuando:

• Los usuarios no pueden expresar sus necesidades en forma clara.
• Existen incongruencias en sus propias necesidades.
• No quieren revelar ignorancia tecnológica.
• Entienden que la tecnología les va a quitar su tarea.
• No pueden posicionarse en una visión global, solo conocen su tarea.
• Vocabulario y hábitos culturales diferentes.
• Conflictos de intereses en el sistema a desarrollar.
• Formas de comunicación no adecuadas (usar gráficos que no se entienden).
• Conflictos personales o por ideología acerca de las políticas de la organización.

Limitaciones cognitivas (del desarrollador) provenientes de:

• Dominio del problema desconocido.
• Elaborar supuestos del dominio del problema o de aspectos tecnológicos.
• Simplificar el problema.
• Problemas propios de la conducta humana.
• Conflicto entre los roles de los participantes (superposiciones).
• Desmotivación del grupo (clientes, usuarios, analistas).

Existen problemas técnicos si:

• Dominio del problema complejo.
• Requerimientos complejos, conflictivos.
• Requerimientos de fuentes diversas (ambigüedades - no claros).

Impacto de los Errores

¿Cómo impactan los errores en la etapa de requerimientos?

• El producto construido no satisface al usuario.
• Se consumieron recursos en un sistema no deseado.
• Las ambigüedades interpretativas de requerimientos pueden llevar a conflictos y desacuerdos.
• Cuanto más tarde se detecte un error en el ciclo de vida del sistema, más costoso es repararlo.
• Los errores en los requerimientos son producidos por omisiones, suposiciones, inconsistencias, ambigüedades no detectadas y trabajadas.
• Existen errores latentes y que no son detectados en forma temprana.

Importante: Los errores detectados en etapas tempranas del ciclo de vida del sistema son menos costosos de resolver.

Fuentes de Información

Estructura de la entrevista y tiempos (aproximados):

1. Preparación previa (20’)
2. Apertura (5’)
3. Desarrollo (40’)
4. Cierre (10’)
5. Análisis de la entrevista (15’)

Tareas de la actividad “Preparación previa”:

• Leer antecedentes.
• Cuidado en el lenguaje.
• Buscar vocabulario en común (necesario para el correcto entendimiento).
• Establecer objetivos de la entrevista.
• Usando los antecedentes: los jerárquicos dan una visión general, los usuarios comunes aportan detalles.
• Seleccionar los entrevistados.
• Minimizar la cantidad de entrevistas.
• Los entrevistados deben conocer el objetivo de la entrevista y las preguntas que se les van a hacer.
• Planificar la entrevista: establecer fecha, hora, lugar y duración de entrevista, convocatoria acordada con el entrevistado.
• Selección tipo de preguntas y estructura.

En la entrevista las preguntas se clasifican en abiertas y cerradas.

Ejemplos de preguntas abiertas:

• ¿Cómo describiría el circuito de reposición de mercadería?
• ¿Qué opinión le merece el sistema actual?
• ¿Qué problemas puede enunciar en el mismo?

Ventajas de las preguntas abiertas:

• Abren nuevas líneas de preguntas.
• Hilo de la entrevista más interesante y llevadero.
• Facilitan la apertura y expresión del entrevistado.
• Permiten espontaneidad.

Desventajas de las preguntas abiertas:

• Pueden dar muchos detalles irrelevantes.
• Riesgo de perder el control de la entrevista.
• El entrevistador no tiene un objetivo claro y se va por las ramas.

Ejemplos de preguntas cerradas:

• ¿Quién recibe este informe?
• ¿Cuántas personas utilizarán el sistema?

Ventajas de las preguntas cerradas:

• Ahorran tiempo.
• Mantienen el control de la entrevista.
• Se consiguen datos relevantes.

Desventajas de las preguntas cerradas:

• Pueden aburrir al interesado.
• No se obtienen detalles.
• Datos precisos pero limitados.

Documentación de Requerimientos

Documentación de Requerimientos

• Encapsula para poder validarlo. Artefacto para comprender el problema y es el cimiento de la solución que se construirá.
• El producto de las entrevistas, estudios de documentos, etc., es necesario entrecruzarlo, trabajarlo para lograr el cuerpo del conocimiento consistente y validado por el usuario.
• Por lo general describimos los requerimientos en un documento llamado SRS (Software Requirement Specification) o ERS (Especificación de requerimientos de software).
• El contenido constituye el cimiento necesario para crear una solución y construirla.

¿Para qué sirve?

• Comunicación
• Contrato
• Costos
• Planificación del proyecto
• Validación y verificación - V&V
• Gestionar los cambios

Diferencias entre documentación y modelo

• Un modelo es una representación o abstracción de algún aspecto de la realidad.
• Una SRS es una forma más de representación, es textual, en el texto se utilizan dos principios: el de circularidad y el de lenguaje mínimo.
• Una especificación completa incluye modelos de las diferentes vistas del sistema.
• Las oraciones deben ser imperativas y claras. Ej. El sistema debe…
• Un modelo gráfico tiene la ventaja de la potencia visual, pero puede recortar detalles de este.
• Modelos y especificación se complementan.

Audiencia: ¿A quién está dirigida?

• Clientes y usuarios: Interesados en el objetivo del sistema, cómo lo operarán, cómo contribuirá para realizar sus tareas (funcionalidad).
• Analistas: Es el documento rector del proyecto. En la SRS estará detallado el problema o situación que se desea atender. Compromiso de actualización y vigencia.
• Desarrolladores (arquitectos, diseñadores, programadores): Es la base de la creación de la solución y la implementación del software.
• Testers: Con este documento verificarán si la solución software se construyó de acuerdo con el documento SRS. Es decir, si se construyó el software correcto. También se puede usar para sacar defectos, evaluar la calidad, verificando los RNF.
• Gerentes: Les sirve para medir y controlar el proyecto, ya que las SRS se corporizan (construyen) a través del plan.
• Equipo de Operaciones: Pueden establecer los recursos de hardware a través de la funcionalidad y su asiduidad (frecuencia, carga, accesos, etc.).
• Equipo de soporte de usuario: En base a este documento definirán el plan de capacitación, la atención de mesa de ayuda online, armado de manuales.
• Área legal: Como soporte para la formalización de documentos legales, contables, establecer escenarios de incumplimientos, determinación de responsabilidades.
• Subcontratistas: Pueden ser proveedores de algún servicio o componente y requerirán las especificaciones de estos.
• Entes reguladores, de control y normativas: En caso de que el proceso de desarrollo o el producto requiera certificación (o deban ser auditados) por organismos superiores.

Técnicas de Documentación

• Escritas en lenguaje natural
• UML - Casos de uso - especificación de escenarios
• Historias de usuarios (metodologías ágiles)
• SYSML (OMG)

La más usada: LENGUAJE NATURAL CONTROLADO. Utilizar principios de CIRCULARIDAD y LENGUAJE MÍNIMO. Debe utilizarse formato indentado para resaltar jerarquías.

Fortalezas y Debilidades

Ventajas: Poder de expresión ilimitado, no es limitante (todos nos comunicamos con el lenguaje), no requiere capacitación especial.

Desventajas: Exceso de riqueza, texto muy adornado complica la comprensión del núcleo, falta de estructuras no favorece su organización, dificultad en la búsqueda, ambigüedad, no puede tratarse con herramientas automatizadas, existe poca metodología de soporte.

Recomendaciones

• Usar glosario de términos.
• Oraciones cortas.
• Un requerimiento por oración.
• Evitar acrónimos no referenciados en glosario.
• Usar ecuaciones o lógica formal para expresiones precisas, cálculos, algoritmos o al relacionar información cuantitativa.
• Ejemplificar.
• Evitar combinaciones complejas de condiciones.
• Utilizar gráficos o esquemas.

Evolución de Requerimientos

Los requerimientos cambian inexorablemente.

Gestionar los Requerimientos

• Versionar Requerimientos: Administrar versiones de requerimientos es tan importante como tener versiones del código fuente, evita tener modificaciones emparchadas y provee claridad, incluso se puede identificar la motivación y fuente del cambio.
• Beneficios: Prevenir cambios no autorizados, guardar revisiones previas de cada requerimiento y seguir el historial, recuperar revisiones anteriores de un requerimiento, prevenir la modificación simultánea de requerimientos, administrar una estrategia de release mediante una herramienta (ej. Subversion, Tracker).

Cualidades de una especificación (SRS - ERS)

• Necesario
• Factible
• Entendible
• Trazable
• Estructurado
• Flexible
• Preciso
• Verificable
• Consistente
• Correcto
• Completo

Introducción al SysML

SysML (System Modeling Language): Desarrollado por el Object Management Group (OMG), SysML es un lenguaje de modelado que permite la representación gráfica de requerimientos y reglas del negocio. Es una extensión de UML (Unified Modeling Language) y se enfoca en el modelado de sistemas complejos que pueden incluir tanto software como hardware.

Modelado de Requerimientos

¿Qué es un modelo?: Un modelo es una representación simplificada de un aspecto del mundo real. Sirve para documentar, comunicar y entender un sistema. Puede ser textual, gráfico o matemático.

Origen del SysML: Surgió para abordar la necesidad de modelar hardware y luego se extendió al ámbito del negocio, áreas que no eran completamente cubiertas por UML.

Diagramas de Requerimientos

Diagrama de Requerimientos: Permiten representar requerimientos y sus relaciones con otros requerimientos o elementos que los implementan.

Ejemplo de Diagrama de Requerimientos: Utiliza convenciones de prefijo, numeración y nombre para representar un requerimiento. Por ejemplo, un requerimiento podría identificarse como RF_01 (Requerimiento Funcional 01).

Relaciones entre Requerimientos

Relaciones de Dependencia: SysML permite varias relaciones entre requerimientos:

• Agregación (Composite): Descompone un requerimiento complejo en sub-requerimientos.
• Copia (Copy): Reutiliza un requerimiento en otro diagrama.
• Derivación (Derive): Nuevos requerimientos que surgen del análisis de un requerimiento fuente.
• Uso (Use, Trace): Relación genérica entre dos requerimientos.
• Verificación (Verify): Especifica los casos de prueba que verifican un requerimiento.
• Satisfacción (Satisfy): Un elemento satisface un requerimiento.
• Refinamiento (Refine): Detalla un requerimiento usando ejemplos o diagramas adicionales.
• Realización (Realize): Un requerimiento implementa o concreta otro de nivel superior.

Clasificación FURPS+

• FURPS+: Es un acrónimo que clasifica los requerimientos en:
  • Funcional (Functional)
  • Usabilidad (Usability)
  • Confiabilidad (Reliability)
  • Rendimiento (Performance)
  • Capacidad de Soporte (Supportability)
  • + (Otros aspectos)

Ejemplificación y Uso de Herramientas CASE

• Herramientas CASE (Computer-Aided Software Engineering): Estas herramientas, como Enterprise Architect, utilizan símbolos y notaciones específicas para representar las relaciones y la estructura de los requerimientos.