Prueba la solución tecnológica

Prueba La solución Tecnológica

En la ingeniería del software, las pruebas de rendimiento son las pruebas que se realizan, desdé
una perspectiva, para determinar lo rápido que realiza una tarea un sistema en condiciones
particulares de trabajo. Las pruebas de rendimiento son un subconjunto de la ingeniería de
pruebas, una práctica informática que se esfuerza por mejorar el rendimiento, englobándose en el
diseño y la arquitectura de un sistema, antes incluso del esfuerzo inicial de la codificación. Existen
diferentes tipos de pruebas para las cuales están diseñadas para poder llevar al máximo el
programa o sistemas que se desea poner a prueba

Pruebas de carga

Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se realiza
generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones
esperada. Esta carga puede ser el número esperado de usuarios concurrentes utilizando la
aplicación y que realizan un número específico de transacciones durante el tiempo que dura la
carga.

Prueba de estrés

Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el número de

usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este
tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos descarga
extrema y ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en
caso de que la carga real supere a la carga esperada

Prueba de estabilidad (soak testing)

Esta prueba normalmente se hace para determinar si la aplicación puede aguantar una carga
esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de
memoria en la aplicación.

Pruebas de picos (spike testing)

La prueba de picos, trata de observar el comportamiento del sistema variando el número de

usuarios, tanto cuando bajan, como cuando tiene cambios drásticos en su carga. Esta prueba
recomienda que sea realizada con un software automatizado que permita realizar cambios en el
número de usuarios mientras que los administradores llevan un registro de los valores a ser
monitorizados.

Pre-requisitos para las pruebas de carga

Un desarrollo estable de la aplicación instalado en un entorno lo más parecido al de producción. El

entorno de pruebas de rendimiento no debe cruzarse con pruebas de aceptación de usuarios ni
con el entorno de desarrollo. Esto es tan peligroso que si las pruebas de aceptación de usuarios, o
las pruebas de integración o cualquier otra prueba se ejecutan en el mismo entorno, entonces los
resultados no son fiables. Como buena práctica, siempre es aconsejable disponer de un entorno
de pruebas de rendimiento lo más parecido como se pueda al entorno de producción
Mitos de las pruebas de rendimiento

Algunos de los mitos más comunes son los siguientes.

1.

Las pruebas de rendimiento se hacen para romper el sistema: Las pruebas de estrés se hacen para
observar el punto de ruptura del sistema. Por el contrario, las pruebas normales de carga se hacen
generalmente para ver el comportamiento de la aplicación bajo una carga de usuarios esperada, y
dependen de otros requisitos, tales como el aumento de carga esperado, la carga continuada por
un periodo prolongado de tiempo mientras la demanda aumenta, la resistencia a las caídas o las
pruebas de estrés.

2.

Las pruebas de rendimiento sólo deben hacerse después de las pruebas de integración del
sistema: Aunque esta es la norma común en la industria, las pruebas de rendimiento también
pueden realizarse mientras se realiza el desarrollo inicial de la aplicación. Este tipo de enfoque se
conoce como pruebas de rendimiento tempranas. Este enfoque garantizaría un desarrollo holístico
de la aplicación manteniendo los parámetros de rendimiento en mente. Por lo tanto, la búsqueda
de un problema en el rendimiento justo antes de la terminación de la aplicación y el coste de
corregir el error, se reduce en gran medida

3.

El probar el rendimiento sólo implica la creación de scripts y cualquier cambio en la aplicación solo
puede causar una simple refactorización dichos scripts: Las pruebas de rendimiento son en sí
mismas una ciencia evolucionada de la industria del software. En sí mismos, los scripts, aunque
importantes, son sólo uno de los componentes de las pruebas de rendimiento. El principal desafío
para cualquier persona que pruebe el rendimiento es determinar el tipo de pruebas necesarias y
analizar los distintos medidores de rendimiento para determinar el cuello de botella de
rendimiento.

Especificaciones del rendimiento

Es fundamental detallar las especificaciones de rendimiento y documentarlas en algún plan de

pruebas de rendimiento. Idealmente, esto se hace durante la fase de requisitos del desarrollo de
cualquier proyecto de desarrollo de sistemas, antes de cualquier esfuerzo de diseño. A veces es
una difícil tarea determinar qué parte del sistema representa esta ruta crítica, y algunas
herramientas de prueba incluyen y que informan de tiempos de transacción, número de accesos a
bases de datos, sobrecarga de la red, y otros monitores del servidor, que pueden ser analizados
junto con los datos principales de las estadísticas de rendimiento. Sin estos instrumentos se podría
tener a alguien encargado de observar el administrador de tareas de Microsoft Windows del
servidor para ver cómo se carga la CPU en las pruebas de rendimiento (suponiendo que se prueba
un sistema de Windows).Las pruebas de rendimiento se pueden realizar a través de la web, e
incluso hacerse en diferentes partes del país, ya que es sabido que los tiempos de respuesta de
Internet varían regionalmente. También se puede hacer en local, aunque el hardware de
enrutamiento debe estar configurado para introducir el desfase de lo que suele ocurrir en las
redes públicas. Las cargas deben ser realizadas en puntos realistas del sistema. Por ejemplo, si el
50% de usuarios de un sistema accede a través de una conexión de módem de 56K y la otra mitad
a través de una T1, entonces la carga simulada (ordenadores que simulan los usuarios reales) se
debe realizar, ya sea con las mismas conexiones (caso ideal) o simular la latencia de la red de
conexiones de este tipo, siguiendo el mismo perfil de usuario. Siempre es útil disponer de una
estimación del pico de número de usuarios que se espera que utilicen el sistema en las horas
punta. Si puede ser también una estimación del máximo tiempo de respuesta permitido en el
percentil 95, para que la configuración de la ejecución de las pruebas se ajuste a estas
especificaciones. La especificación de rendimiento, como mínimo, debería responder a las
siguientes preguntas:

• ¿Cuál es el alcance, en detalle, de la prueba de rendimiento? ¿Qué subsistemas, interfaces,

componentes, etc están dentro y fuera del ámbito de ejecución de esta prueba?

•Para las interfaces de usuario involucradas, ¿Cuál es el número de usuarios concurrentes que se
esperan para cada uno (especificando picos y medias?

• ¿Cuál es la estructura objetivo del sistema (hardware, especificando todos los servidores de red
y configuraciones de dispositivo)?

• ¿Cuál es la distribución del volumen de trabajo de la aplicación para cada componente? (por
ejemplo: 20% login, 40% buscando, 30% seleccionando elemento, 10%comprando).

• ¿Cuál es la distribución del trabajo del sistema? [Las cargas de trabajo múltiples pueden ser
simuladas en una sola prueba de eficacia] (Por ejemplo: 30% del volumen de trabajo para A, 20%
del volumen de trabajo para B, 50% del volumen de trabajo para C)

• ¿Cuáles son los requisitos de tiempo para cada uno y para todos los procesos por
lotes(especificando picos y medias)

Entregar la solución tecnológica al cliente

El punto de entrega es un desarrollo reciente en la administración de proyectos. Tradicionalmente,

un proyecto se divide en fases, hitos y tareas, pero el enfoque de punto de entrega utiliza una
fecha de vencimiento absoluta para el proyecto y todo lo que se haya realizado al término de esa
fecha se debe implementar. Es importante establecer una fecha de vencimiento razonable según
el tamaño y las metas del proyecto. También, es necesario priorizar las metas del proyecto con el
propósito de entregar a los usuarios las más importantes a la fecha de vencimiento. Las metas
menos importantes pueden ser implementadas posteriormente en el proyecto. Un ejemplo de
punto de entrega (timeboxing) es crear un sitio Web que contenga las características más
importantes, aún y cuando algunas páginas de menor importancia muestren la imagen "En
construcción”. El enfoque de punto de entrega (timeboxing) establece una fecha de vencimiento
absoluta para el proyecto, y todo lo que se haya terminado para esa fecha debe implementarse
que contenga las características más importantes, aún y cuando algunas páginas de menor
importancia muestren la imagen "En construcción”. El enfoque de punto de entrega (timeboxing)
establece una fecha de vencimiento absoluta para el proyecto, y todo lo que se haya terminado
para esa fecha debe implementarse.

Determinar el tipo de implantación de la solución tecnológica Gestionar la infraestructura para la

solución tecnológica

Cada sistema de información tiene su propio tipo de decisión .Sistema de procesamiento de

transacciones (TPS): decisiones estructuradas Sistema de apoyo a ejecutivos (ESS): decisiones no
estructuradas Las etapas de la toma de decisión son: Obtención información estratégica es decir,
identificar los problemas. Diseño se diseñan posibles soluciones. Selección se elige la mejor
solución .Implementación se lleva a la practica la solución elegida. Los sistemas de información son
fruto de un proceso de resolución de problemas de la organización. Desarrollo de sistemas:
actividades que producen una solución de sistemas de información para un problema u
oportunidad de la organización. Análisis de sistemas: Análisis de un problema que la organización
tratara de resolver con un sistema de información. El analista de sistemas crea un diagrama de la
organización y sus sistemas existentes, e identifica a los propietarios y usuarios primarios de la
organización. A partir de este análisis, el analista detalla los problemas o las limitaciones de los
sistemas existentes Factibilidad: Un estudio de factibilidad es necesario para determinar si la
solución es factible o no, dados los recursos y las restricciones de la organización.

Factibilidad técnica: determina si una solución propuesta se puede implementar no con el

hardware, software y recursos técnicos disponibles. Factibilidad económica: determina si una
solución propuesta superan o no a los costos. Factibilidad operativa: determina si una solución
propuesta es o no deseable dentro del marco gerencial y de organización existente.

Mantiene la solución tecnológica

Identificar las necesidades, expectativas, restricciones e interfaces para el desarrollo de las

soluciones tecnológicas de TIC y definir los requerimientos de manera detallada. El Responsable de
este proceso deberá: 1. Coordinarse con el Administrador del portafolio de proyectos de TIC, para
que el proyecto correspondiente al desarrollo de la solución tecnológica se

Inscriba en el portafolio de proyectos de TIC y que se asigne un Responsable de proyecto.

2. Asegurarse que se elabore el Documento de planeación del proyecto, de acuerdo al proceso

APTI- Administración de proyectos de TIC.3. Asegurarse que se asignen los roles y responsables
para la ejecución del proyecto y se registren en el Documento de planeación del proyecto. El
Analista de requerimientos de soluciones tecnológicas de TIC, con apoyo del Representante de la
unidad administrativa solicitante, cuando así corresponda; 4. Identificar las necesidades de la
solución tecnológica que se pretende desarrollar, tomando en cuenta: a) La normativa que incide
en la solución tecnológica de que se trate. b) Las expectativas, interfaces y restricciones, existentes
y proyectadas.5. Definir los requerimientos de las soluciones tecnológicas de TIC, para lo cual: a)
Traducir las necesidades identificadas, en requerimientos específicos. b) Integrar la información y
el diseño de la solución tecnológica de TIC que se haya desarrollado, mediante el proceso DSTI-
Diseño de servicios de TIC. c) Analizará el modelo de flujo de negocio que será provisto, en su caso,
por la Unidad administrativa solicitante.6. Revisar y validar los requerimientos específicos
definidos conforme a los factores críticos 4 y 5, así como integrarlos en el Documento de visión de
la solución tecnológica de TIC

Actualizar los cambios de la solución tecnológica

Desarrollar los requerimientos de soluciones tecnológicas de TIC, considerando los componentes o

productos asociados a las mismas .El Analista de requerimientos de soluciones tecnológicas de TIC
deberá:1. Desarrollar los requerimientos de la solución tecnológica de TIC de que se trate, para lo
cual: a) Analizará la información contenida en el Documento de visión de la solución tecnológica
de TIC .b) Detallará los requerimientos de la solución tecnológica, así como la características de
dichos requerimientos .c) Definirá el diagrama de flujo y las reglas de negocio, conforme a los
cuales la solución tecnológica proveerá la funcionalidad requerida. d) Identificará los
requerimientos para cada producto o componente de la solución tecnológica, con base en las
definiciones del Paquete de diseño del servicio de TIC, desarrollado en el proceso DSTI- Diseño de
servicios de TIC.2. Identificar interfaces, externas e internas.3. Establecer las relaciones entre los
requerimientos de la solución tecnológica de TIC.4. Integrar la información de esta actividad en el
Documento de especificación de requerimientos de soluciones tecnológicas, y actualizar el
Repositorio central de requerimientos.

Depurar la información de la solución tecnológica

El Diseñador de soluciones tecnológicas de TIC, con apoyo del Arquitecto de soluciones

tecnológicas y del Líder técnico de desarrollo, deberá:

1. Adoptar el método para el diseño detallado de la solución tecnológica que, de acuerdo con la
alternativa seleccionada, resulte ser el más adecuado.2. Determinar las capas de diseño,
considerando :a) La arquitectura tecnológica de la solución. b) El diseño funcional. c) El diseño de
interfaces. d) Los flujos de información. e) Las estructuras de datos. f) Las estructuras y relaciones
de componentes.3. Desarrollar el diseño detallado de la solución tecnológica, de acuerdo con los
estándares y criterios técnicos que para este proceso se definen conforme al proceso OSGP-
Operación del sistema de gestión y mejora de los procesos de la UTIC.4. Identificar las interfaces
asociadas con otros componentes, soluciones tecnológicas o servicios de TIC de la Institución o,
incluso de otras instituciones u organizaciones.5. Elaborar el Documento de diseño, en el que se
contenga el diseño detallado de la solución tecnológica.

Utilizar sistemas de control de versiones

Definir los componentes o productos que serán integrados en la solución tecnológica, así como la
secuencia para realizar la integración. El Integrador de la solución tecnológica, con apoyo del Líder
técnico de desarrollo y de los Desarrolladores de la solución tecnológica, deberá:1. Identificar los
productos o componentes que serán integrados en la solución tecnológica.2. Definir los tipos de
verificación que serán ejecutadas durante laintegración.3. Identificar alternativas de integración y
de secuencia, así como efectuar pruebas sobre estas.

4. Analizar las diversas alternativas y seleccionar aquélla que técnicamente resulte la más
conveniente para la integración de la solución tecnológica, y realizar la justificación
correspondiente.5. Documentar en el Reporte de integración, la alternativa seleccionada y su
respectiva justificación.6. Actualizar, con la información de los factores críticos anteriores, el
Repositorio de configuraciones, el Repositorio central de proyectos y, en caso de establecerse, el
Repositorio de componentes y productos