Teste

Ingeniería del Software Avanzada- Grado en Ingeniería Informática

Proyecto

PROYECTO A/DOO
Recomendaciones
Cada frase/párrafo de la especificación corresponde con uno o más requisitos
funcionales y no funcionales.
Se añaden, si es necesario, requisitos implícitos en la especificación o requisitos que
mejoren o completen la especificación.
Todos los requisitos deben ser precisos, debenpoder probarse.
Cada requisito se integra en un caso de uso general, de primer nivel, y se desarrolla en
un caso de uso detallado del diagrama de casos de uso del caso de uso general. Los
requisitos no funcionales pueden, según el requisito, ser transversales a todos los casos
de uso.
Cada caso de uso detallado se concreta con uno o más (escenarios) diagramas de
secuencia.
Los objetos ymensajes del diagrama de secuencia se corresponden con clases y
métodos del diagrama de clases.
Las tablas de la base de datos y, si es el caso, los ficheros, están definidos en el modelo
de datos.
Las clases que modifiquen su situación durante su ciclo de vida (por ejemplo pedido
creado, aprobado, en espera, servido, pendiente de pago, pagado, cerrado,…) deben ser
explicadas mediante undiagrama de estados.
Los atributos de las clases persistentes deben corresponder con datos de la base de datos
o de ficheros. Los atributos, no obvios, deben llevar una explicación de su significado y
su uso.
Los métodos de las clases deben ser procesos básicos. Si el método no es obvio, es
decir, utiliza los métodos o los atributos de otras clases, selecciona información
utilizando criterios,genera información combinando o elaborando otra o realiza
cálculos, debe ser explicado mediante un diagrama de actividad y/o textualmente y
quedar indicado claramente de donde procede la información que utiliza y que hace con
la información que genera.
Las pruebas unitarias prueban métodos. Las pruebas de integración prueban llamadas
entre métodos, pueden ser casos de uso detallados. Las pruebasde sistema prueban
casos de uso generales, requisitos no funcionales y resistencia o estrés.

Comentarios a los artefactos
Se pueden encontrar ejemplos sobre artefactos y patrones en el libro de Craig Larman
‘UML y patrones’ de la editorial Prentice Hall.
Diagrama de contexto. Un único diagrama de casos de uso en el que se ven los
subsistemas como casos de uso y su relación con los actores(personas o sistemas de
información). Un subsistema es una agrupación lógica de casos de uso. Se describe
1

Ingeniería del Software Avanzada- Grado en Ingeniería Informática

Proyecto

brevemente el flujo de información de cada relación (puede ser un nombre o una frase).
No deberían aparecer más de siete subsistemas. El número ideal para sistemas medios es
tres o cuatro.
Descripcióndetallada de un caso de uso. Debe contener:
Identificativo y Nombre
Descripción breve
Actor principal y otros actores involucrados
Requisitos funcionales cubiertos
Precondiciones:
Condiciones para terminar con éxito el caso
Postcondiciones:
Situación del sistema después de acabar con éxito el caso
Escenario principal:
Actor
1.- Paso 1.
3.- Paso 3.
...

Sistema
2.-Paso 2.
4.- Paso4.
...

Escenarios excepcionales o alternativos:
En paso N: si no se ha podido x, entonces xxxxx
En paso N: si y , entonces xxxxx
En cualquier momentos: si z, entonces xxxxx

Requisitos no funcionales involucrados
Frecuencia
Diagrama de casos de uso que divide el caso de uso en casos de uso más
detallados
Descripción de Interfaz:
Lista y descripción de pantallas que aparecen a lolargo del desarrollo del
caso. Representación de las pantallas más significativas para servir como
prototipos. Pautas generales de diseño de la interfaz (teclas de función,
menú, iconos, ayuda on-line, mensajes de error)
Tabla Plan de desarrollo del software.
Identificativo

Descripción

Caso de uso o
requisito

Comentarios

Prioridad
(Alto/Medio/
Bajo)

Riesgo
(Alto/Medio/
Bajo)...