Estándares para el Análisis de Sistemas

Documentación Requerida para la fase de Análisis y Diseño

• Historias de Usuario
• Narrativas de Casos de Uso
  • Casos de Uso
  • Modelos de Dominio
  • Prototipos UI/UX
• Especificación de Diseño de Alto Nivel
• Diagramas Entidad Relación
• Diagramas de Flujo
• Diagramas de Colaboración
• Diagramas de Interacción
• Diagramas Lineal Secuencial
• Diagrama de Procesos

Esta documentación es obligatoria y sin excepción alguna se deberá contar con ella, por lo que en cada Sprint de Desarrollo se considera un tiempo específico para su construcción.

Consultar la siguiente documentación para mayor detalle técnico sobre los diagramas:

• UML

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

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.

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.

Modelado del proceso

• 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.

Modelo de dominio

• 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.

Casos de Uso

• 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.

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.

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.

Prototipos

• 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.