presentacion del capitulo 9 de entrega continua

1. Juan Pablo Rivera Zabala
Id: 000261281
Ingeniería de Sistemas e Informática

2. El concepto de requerimiento funcional y no funcional
Es artificial. Ya que los Requisitos no funcionales tales como disponibilidad,
Capacidad, seguridad y mantenibilidad son tan importantes y valiosos
Como los funcionales, y son esenciales para el funcionamiento del sistema. las
Alternativas -como los requisitos funcionales del sistema
Han sido sugeridas -y, en nuestra experiencia, la forma en que
Son comúnmente tratados raramente funciona bien.
Un ejemplo de un requisito no funcional es la disponibilidad que una aplicación
bancaria tenga para operar , debe ser capaz de operar tanto con un usuario como con
100 usuarios simultáneos
requerimientos no funcionales

3. Gestión de los requerimientos no
funcionales
La dificultad para tratar los requisitos no funcionales de un sistema de manera diferente
De los requisitos funcionales es que hace que sea fácil dejarlos fuera del proyecto por que no
Planificamos o no prestamos la atención suficiente. Esto puede ser desastroso porque Los NFRs
son una fuente frecuente de riesgo en el proyecto y Descubrir tarde en la aplicación que un
Proceso no es apto para el propósito debido a una falla de seguridad o mal rendimiento puede
llevar a que el proyecto sea cancelado por no tener en cuenta estos requisitos que son tan
importantes al momento de poner en marcha la aplicación.
En términos de implementación, los NFRs son complejos porque usualmente tienen una
Influencia muy fuerte en la arquitectura del sistema. Por ejemplo, cualquier sistema
Que requiere un alto rendimiento no debe implicar peticiones que atraviesen varios
Niveles Dado que la arquitectura del sistema es difícil de cambiar más adelante en la entrega.

4. los NFR tienden a interactuar entre sí de una manera poco útil:
Los sistemas muy seguros comprometen a menudo la facilidad de uso; Sistemas muy flexibles a
menudo comprometen el rendimiento, y así sucesivamente. En un mundo ideal todos quieren que
sus sistemas sean altamente seguros, de muy alto rendimiento,
Masivamente flexible, extremadamente escalable, fácil de usar, fácil de soportar,
simple de desarrollar y mantener, en realidad cada una de estas características
Tiene un costo. Cada arquitectura implica una cierta descompensación entre requerimientos no
funcionales y funcionales.

5. Análisis de requerimientos no funcionales
El problema con los requisitos no funcionales mal analizados es que tienden
a menudo a conducir un diseño excesivo y una optimización inadecuada.
Es demasiado fácil gastar cantidades excesivas de tiempo en escribir código .
Los programadores son bastante pobres en predecir donde se creara un cuello de botella de
rendimiento en Una aplicación , Tienden a hacer que el código sea innecesariamente complejo y,
por lo tanto, costoso

6. Programación de la capacidad
Estrategia para abordar los problemas de capacidad:
1- Decidir sobre una arquitectura para su aplicación. Prestar especial atención
Para procesar y establecer limites en dispositivos E / S y en general.
2- Entender usar patrones y evitar anti patrones que afecten la estabilidad
Y la capacidad de su sistema.
3- Mantener al equipo trabajando dentro de los límites de la arquitectura elegida, pero,
Aparte de aplicar patrones cuando sea apropiado, ignorar el deseo para optimizar
la capacidad. Fomentar la claridad y la simplicidad en el código. Nunca
Comprometer la capacidad de lectura sin una prueba explícita que demuestre
el valor
4-Preste atención a las estructuras de datos y algoritmos elegidos, asegurándose de que
Sus propiedades son adecuadas para su aplicación. Por ejemplo, no use
(n)algoritmos si usted necesita (1) un solo requerimiento

7. 5- Establecer pruebas automatizadas que afirmen el nivel deseado de capacidad. Cuando estos
pruebas fallan, utilícelas como una guía para reconocer que problemas se tiene y poder corregirlos en el
menor tiempo posible.
6-Donde sea posible, utilice las medidas de capacidad en el mundo real. Si su sistema de producción
Es su única fuente real de medición. Úselo y entienda lo que es
Prestando especial atención al número de usuarios del sistema,
Sus patrones de comportamiento y el tamaño del conjunto de datos de producción determinan la
capacidad de operación que tiene el sistema.

8. Medición de la capacidad
Medir la capacidad implica investigar un amplio espectro de características de
Una aplicación. Estos son algunos tipos de medidas que se pueden realizar:
• Pruebas de escalabilidad. ¿Cómo funciona el tiempo de respuesta de una solicitud individual y
El número de posibles usuarios simultáneos cambia a medida que agregamos más servidores,
Servicios o hilos?
• Pruebas de longevidad. Esto implica ejecutar el sistema durante mucho tiempo para ver
Si el rendimiento cambia durante un período prolongado de operación. Este tipo
De pruebas pueden detectar fugas de memoria o problemas de estabilidad.
• Pruebas de rendimiento. ¿Cuántas transacciones, o mensajes, o visitas de página por
Segundo puede manejar el sistema?
• Prueba de carga. ¿Qué sucede con la capacidad cuando la carga en la aplicación
Aumenta a proporciones de producción y más allá? Esta es quizás la
Clase más común de pruebas de capacidad

9. El entorno de pruebas de capacidad
Las mediciones absolutas de la capacidad de un sistema deberían realizarse idealmente
En un entorno que sea, lo más cerca posible, y reproduzca la producción del
Ambiente en el que el sistema funcionará en su última instancia.
El comportamiento de los sistemas informáticos de alto rendimiento es una área compleja .susceptible a
Los cambios de configuración , estos tienden a tener un efecto no lineal
Sobre las características de la capacidad. Cosas simples como alterar la proporción de la interfaz de usuario
puede llevar a crear un mal entorno de visualización
-la cantidad de conexiones del servidor de aplicaciones y de bases de datos
Puede aumentar el rendimiento total de un sistema en un orden de muy ato espectro
Estas son algunas de las variables importantes con las que se debe jugar para mantener la continuidad del
negocio).

10. Uso de plantillas de interacción registrada
Esta estrategia puede utilizarse en aplicaciones que proporcionan un mecanismo de comunicación de API
que no sea de una interfaz gráfica de usuario
, como un servicio web, colas de mensajes o alguna otra
. Esto puede ser un punto ideal para guardar interacciones
, que le permite esquivar los problemas de escalamiento de cliente, la complejidad
de manejar cientos o miles de procesos de cliente y la relativa fragilidad
de interactuar con el sistema a través de la interfaz de usuario.

11. Usando pruebas de capacidad en test de desarrollo
Siempre que esté escribiendo pruebas de capacidad, es
Importante empezar por la aplicación haciéndole un test, a la interfaz,
O la tecnología bajo prueba para que pueda mostrar que esta prueba puede ejecutarse en la
Velocidades que necesita y se pueda afirmar que opera correctamente cuando el otro extremo esta haciendo
Algún trabajo simultáneamente.
existen casos en que Pruebas que afirman que la aplicación falla en capacidad de operación, cuando
en realidad fue la prueba misma la que
No podía mantener el ritmo esto es un error de diseño de la estructura de la prueba

12. Adición de las pruebas de capacidad en el despliegue de la app
La mayoría de las aplicaciones deben cumplir con un umbral mínimo de capacidad. las
Aplicaciones comerciales deben estar en capacidad de operar con muchos usuarios simultáneos y
Por lo tanto, deben escalar para satisfacer su perfil de demanda máxima y
Rendimiento aceptable. Durante el desarrollo, lo que necesitamos es la capacidad de afirmar
Que nuestra aplicación logrará la capacidad requerida por el cliente.
Esto significa que cada cambio que pasa las pruebas de confirmación y las pruebas de aceptación
Deben tener pruebas de capacidad automatizadas en su contra. Así es posible
Identificar el momento en que se introduce un cambio que afecta
Capacidad de la aplicación.
Algunos tipos de prueba de capacidad pueden tomar mucho tiempo para ejecutar, dando por
resultado
un retraso insostenible antes de obtener un resultado de prueba de aceptación.

13. Muchas Gracias