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.
  • Descripción.
  • Diagramas de Modelo Lineal Secuencial.
  • Diagrama de interacciones, colaboraciones, y flujo de datos.
  • Interfaces UI/UX y sus protocolos de uso.
• Modelado de procesos.
• Descripción de Diseño del Sistema.
  • Análisis de requisitos de Software.
  • Diagrama Entidad Relación en la parte de DB.

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

• 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

• 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

• 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

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