1 / 16

Entregas modelado VISION

Entregas modelado VISION. 2010-2011. VISIÓN 1 - requisitos. Algunos requisitos no tienen número (#id ), ni tipo, ni descripción, ni prueba, ni estereotipo reqMSEEI .

binh
Download Presentation

Entregas modelado VISION

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Entregas modelado VISION 2010-2011

  2. VISIÓN 1 - requisitos • Algunos requisitos no tienen número (#id), ni tipo, ni descripción, ni prueba, ni estereotipo reqMSEEI. • Hay algún requisito duplicado (¿duplicados al intentar hacer la descomposición? )Si vais a seguir por aquí habría que repasar con cuidado esta parte del modelo • Todos los requisitos generales dependen (deben ser satisfechos) por TODO el sistema (por sus dos partes). Esto lo habéis hecho bien para casi todos los requisitos. • Por ejemplo, “Avisar de cliente” es un requisito que habría que redactar mejor porque si bien el interfaz al usuario está en el puesto de recepción, realmente necesita también de la Cámara Inteligente. • Por eso mismo habéis descrito pruebas que parecen necesitar siempre que el sistema esté funcionando al completo. • Por ejemplo, “GuardarCliente” , se prueba: Realizamos una simulación en la que guardamos un cliente ficticio. Comprobamos manualmente en la base de datos que se ha realizado con éxito la operación.. ¿En qué consiste la simulación? ¿En que todo el sistema funcione? • Los diagramas de Requisitos sirven para “aclararse” con los requisitos y sus dependencias. A veces, poner toda la información sobre el diagrama (satisfy y refine), sólo “emborrona” el diagrama, y además este tipo de relaciones puede ser más claro mirarla en la tabla. En definitiva, que aunque se haya usado el diagrama para establecer las relaciones, se puede de cara a la documentación del TFM dibujar otro donde no se vean (o borrarlas del diagrama original, recordad que siguen estando en el modelo) • Por estas dos causas es necesaria la descomposición, que en vuestro modelo creemos que no habéis hecho. ¿Puede ser?

  3. VISIÓN 2 - requisitos • Los satisfy de los requisitos de alto nivel son a todo el sistema. Por eso luego se descompone.. • Por eso las pruebas que habéis redactado para esos requisitos, implican el funcionamiento de todo el sistema. Las pruebas creemos que están muy bien definidas (a falta del visto buen del tutor) • A algunos requisitos les falta algún campo (son los añadidos por la descomposición, si vais a seguir por aquí habría que mirar si el campo es necesario) • No salen los requisitos padre en la tabla. Da un problema de hecho al generarla, si vais a seguir usándola, decídnoslo y la miramos más despacio. • Los diagramas de Requisitos sirven para “aclararse” con los requisitos y sus dependencias. A veces, poner toda la información sobre el diagrama (satisfy y refine), sólo “emborrona” el diagrama, y además, este tipo de relaciones puede ser más claro mirarla en la tabla. En definitiva, que aunque se haya usado el diagrama para establecer las relaciones, se puede de cara a la documentación del TFM dibujar otro donde no se vean (o borrarlas del diagrama original, recordad que siguen estando en el modelo

  4. VISION1 – casos de uso ¿Generalización mejor? En ese caso, habría que borrar la relación PersonalMantenimiento-AvisarCliente Hay que aclarar definitivamente el caso Avisar de cliente: ¿Incluye reconocerlo? ¿Qué significa ese include?

  5. VISION2 – casos de uso Frame “Sistema Completo” Y a lo que sería el sistema completo ¿Puesto de recepción? Hay que aclarar definitivamente el caso Avisar de cliente: ¿Incluye reconocerlo? ¿Generalización mejor? En ese caso, habría que borrar la relación Mantenimiento-AvisarCliente ¿Hay un include aquí?

  6. VISION1 - arquitectura I/O Flows: Son Eventos o clases en función del tipo de información OK! Interfaz device: Esos módulos sería mejor que fueran subsistemas ¿no? Interfaz device: Parece que tuviera el sistemas dos teclados y dos ratones …

  7. VISION2 - arquitectura Se echa de menos una caja “Sistema de …” que rodee a toda la arquitectura. La misma que se escoja para el diagrama de Casos de uso. Hay un “intento” de diagrama que tenéis por ahí (buscar en la Vista Diagramas en “AllDiagrams”) en la que sí empezasteis delimitando el Sistema. I/O Flows: ¿Todos son Eventos? Interfaz device. Esos módulos sería mejor que fueran subsistemas ¿no? Interfaz device: Parece que tuviera el sistemas dos teclados y dos ratones …

  8. VISIÓN1/2-comportamiento Aquí se pueden poner los periféricos (interface devices) que intervienen

  9. Entregas modelado RSI 2010-2011

  10. RSI 1 - requisitos Los diagramas de Requisitos sirven para “aclararse” con los requisitos y sus dependencias. A veces, poner toda la información sobre el diagrama (satisfy y refine), sólo “emborrona” el diagrama, y además, este tipo de relaciones puede ser más claro mirarla en la tabla. En definitiva, que aunque se haya usado el diagrama para establecer las relaciones, se puede de cara a la documentación del TFM dibujar otro donde no se vean (o borrarlas del diagrama original, recordad que siguen estando en el modelo)

  11. RSI 1 - requisitos • Sólo hay un par de relaciones de satisfy, Habría que poner todos las satisfy antes de seguir. Tal vez os liamos un poco al intentar hacer los sastify con frames.. • Requisitos duplicados y sin descomposición (¿duplicados al hacer la descomposición?) Usabilidad por ejemplo. • ¿Despistes? Requisitos “Funcionamiento General” contenido en “caídaProgHotel”. Relación de derive “extraña (ver diagrama en la transparencia anterior) • Como es lógico para requisitos de alto nivel, las pruebas que proponéis son casi siempre del sistema completo. Creo que realmente estáis pensando en que el sistema ya está en marcha: o bien que ya hay al menos otros subsistemas funcionando. Ejemplos ¿En dónde se “ve” que se genera un evento? ¿Dónde se monitoriza la señal?

  12. RSI 2 - requisitos Esos derives los tenemos que discutir

  13. RSI 2 - requisitos • Los satisfy de los requisitos de alto nivel son a todo el sistema, no a sus distintas partes. Por eso luego se descompone. • Por eso casi todas las pruebas os salen de todo el sistema funcionando, y algunas de requisitos de más bajo nivel que los generales (como “movimiento”) os salen de integración entre dos subsistemas. Ejemplo: Integración NS con NNE • Algunos requisitos tienen tipo y otros no (alguno de los que no tienen, son los añadidos por la descomposición, podemos añadir ese tipo si vais a seguir por aquí)

  14. RSI1 - arquitectura Los I/O Flow no salen porque el diagrama de secuencia, creo, que lo habéis hecho creando eventos directamente. Ahora, habría que añadir I/O Flows a las relaciones que aparecen en el diagrama de contexto del tipo evento (ya creado en el diagrama de secuencia) correspondiente.

  15. RSI2 - arquitectura A los I/O Flow sería mejor ponerles un tipo más adecuado al tipo de información que llevan. Por ejemplo, los datos de tipo Clase…

  16. RSI 1/2-comportamiento Aquí se pueden poner los periféricos (interface devices) que intervienen Si ponéis esa línea en donde señala la flecha, ahí se pueden poner los periféricos (interface devices) que intervienen

More Related