Diferencia entre revisiones de «Estándares para el Análisis de Sistemas»
(→Modelado del proceso) |
|||
| (No se muestran 31 ediciones intermedias de 3 usuarios) | |||
| Línea 1: | Línea 1: | ||
| − | == | + | ==Documentación Requerida para la fase de Análisis y Diseño== |
| − | * Narrativas de | + | * Historias de Usuario |
| − | * | + | * Narrativas de Casos de Uso |
| − | * | + | ** Casos de Uso |
| − | * | + | ** Modelos de Dominio |
| − | * | + | ** Prototipos UI/UX |
| − | * Diagramas de | + | * Especificación de Diseño de Alto Nivel |
| − | * | + | * Diagramas Entidad Relación |
| − | * | + | * Diagramas de Flujo |
| − | * | + | * Diagramas de Colaboración |
| − | * Diagrama | + | * Diagramas de Interacción |
| + | * Diagramas Lineal Secuencial | ||
| + | * Diagrama de Procesos | ||
| − | + | Las Narrativas de Casos de Uso serán entregadas y revisadas por el cliente, con el objetivo de obtener su aprobación para el inicio del desarrollo. | |
| − | === | + | |
| − | * La | + | '''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.''' |
| − | * Por lo general, | + | |
| − | * En este proceso | + | '''En caso de ser necesario, la documentación generada podrá ser modificada conforme se vaya avanzando con el sprint de desarrollo''' |
| − | * Aplicado a la Ingeniería de | + | |
| + | Consultar la siguiente documentación para mayor detalle técnico sobre los diagramas: [https://www.omg.org/spec/UML/2.5.1/PDF UML] | ||
| + | |||
| + | ===Herramientas de Construcción=== | ||
| + | * Se establece el uso obligatorio de [http://dia-installer.de/index.html.es Dia] para la creación de los Diagramas | ||
| + | * Se establece el uso obligatorio de [https://balsamiq.com/ Balsamiq] para la creación de los Prototipos de UI/UX | ||
| + | |||
| + | ==Aspectos Generales== | ||
| + | |||
| + | ===Checklists=== | ||
| + | El 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? ¿Existe duplicidad con otro requerimiento? | ||
| + | * ¿Ya existen módulos previamente hechos y su documentación? (Para reutilizarlos) | ||
| + | |||
| + | 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. | ||
| + | |||
| + | ===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, se realiza para identificar y entender los componentes o partes que constituyen un todo. | ||
| + | * En este proceso es vital identificar las interacciones entre los diferentes 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 cierto sentido, el proceso es similar al de la elaboración de una estructura de desglose de trabajo de un proyecto. | ||
| − | |||
* La intención es dividir un sistema de tal forma que cada componente se pueda describir sin necesidad de referir a otro componente. | * 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. | * 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. | * 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. | * 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. | * 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 sistema. | |
| − | + | ||
| − | * Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y departamentos | + | * Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y departamentos involucrados. |
| − | * Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas, manuales o combinación | + | * Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas, manuales o combinación de ambas. |
* Su naturaleza visual ayuda a la comprensión y comunicación a terceros. | * Su naturaleza visual ayuda a la comprensión y comunicación a terceros. | ||
* Cuando los procesos son complejos, deben desglosarse en componentes (subprocesos). | * 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. | + | * La relación entre los diagramas de flujo y la gerencia de proyectos es fundamental para el éxito del producto. |
| + | |||
| + | '''El propósito de este diagrama es documentar el proceso con el fin de comprender la operación desde el punto de vista del cliente, es decir, plasmar la forma en que el cliente lleva a cabo sus actividades.''' | ||
[[Archivo:Imagen_Analisis_1.png|center|Modelado del proceso]] | [[Archivo:Imagen_Analisis_1.png|center|Modelado del proceso]] | ||
| − | === | + | ===Modelo de dominio=== |
| − | + | Consiste en analizar todo el sistema, en relación con un dominio específico. Esto con la finalidad de encontrar sus partes comunes y partes que los diferencian. | |
| + | |||
* Produce un modelo de contexto de negocio para todo el sistema. | * 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 modelo de dominio comprende diagramas conceptuales que incluyen tanto el comportamiento de un sistema como sus datos. | ||
| Línea 47: | Línea 83: | ||
[[Archivo:Imagen_Analisis_2.png|center|Modelado de dominio]] | [[Archivo:Imagen_Analisis_2.png|center|Modelado de dominio]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ||
| − | + | ===Inspección=== | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
====Revisión no destructiva de los requerimientos de software. Por ejemplo:==== | ====Revisión no destructiva de los requerimientos de software. Por ejemplo:==== | ||
* Examinar un software visualmente para constatar que las pantallas solicitadas se encuentran incluidas. | * Examinar un software visualmente para constatar que las pantallas solicitadas se encuentran incluidas. | ||
| Línea 79: | Línea 93: | ||
* 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. | * 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. | * 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). | * 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). | ||
| Línea 86: | Línea 100: | ||
* Puede extenderse innecesariamente en el tiempo si las discusiones se realizan en torno al como en lugar de en torno al que. | * 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. | * 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. | ||
| − | |||
| − | |||
Revisión actual del 20:49 19 mar 2021
Sumario
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
Las Narrativas de Casos de Uso serán entregadas y revisadas por el cliente, con el objetivo de obtener su aprobación para el inicio del desarrollo.
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.
En caso de ser necesario, la documentación generada podrá ser modificada conforme se vaya avanzando con el sprint de desarrollo
Consultar la siguiente documentación para mayor detalle técnico sobre los diagramas: UML
Herramientas de Construcción
- Se establece el uso obligatorio de Dia para la creación de los Diagramas
- Se establece el uso obligatorio de Balsamiq para la creación de los Prototipos de UI/UX
Aspectos Generales
Checklists
El 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? ¿Existe duplicidad con otro requerimiento?
- ¿Ya existen módulos previamente hechos y su documentación? (Para reutilizarlos)
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.
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, se realiza para identificar y entender los componentes o partes que constituyen un todo.
- En este proceso es vital identificar las interacciones entre los diferentes 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.
- 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 sistema.
- Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y departamentos involucrados.
- Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas, manuales o combinación de 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 del producto.
El propósito de este diagrama es documentar el proceso con el fin de comprender la operación desde el punto de vista del cliente, es decir, plasmar la forma en que el cliente lleva a cabo sus actividades.
Modelo de dominio
Consiste en analizar todo el sistema, en relación con un dominio específico. Esto 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.
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.
