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.