Proceso Unificado de Desarrollo de Software Fase de …ci3715/teoria/html/cla_0005.pdf · 4 7 Fase...

1

1

Proceso Unificado de Desarrollo de Software

Fase de Inicio

A. Soriano (UCV-USB)Septiembre 2005

2

Proceso Unificado: Referencia Básica

Craig Larman

“Applying UML and Patterns: An Introduction to Object. Oriented Analysis and Design and the Unified Process”

Prentice-Hall, Inc. 2002 ISBN 0-13-092569

Descripción del Problema: Cap. 3 Fase de Inicio Cap. 4 -5 - 6 y 7 Modelo de Casos de Uso: Cap. 6 - 25

2

3

Proceso Unificado:Referencias“El Proceso unificado de desarrollo de Software”I. Jacobson, G. Booch y J.RumbaughAddison Wesley - Pearson Education 1999

“Applying UML and Patterns: An Introduction to Object. Oriented Analysis and Design and the Unified Process”Craig LarmanPrentice-Hall, Inc. 2002 ISBN 0-13-092569

“The Rational Unified Process”Ph. KruchtenAddison Wesley 2000

4

Proceso Unificado:Referencias

“El Lenguaje Unificado de Modelado: Manual de Referencia”J.Rumbaugh, I. Jacobson y G. BoochAddison Wesley - Pearson Education 2000

“RUP”Herramienta de Rational

3

5

Proceso Unificado

Modelado del Negocio

ImplementaciónPrueba

Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos

Gerencia de ProyectoAmbiente

Fases

Iteraciones

Elaboración Construcción Transición

Gerencia de Configuración y Cambio

Inicio

6

Proceso Unificado: Fase de Inicio

tiempo

Inicio Elaboración Construcción Transición

Hito del Ciclo de Vida:Define el alcance y la

factibilidad del proyecto

4

7

Fase de Inicio: ¿Para qué?



Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio

¿Cuál es la visión y caso del negocio?

¿Es factible el proyecto?

¿Comprar o Construir el software?

¿Orden de precio?

¿Seguir adelante?

8

Fase de Inicio: ¿Cuántas iteraciones?

Iteración ... Iteración Iteración ... Iteración ...

Versiones Versiones Versiones Versiones Versiones Versiones Versiones Versiones

Inicio Elaboración Construcción Transición

5

9

Fase de Inicio: ¿Qué Actividades realizar?

• Formular el alcance del proyecto.Capturar los requerimientos y restricciones mas importantes, de los cuales pueda depender la finalización del producto

• Preparar el caso del negocio, identificar riesgos

y evaluar alternativas para su manejo, personal,

tiempos, estimar costos y beneficios

• Sintetizar una arquitectura candidata

10

Modelo de Casos de Uso

Glosario

Visión, Requerimientosy Caso del Negocio

Fase de Inicio: ¿Qué Artefactos producir?

Visión general (problema, usuarios, producto, restricciones)

Requerimientos principales

6

11


Glosario

Visión, Requerimientosy Caso del Negocio


Describe la terminología clave

Describe los requerimientos funcionales y aquellos no funcionales relacionados

12

EspecificacionesSuplementarias


Glosario

Visión y Caso del Negocio


Describe otros requerimientos

7

13

Plan de Iteración

Lista de Riesgos y

Plan de Manejo

EspecificacionesSuplementarias


Glosario



Describe y prioriza los riesgos

Describe cómo mitigar los riesgos

Describe qué hacer en la primera iteración de la Fase de Elaboración

14

Modelo del Dominio

Plan de Iteración

Lista de Riesgos y

Plan de Manejo

EspecificacionesComplementarias


Glosario



Prototipo

- del comportamiento del sistema

- de la estructura del sistema

Conceptos básico del dominio y relaciones entre ellos

8

15

¿Demasiada Documentación?

NO!

sólo deberá construir los

artefactos que considere necesarios

para alcanzar

el hito de la fase

16

Especificador de caso de uso

Caso de uso

Diseñador de interfaz de usuario

Prototipo de interfaz de usuario

Arquitecto

Descripción de la arquitectura

Analista de sistemas

Modelo de casos de uso

Actor Glosario

Fase de Inicio: ¿Quién es responsable de producir Qué?

9

17

ArquitectoPriorizar los casos de uso

Analista de sistemasEncontrar actores

y casos de usoEstructurar el modelo

de casos de uso

Diseñador de interfaces de usuario

Prototipo de la interfaz de usuario

Especificador de casos de usoDetallar un caso de uso

Fase de Inicio: ¿Cuándo debe producirse un artefacto?

18

Artefactos de la Fase de Inicio: ¿En qué disciplina debe producirse un artefacto?



Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio

- Caso del Negocio

- Modelo del Negocio

10

19

Artefactos de la Fase de Inicio: ¿En qué disciplina?



Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio

-Visión

- Modelo de Casos de Uso

- Especificaciones Complementarias

- Glosario

20




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio

- Modelo Conceptual

- Análisis y Diseño de

Interfaces

11

21




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio

Codificación de Prototipos

22




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio

Plan de Desarrollo del Software

12

23

¿Entendió la Fase de Inicio?

•¿Es una fase que no puede realizarse en unas pocas semanas,

excepto para proyectos pequeños y simples?

•¿Debemos capturar la mayor parte de los requerimientos?

•¿La planificación deberá ser estricta?

•¿ Se define completamente la arquitectura del sistema?

•¿Se debe primero levantar requerimientos, luego diseñar la

arquitectura y finalmente implementar?

•¿Es el documento Visión un documento superfluo?

•¿Es superfluo identificar actores y casos de uso?

•¿Debemos describir en detalle todos los casos de uso?

FALSO

FALSO

FALSO

FALSO

FALSO

FALSO

FALSO

FALSO

24

Los Requerimientos

¿Qué son?

¿Para qué sirven?

¿Cómo se clasifican?

¿A través de qué artefactos pueden describirse?

13

25

Los Requerimientos: ¿Qué son?

¿Qué deberá hacer el sistema?¿En qué condiciones deberá hacerlo?

¿Qué cualidades o atributos deberá poseer el sistema?

26

Los Requerimientos: ¿Para qué sirven?

Requerimientos

14

27

Los Requerimientos: Tipos

28

Los Requerimientos: Categorías FURPS+

15

29Req

u erim

ien t

o s o

A

trib u

tos d

e C

alid

adLos Requerimientos:

Categorías FURPS+

30

Func

iona

les

No

Func

iona

les

Los Requerimientos: Clasificación de uso común

16

31

Los Requerimientos: Artefactos

Los Requerimientos Funcionales

32

¿ Caso de Uso ?

Actor

¿Qué representa la figura?

Sistema

17

33

¿ Caso de Uso ?

¿Qué hace el actor?¡Usa el sistema !El actor interactúa con el sistema.

Se realiza una secuencia específica de acciones

Escenario Instancia de Caso de Uso

34

¿ Caso de Uso ?

• Representa una colección de escenarios de éxito y falla relacionados, que describe actores usando el sistema

• Define una funcionalidad del sistema

18

35

Caso de Uso: Definición en RUP

“Un conjunto de instancias de caso de uso, en el que cada instancia es una secuencia de acciones realizadas por el sistema y que conducen a un resultado de valor observable para un actor particular”

Appliyng UML and patterns. 2° edición

C. Larman

Prentice Hall. 2002

36

Caso de Uso: Definición en RUP

“Un conjunto de instancias de caso de uso, en el que cada instancia es una secuencia de acciones realizadas por el sistema y que conducen a un resultado de valor observable para un actorparticular”

Appliyng UML and patterns. 2° edición

C. Larman

Prentice Hall. 2002

19

37

Caso de Uso: Recomendación

1. Responder a la pregunta:

¿Qué puede hacer el sistema para producir resultados de valor para un actor en particular?

38

Computador,

Lector de código de barra

Software del Sistema

registrar ventas

y manejar los pagos

Caso de Estudio: Sistema de Punto de Venta

Punto de Venta para ventas al detal: POS (Point of Sale)

Uso principal:

Compuesto por: Ilustración extraída de:

Appliyng UML and patterns.

2° edición

C. Larman

Prentice Hall. 2002

20

39

Ejemplo: POSManejar devoluciones

Principal Escenario de éxitoUn cliente llega a la caja con productos para su devolución. El cajero usa el sistema POS para registrar cada producto .....

Escenarios AlternativosEl cliente pagó con tarjeta de crédito y la transacción de reembolso es rechazada, se le informa al cliente y ....

.....

40

¿Cómo determinar los Casos de Uso?

SISTEMA

¿Sistema?

21

41


SISTEMA

¿Límite del Sistema?

42


SISTEMA

Límite del Sistema

¿Actores?

22

43


SISTEMA

Actor

¿Qué quiere el actor? ¿metas? ¿objetivos?

44


SISTEMA

Actor

Esto, esto, esto

y esto

23

45


SISTEMA

Actor

Ah!, ahora defino los casos de uso.

46

Casos de Uso:Descripción

Breve

Casual

Completo

Un párrafo resumen correspondiente al escenario principal

Formato informal, los escenarios se presentan en múltiples párrafos

Formatos

Formato elaborado. Todos los pasos y variaciones se describen en detalle; incluye secciones de soporte tales como postcondiciones ...

24

47

Caso de uso en formato breveEjemplo: POS Manejar Devoluciones

Manejar devolucionesUn cliente llega a la caja con productos para su devolución. El cajero usa el sistema POS para registrar cada producto .....

48

Caso de Uso: Manejar DevolucionesPrincipal Escenario de éxito

Un cliente llega a la caja con productos para su devolución. El cajero usa el sistema POS para registrar cada producto .....

Escenarios Alternativos

El cliente pagó con tarjeta de crédito y la transacción de reembolso es rechazada, se le informa al cliente y ....

.....

Caso de uso en formato casualEjemplo: POS Manejar Devoluciones

25

49

Caso de uso en formato completowww.usecases.org

Actor Principal

Expertos e Interesados

Precondiciones

Éxito Garantizado (Postcondiciones)

Escenario Principal de Éxito ( Curso Básico)

Extensiones (Cursos Alternos)

Requerimientos Especiales

Tecnología y Lista de Variaciones de Datos

Frecuencia de Ocurrencia

Preguntas abiertas

Actor que invoca al sistema

solicitando un servicio con un propósito

particular

50

Caso de uso en formato completoEjemplo: POS Procesar Venta

Actor Principal: Cajero

26

51

Actor Principal

Participantes e Intereses

Precondiciones


Escenario Principal de Éxito (Curso Básico)





Preguntas abiertas

Posibles participantes en el

Caso de Uso y sus intereses


52


Participantes e Intereses:

Cajero: Desea garantizar registro rápido y sin errores en los pagos

Vendedor: Desea que su comisión se registre adecuadamente

...

27

53

Actor Principal


Precondiciones







Preguntas abiertas

Aquellas premisas que deben ser ciertasantes de la ejecución

del caso de uso


54


Precondiciones: El Cajero está identificado y autorizado

28

55

Actor Principal


Precondiciones







Preguntas abiertas

Establece lo que debe cumplirse

en caso de haber sidocompletado con éxito

el caso de uso.Escenario principal o algún curso alterno


56


Postcondiciones:

La venta fue registrada.

El impuesto fue correctamente calculado.

El inventario fue actualizado.

Las comisiones fueron registadas.

Se generó un recibo.

29

57

Actor Principal


Precondiciones







Preguntas abiertas

También llamado escenario“happy path”.Describe el curso típico que satisface el interés

de aquellos relacionados con el caso de uso


58


Escenario Principal de Éxito (Flujo Básico):

El escenario registra principalmente tres tipos de pasos:1. Interacción entre actores2. Validación (generalmente hecha por el sistema)3. Cambio de estado del sistema

(ejemplo: registrar o modificar información)

30

59


1) El Cliente llega al POS de salida con artículos a comprar

2) El Cajero inicia una nueva venta

3) El Cajero introduce la identificación del producto

4) El sistema registra cada línea de venta y presenta la descripción y el total acumulado

El Cajero repite los paso 3 y 4 hasta que se indique hecho


60


Escenario Principal de Éxito (Flujo Básico):1) El Cliente llega al POS de salida con artículos a comprar


3) El Cajero introduce la identificación del producto

4) El sistema registra cada línea de venta y presenta la descripción y el total acumulado

El Cajero repite los paso 3 y 4 hasta que se indique hecho

FORMATO DE UNA COLUMNA

31

61


Acción del Actor Respuesta del Sistema

1) El Cliente llega al POS de

salida con artículos a comprar


3) El Cajero introduce la

identificación del producto 4) Registra cada línea de venta ypresenta la descripción y el total acumulado

El Cajero repite los paso 3 y 4 hasta

finalizar de introducir los productos

...


FORMATO DE DOS COLUMNAS

62

Actor Principal


Precondiciones


Escenario Principal de Éxito ( Curso Básico)





Preguntas abiertas

Indican otos escenarios o ramas, tanto de éxito

como de falla.Generalmente son más

extensos y complejos que el curso normal


32

63


Extensiones (Cursos Alternos):3a. Identificación inválida:

1. El Sistema señala el error y rechaza la entrada

3b. Hay diferentes clases del mismo producto:

1. El Cajero puede introducir la categoría y la cantidad

...

64

Actor Principal


Precondiciones







Preguntas abiertas

Requerimientos no funcionalesasociados conel caso de uso


33

65


Requerimientos Especiales:

- Pantalla Táctil en un gran monitor plano. El

texto debe ser visible a 1 metro.

- La respuesta sobre la autorización de la

tarjeta toma 30 segundos el 90% de las veces

...

66

Actor Principal


Precondiciones







Preguntas abiertas

Detalles técnicos quedeben ser considerados

en el caso de uso


34

67


Tecnología y Lista de Variaciones de Datos:

3a. La identificación del producto se introduce por

una lectora laser o por el teclado.

3b. La identificación del producto se introduce en

diferentes esquemas de codificación (UPC, EAN,

JAN o SKU)

68

Actor Principal


Precondiciones







Preguntas abiertas

Indica la frecuencia de ocurrencia del caso de uso


35

69


Frecuencia de Ocurrencia:

Puede ser casi contínuo

70

Actor Principal


Precondiciones







Preguntas abiertas

Apectosno consideradosque se mantienen

como preguntas abiertas


36

71


Preguntas Abiertas:

-¿Qué variantes hay en la ley de impuestos?

-¿Puede el cliente directamente usar el lector de

tarjetas de crédito, o es indispensable que lo haga

el cajero?

...

72

Caso de uso:Descripción

¿Qué formato usar?

Breve

Casual

Completo

37

73

Lenguaje de Modelación Unificado

UnifiedModelingLanguage

74

Use CaseDiagramsUse Case

DiagramsDiagrama de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagrama de Actividad

ScenarioDiagramsScenario

DiagramsDiagrama de Secuencia

Use CaseDiagramsUse Case

DiagramsDiagrama de Estados

StateDiagramsState

DiagramsDiagrama de Clases

Diagrama de Colaboración

Diagramas

StateDiagramsState

DiagramsDiagrama de Objeto

ComponentDiagramsComponent

DiagramsDiagrama deComponentes

ComponentDiagramsComponent

DiagramsDiagrama de Despliegue

UML 1.x: Vistas y Diagramas

38

75

UML 2.0 (Unified Modeling Language)

Diagramas Dinámicos

Múltiples vistasSintaxis y semántica precisas

Diagramas deActividad

Diagramas

Diagramas Estáticos

Diagramas de Secuencia

Diagramas de Comunicación

Diagramas deMáquina de

Estado

Diagramas deDespliegue

Diagramas deComponentes

Diagramas deObjeto

Diagramas deClasesDiagramas de

Casos de Uso

76

Vistas y Diagramas

– Diagramas de Casos de Uso

Representa las funcionalidades

del sistema a partir de las interacciones del usuario

39

77

Diagrama de casos de uso

• Especifica el comportamiento de un sistema• Describe la secuencia de acciones que dan un

resultado observable a un actor• Captura el comportamiento del sistema (el qué)

omitiendo la implementación del comportamiento(el cómo)

• Identifica las funcionalidades visibles al usuario

78

• Representan los entes externos que interactúan con el sistema:

– tipos de usuarios– otros sistemas

• Inician la ejecución de los casos de uso

Diagrama de casos de uso: Actores

40

79

Diagrama de Casos de Uso: Componentes

• Actor: entidad externa que interactúa con el sistema activando o participando en la ejecución los casos de uso

• Caso de uso: secuencia de transacciones iniciadas por un actor y que constituye una funcionalidad del sistema

A

B

Actores Casos de uso

usuario2

usuario1

80

Diagrama de casos de uso: Relaciones

Relaciones entre actores y casos de uso

Relaciones entre casos de uso:

Relaciones entre actores:

Asociación

Extensión (<<extend>>)

Generalización

Inclusión (<<include>>)

Generalización

41

81

Diagrama de casos de uso: Relaciones entre Actores y Casos de Uso

• AsociaciónRelacionaun actor

con un caso de uso

Ir al cine

Actor

82

Diagrama de Casos de Uso: Componentes

nombre del caso de uso

número del caso de uso

nombre del sistema

Nombre del actor

Nombre del actor

nombre del caso de uso

número del caso de uso

Participación de un actor en un caso de uso

42

83

– En la relación de Asociación puede indicarse la cardinalidad (multiplicidad)

Ir al cine1 *

Una persona puede “Ir al cine” cero o muchas veces

Persona

Diagrama de casos de uso: Relaciones entre Actores y Casos de Uso

84

Diagrama de Casos de Uso: Relaciones entre Casos de Uso

• Extensión(<<extend>>)

• Generalización• Inclusión

(<<include>>)Relación que define uncurso alterno opcional

de otro caso de uso (base)

43

85

Diagrama de Casos de Uso: Relación extend

Ir al cine

Comprar cotufas

<<extend>>tengo dinero

• Relaciones extend:el caso de uso Ir al cine puedeincluir el comportamiento especificado en el caso de uso Comprar cotufas

86

Diagrama de Casos de Uso: Relación extend (extension points)

Comprar cotufas

<<extend>>tengo dinero• Extension points:

el caso de uso podrá ejecutarse una vez alcanzado el (los) extension point(s) indicado(s)

Ir al cineExtension points

requerimientos adicionales:despues de entrar al cine

44

87

Diagrama de Casos de Uso: Relación extend

• Es una asociación que describe un curso alterno opcional (la extensión) de otro caso de uso (base).

• ¿Cuándo usarla?– En partes opcionales de un caso de uso– Cursos alternativos que raramente ocurren– Cursos separados que son ejecutados bajo ciertas

condiciones– En situaciones donde se puede seleccionar entre diferentes

alternativas– Puede ser ejecutado directamente por el actor

88

Diagrama de casos de uso: Relaciones entre Casos de Uso

• Extend• Generalización• Include

Relación que define un caso de uso

como una generalización de otro caso de uso

45

89

Relaciones entre Casos de Uso : Generalización

• Relación Generalización: el caso de uso divertirse es una generalización del caso de uso ir al cine

Ir alcine divertirse

90

Diagrama de casos de uso: Relaciones entre Casos de Uso

• Extend• Generalización• IncludeRelación que define

una instancia de un caso de uso como un curso

obligatorio en otro caso de uso

46

91

Relaciones entre Casos de Uso: include

• Relación include: el caso de uso Ir al cine siempre incluye el comportamiento especificado en el caso de uso Comprar entrada

<<include>>Comprar entrada

Comprar cotufa

<<extend>>tengo dinero

Ir al cineExtension points

requerimientos adicionales:despues de entrar al cine

1 *

92

Relaciones entre Casos de Uso: include

• Es una asociación que relaciona cursos fuertemente acoplados que conforman el curso completo del caso de uso base

• ¿Cuándo usarla?– Para particionar un caso de uso complejo en los casos

de usos constitutivos– Separar una parte del caso de uso base que por si misma

constituye una funcionalidad (posible caso de uso abstracto)

47

93

Relaciones entre Casos de Uso: Comparación include/extend

Diferentes intenciones• Include

– permite extraer un comportamiento común o aislarfuncionalidades

– en general los actores no están relacionados con el casode uso aislado

• Extend– permite extraer variantes de un curso normal– el actor puede estar relacionado con el caso de uso

aislado

94

Relaciones entre Casos de Uso: Reacomode e Indique las relaciones

responder

exámen

ir al baño

colocar identificación

al exámen

pediraclaratoria

solicitar

exámen

Realizar la Prueba

leer

exámen

entregar

exámen

estudiante

Utilizar

calculadora

buscar Calificación

48

95

responder

exámen

ir al baño

colocar identificación

al exámen

pediraclaratoria

solicitar

exámen

Realizar la Prueba

leer

exámen

entregar

exámenestudiante

Utilizar

calculadora

Buscar Calificación

<<include>><<include>>

<<include>>

<<include>>

<<include>>

<<extend>>

<<extend>><<extend>>

Relaciones entre Casos de Uso: Reacomode e Indique las relaciones

96

Diagrama de casos de uso: Relaciones entre actores

• Generalización

Un actor es una “instancia”de otro actor

49

97

Relaciones entre actores: Generalización

• Relación de Generalización: una persona es una generalización de un estudiante

estudiantepersona

98

Ejemplo POS : Requerimientos Funcionales

1. Límites 2. Actores 3. Metas

Agente de Impuesto a las

Ventas

CajeroSistema

POSMeta:

Colectar impuestos

Meta:

Adquirir productos

Meta:

Analizar las ventas y producir reportes de eficiencia

Meta:

Procesar ventas

Cliente

Servicio de Ventas

Sistema de

Actividad de Ventas

Servicio de Entrega

50

99

Agente de Impuesto a las

Ventas

CajeroSistema

POSMeta:

Colectar impuestos

Meta:

Adquirir productos

Meta:


Meta:

Procesar ventas

Cliente

Servicio de Ventas

Sistema de

actividad de Ventas

Servicio de Entrega

Cajero Sistema POS

Sistema de Actividad de Ventas


4. Casos de Uso

100

Cajero Sistema POS



4. Casos de Uso

Administrador del Sistema

Meta:

Procesar ventasMeta:


Meta:

Garantizar seguridad y

Manejar Usuarios

51

101

Meta:


Meta:


Manejar Usuarios

Cajero Sistema POS



4. Casos de Uso


Meta:

Procesar ventas

Meta del Cajero:

Procesar Venta

102


4. Casos de Uso

Meta del Cajero:

Procesar Venta

Procesar Venta Manejar Devoluciones

Cobrar

Alquilar

52

103

Meta:


Meta:


Manejar Usuarios

Cajero Sistema POS



4. Casos de Uso


Meta:

Procesar ventas

Meta del Sistema de Actividad de Ventas:


104


4. Casos de Uso

Meta del Sistema de Actividad de Ventas:


Analizar Actividad

53

105

Meta:


Meta:


Manejar Usuarios

Cajero Sistema POS



4. Casos de Uso


Meta:

Procesar ventas

Meta del Administrador del Sistema:


Manejar Usuarios

106


4. Casos de Uso

Meta del Administrador del Sistema:


Manejar Usuarios

Manejar Seguridad

Manejar Usuarios

54

107


4. Casos de Uso

POS

Cajero



108


4. Casos de Uso

POS

Cajero


<<actor>> Sistema de

Actividad de Ventas

Representación alternativa con el

uso de un “estereotipo”


55

109


4. Casos de Uso

POS

Cajero



Actividad de Ventas

Manejar Seguridad

Manejar Usuarios

Analizar Actividad

Procesar Venta

Manejar Devoluciones

Cobrar

Alquilar

110


4. Casos de Uso

Servicio de Autorizaciones de Pago


Suscripciones

<<actor>> Sistema Calculador

de ImpuestosManejar Seguridad

Manejar Usuarios

Analizar Actividad

Procesar Venta


Alquilar

POS

Cajero



Actividad de Ventas

Cobrar

......

56

111


4. Casos de Uso

Casos de Uso y Formatos de Descripción

Procesar Venta


...

Alquilar

Analizar Actividad de Ventas

Manejar Seguridad

...

Pagar

Cobrar

Manejar Usuarios

...

Completo Casual Breve

112

Ejemplo POS : Otros Requerimientos

UsabilidadFactores Humanos: el Cliente dispondrá de un monitor grande asociado a POS

- El texto debe ser visible a 1 metro

- Evitar colores poco visibles

...

57

113

Ejemplo POS : Otros Requerimientos

Usabilidad

Confiabilidad

Interfaz

Implementación

Documentación Legal

...

Proceso Unificado de Desarrollo de Software Fase de …ci3715/teoria/html/cla_0005.pdf · 4 7 Fase...

Documents

Transcript of Proceso Unificado de Desarrollo de Software Fase de …ci3715/teoria/html/cla_0005.pdf · 4 7 Fase...