requisitos no funcionales
DESCRIPTION
breve resumen sobre requisitos no funcionales del softwareTRANSCRIPT
Aplicaciones Web J2EE y Requerimientos no funcionales
[ Una vista rápida ]
Abril 2009
Ing. Jorge Irey
Agenda
1. Taxonomia de Requisitos no Funcionales
2. Arquitectura vs. Diseño
3. Aplicaciones “n” – Capas: Tiers vs. Layers
4. Disponibilidad
5. Escalabilidad
6. Performance
7. Causas Comunes a los problemas
Motivación
“Fuerzas” que afectan a un Puente:Carga muertaCarga VivaCarga DinámicaCarga ambiental
“Fuerzas” que afectan al Software:Requerimientos FuncionalesRequerimientos NO Funcionales
Software
RequerimientosFuncionales
Característicasen tiempo de
ejecución
Restriccionesde Tecnología
Restriccionesdel Negocio
Otras Características
SLA QoS
Motivación (2)
Requerimientos
del Negocio
Documento de Visión y Alcance
Requerimientos
del usuario
Requerimientos
Funcionales
Requerimientos
del Sistema
Atributos de
Calidad
Otros Requerimientos
No funcionales
Restricciones
Documento de Casos de Uso
Especificación de Requerimientos de
SofwareIEEE Std 830-1998
Restricciones: “Solamente podrán votar los
ciudadanos legalmente residentes en el extranjero”
Taxonomia de Requisitos no Funcionales
OPERACION
Visión delUsuario
FACILIDAD DE MANTENIMIENTO ¿ puedo
arreglarlo ?
FACILIDAD DE PRUEBA ¿ puedo
probarlo ?
FLEXIBILIDAD ¿ Puedo modificarlo ?
INTEROPERABILIDAD ¿ podré comunicarlo con otros sistemas ?
PORTABILIDAD ¿ podré utilizarlo en otra máquina ?
REUSABILIDAD ¿ podré reutilizar parte del software ?
CORRECCION ¿ Hace lo que se requiere ?
FIABILIDAD ¿ funciona bien todo el tiempo ?
EFICIENCIA ¿ Funcionará lo mejor posible ?
INTEGRIDAD ¿ es seguro ?
FACILIDAD DE USO ¿ puedo ejecutarlo ?
Modelo de McCall
Taxonomia de Requisitos no Funcionales
Modelo ISO 9126
RNF-001 “Debe tener un diseño amigable e
intutitivo al usuario”
RNF-002 y RNF-020 “El sistema deberá
considerar un arquitectura lógica de 3 capas”
RNF-006: “ Habrá un servidor dedicado”
RNF-009: “ El sistema será desarrollado para
ejecutarse bajo el sistema operativo Windows XP”
RNF-019: “ El sistema usará MySQL ”
RNF-021 : “El servidor dedicado será como
mínimo P4 de 3 Ghz, 1 GB de RAM y disco duro
de 20 MB”
RNF-016 “A cada usuario empadronado se le
asignará un PIN”
RNF-014 “Se debe tener extrema seguridad para
la transferencia de información con respecto a los
votos”
RNF-022 “El tiempo de respuesta del sistema para
operaciones de carga de información deberá ser
como máximo 4 segundos con un ancho de banda
de 100 Mbps”
Arquitectura vs. Diseño
Diseño : que sucede cuando un usuario hace “click”
Arquitectura : qué sucede cuando “N” usuarios hacen “click”
Una arquitectura significa crear unainfraestructura de software que soporte los nivelesde servicio (SLA) identificados para el sistema.
CodigoCandidato Votos
C1 5
C2 12
C3 27
EJEMPLO: Votación Electrónica
¿Qué problemas potenciales tiene
la siguiente estructura de BD ?
PK
Tiers vs. Layers
VS.
Layer
Tier
SLA en Internet
1. Performance
2. Escalabilidad
3. Confiabilidad
4. Disponibilidad
5. Extensibilidad
6. Mantenibilidad
7. Manejabilidad
8. Seguridad
Todos estánrelacionados
Algoritmos de balanceo de carga:Round-robinRound-robin con pesosBasados en el tiempo de respuesta
Asignación de clientes a instancias (stickiness)Monitorización de disponibilidad de instanciasReintento de peticiones idempotentesSoporte de balanceadores HW
Replicación de sesiones HTTPCluster de Servidores
Algunas soluciones
Disponibilidad y Confiabilidad
• CONFIABILIDAD medida de la continuidad de servicios “cumplidos” ( o equivalentemente, mide el tiempo de fallas )
– MTTF Mean Time to Failure
– FIT Failures in Time = 1/MTTF ( Se mide en mil
millones de horas de operación = 109 )
– MTTR Mean Time to Repair ... Mide la interrupción del
servicio
– MTBF Mean Time Between Failure = MTTF + MTTR
• DISPONIBILIDAD Mide el cumplimiento del servicio con respecto a la alternancia entre los 2 estados. Para sistema no redundantes:
– Disponibilidad = MTTF / ( MTTF + MTTR )
Escalabilidad
• Comportamiento de una arquitectura cuando únicamente aumenta la carga del sistema y los demás parámetros se mantienen constantes.
Escalabilidad vertical: Aumentando el numero de CPU’s y memoria de los servidores
Escalabilidad horizontal: Aumentando el número de servidores
Performance
• Tiempo de Respuesta
• TroughtputCPU
Disco
...
1
2
m
X
Peticiones
completadasPeticiones
llegando
¿ k = n ?no
sí
rechazo
k <= n
n
cola
ejecución
A queueing Model for a single tier server
MENASCE, Daniel; BARBARÁ, Daniel; DODGE, Ronald. “Preserving QoS of E-commerce sites Throrugh Self-Tunning: A Performance Model Approach”.
ACM, Conferencia de Comercio Electrónico, Florida, USA, 2001. Universidad George Mason
l
Causas Comunes a los problemas
Base de Datos
Causas Comunes a los problemas
La aplicación desarrollada teóricamente cumple con el RES y el RDS, pero el usuario típico se queja : “El tiempo de respuesta está lento”
Configuración de la JVM, Garbage Collector
Código Java desarrollado no es óptimo
Arquitectura de la aplicación
Mala codificación de las sentencias SQL, se genera FULL SCAN
Mal diseño de transacciones en la Base de Datos, se generan bloqueos
Afinamiento del Sistema Operativo
Afinamiento del Servidor de Aplicaciones
Hay formas de medir la “experiencia” del usuarioHay formas de medir la cantidad de usuarios actuales.Hay que compararlo contra el RNF de la aplicaciónLuego: el trabajo consiste en determinar el MOTIVO de la lentitud
Tema de discusión
BDADSLPDAW
?
Ejemplo
Ejemplo clásico del RES : RNF-022 “el tiempo de respuesta del sistema para operaciones
de carga de información deberá ser como máximo 4 segundos de espera con una ancho de
banda de 100 Mbps”
Preguntas
¡ Gracias por su atención !