Estándares para el Análisis de Sistemas

1.- La fase de análisis y diseño deberá ser sustentada con la documentación solicitada:

• Narrativas de caso de uso (UML).
• Modelado de procesos (diagramas de flujo).
• Diagramas de Modelo Lineal Secuencial.
• Diagrama de interacciones, colaboraciones, y flujo de datos.
• Descripción de interfaces de UI/UX y sus protocolos de uso.
• Análisis de requisitos de Software.

2.- Para lograr la documentación requerida el proceso deberá ser el siguiente:

1. Descomposición funcional

• La descomposición funcional se refiere al proceso de identificar y resolver las relaciones funcionales en sus partes constituyentes,

 de tal forma que la función global pueda ser reconstruida a partir de sus partes.
       * Por lo general, la descomposición funcional se realiza para identificar y entender los componentes o partes que constituyen un todo
         (o función global).
       * En este proceso, es vital identificar las interacciones entre componentes.
       * Aplicado a la Ingeniería de requisitos, consiste en tomar los requerimientos de software, dividirlos en partes y analizarlos
         individualmente. De ser necesario, se pueden descomponer en más partes hasta lograr un nivel adecuado de detalle.
       * En cierto sentido, el proceso es similar al de la elaboración de una estructura de desglose de trabajo de un proyecto.
       * En Ingeniería de sistemas, la descomposición funcional consiste en definir un sistema en términos funcionales, para luego definir
         funciones de más bajo nivel y establecer las relaciones con estas funciones de alto nivel.
       * La intención es dividir un sistema de tal forma que cada componente se pueda describir sin necesidad de referir a otro componente.
       * De esta forma, cada parte del sistema tendrá funciones independientes, que pueden reusarse y reemplazarse.
       
   2.	Especificación vía Sentencias Textuales
       * Es la forma tradicional de la especificación de requerimientos de software.
       * Se usan especificaciones textuales en lenguaje natural, que se documentan en matrices de trazabilidad de requerimientos o 
         definiciones del alcance.
       * El procedimiento consiste en tomar el requerimiento producto del levantamiento de información, para desarrollar una narrativa 
         más detallada.
       * No usa herramientas visuales como los flujogramas o estructura como los casos de uso, es simplemente una descripción más detallada 
         del requerimiento en lenguaje natural.
         
   3.  Modelado del proceso (imagen 1)
       * Comprende la elaboración de diagramas de flujo de procesos (Flujogramas) a partir de los requerimientos del software.
       * Definir una sola herramienta de modelado de procesos, para unificar símbolos y reglas.
       * Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y departamentos intervinientes.
       * Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas, manuales o combinación entre ambas.
       * Su naturaleza visual ayuda a la comprensión y comunicación a terceros.
       * Cuando los procesos son complejos, deben desglosarse en componentes (subprocesos).
       * La relación entre los diagramas de flujo y la gerencia de proyectos es fundamental para el éxito.
       
   4.  Modelo de dominio (imagen 2)
       * En Ingeniería de software, en análisis de dominio consiste en analizar sistemas o software relacionados en un dominio, 
         con la finalidad de encontrar sus partes comunes y partes que los diferencian.
       * Produce un modelo de contexto de negocio para todo el sistema.
       * Un modelo de dominio comprende diagramas conceptuales que incluyen tanto el comportamiento de un sistema como sus datos.
       * Un tipo de modelo de dominio son los diagramas de funcionalidades (Features Diagrams), que es una representación “compacta” 
         del sistema o aplicación en términos de sus características.
       * El análisis de dominio produce modelos orientados a objetos o modelos relacionales de datos, que pueden ser usados por los 
         desarrolladores de software como base de arquitecturas de software y aplicaciones.
         
   5.  Casos de Uso (imagen 3)
       * En el Lenguaje de Modelado Unificado (UML), un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo 
         que usa alguno de sus servicios.
       * Es una de las técnicas de mayor difusión para especificar el comportamiento del Sistema.
       * Formato simple y estructurado que puede ser compartido entre usuarios y desarrolladores.
       * Además de usarse para analizar los requerimientos de software, también pueden usarse en el diseño del sistema e inclusive para 
         definir pruebas de caja negra (Testing).
       * Son útiles en sistemas informáticos orientados a la funcionalidad (transacciones con el usuario), que se van a implementar 
         orientados a objetos y con UML.
       * No son la mejor opción en sistemas sin usuarios, o dominados fundamentalmente por requerimientos no funcionales.
       
   6.  Checklists
       * La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones que se realizan sobre los requerimientos de software, 
         que nos sean presentados de forma escrita.
       * Una lista de chequeo puede realizar preguntas como:
         * ¿ Se han especificado los requisitos de hardware y software ?
         * ¿ Se han realizado consideraciones de seguridad ?
         * ¿ El nivel de granularidad del requerimiento se ha incluido ?
         * ¿ Se ha incluido el código de referencia en para identificar el requisito en el desglose de requerimientos ?
         * ¿ Está escrito el requerimiento en un lenguaje claro y conciso ?
         * ¿ El requerimiento es único? (no existe duplicidad con otro requerimiento).
         * Y muchas preguntas más.
       * La lista de chequeo sirve de marco de trabajo y procedimental para revisar el requerimiento, facilitando su análisis de forma 
         estructurada.
       * Los requerimientos se pueden revisar sobre la matriz de trazabilidad de requerimientos o sobre la definición del alcance.
       
   7.  Inspección
       * Revisión no destructiva de los requerimientos de software. Por ejemplo:
         * Examinar un software visualmente para constatar que las pantallas solicitadas se encuentran incluidas.
         * Verificar la inclusión de los campos necesarios para el ingreso de datos.
         * Verificar la existencia de los botones necesarios para iniciar la funcionalidad que ha sido requerida.
         * Verificar que el requerimiento se apega a los estándares definidos para la aplicación. Por ejemplo estándares de navegación 
           entre pantallas y estándares de interfaz gráfica.
         * De forma similar al uso de la lista de chequeo, la inspección consiste en tomar el requerimiento definido en la matriz de 
           trazabilidad o definición de alcance, leerlo y producir un resultado para su corrección.
           
   8.  Prototipos (imagen 4)
       * Consiste en elaborar representaciones visuales (interfaz gráfica con el usuario) de los requerimientos de software.
       * Es una herramienta muy útil para validar con los usuarios, clientes e interesados de proyecto que el diseño funcional 
         corresponde con los requerimientos de software (Que existe entendimiento común entre desarrolladores de software y usuarios).
       * Permite a desarrolladores y usuarios entender mejor los requerimientos, determinar cuáles son indispensables y cuales deseables, 
         e identificar riesgos de forma temprana.
       * Puede enfocarse en toda la solución o sólo en áreas específicas.
       * Puede extenderse innecesariamente en el tiempo si las discusiones se realizan en torno al como en lugar de en torno al que.
       * La elaboración de prototipos conlleva iteraciones entre desarrolladores y usuarios, en los cuales se van elaborando varios 
         prototipos y sometidos a evaluación del cliente.