Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Criterios para evaluar la calidad del software

Se describen algunos de los criterios de la calidad del software
by

Isaac Arce

on 1 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Criterios para evaluar la calidad del software

Criterios para evaluar la calidad del software Desempeño Rendimiento Cantidad de trabajo en una unidad de tiempo Tiempo de respuesta Medida de latencia en proceso de transacción Capacidad de una aplicación para hacerse más grande sin perder calidad Características generales Toman en cuenta aspectos funcionales y no funcionales.
Esenciales para garantizar la calidad en el software.
Deben ser medibles.
Es necesario que ser incorporados desde el inicio del proyecto. Característica difícil de determinar Es un tanto subjetiva. Toma en cuenta muchas métricas. Por ejemplo: Ejemplo: Transacciones por segundo Tiempo límite Aplicación con ventana de tiempo límite Escalabilidad Escalabilidad Vertical Añadir más recursos a un solo nodo en particular dentro de un sistema Escalabilidad Horizontal Agregar más nodos a un sistema, tal como añadir una computadora nueva a un programa de aplicación Pruebas Prueba de Carga
Pruebas de estrés
Pruebas de picos Existen 2 tipos: Ejemplos asociados Solicitud de cargas
Conexiones simultáneas
Tamaño de los datos Modificabilidad Seguridad Disponibilidad Se refiere a un nivel de servicio proporcionado por aplicaciones, servicios o sistemas. Los sistemas de alta disponibilidad tienen un tiempo de inactividad mínimo, ya sea previsto o imprevisto. (Tiempo Total Transcurrido - Tiempo de Inactividad)
_______________________________________
(Tiempo Total Transcurrido) Porcentaje de Disponibilidad = Fallas en Aplicaciones

Recuperabilidad Porcentaje de disponibilidad Día de 24 horas Día de 8 horas
90% 876 horas (36,5 días) 291,2 horas (12,13 días)
95% 438 horas (18,25 días) 145,6 horas (6,07 días)
99% 87,6 horas (3,65 días) 29,12 horas (1,21 días)
99.9% 8,76 horas 2,91 horas
99.99% 52,56 minutos 17,47 minutos
99,999% (“cinco nueves”) 5,256 minutos 1,747 minutos
99.9999% 31,536 segundos 10,483 segundos Portabilidad Testeabilidad Mantenibilidad Está relacionada con la facilidad que posee una aplicación para ser incorporada en un contexto más amplio. Conclusiones http://social.downornot.com/ El valor de dicho software puede incrementar en gran medida si su funcionalidad y/o datos pueden ser utilizados en diferentes operaciones en las que diseñador originalmente no anticipó. Facebook
Twitter
Flickr
Youtube - Es qué tan fácil o difícil se puede probar una aplicación.
- La dificultad afecta las pruebas.
- Se evalúa el nivel de cumplimiento de los
requerimientos funcionales y atributos Integración Métodos: - Pruebas Funcionales
- Pruebas De Regresión
- Pruebas De Compatibilidad
- Pruebas De Desempeño
- Pruebas De Estrés
- Pruebas de Carga
- Pruebas por Unidades De Código
- Pruebas De Usabilidad
- Pruebas De Caja Blanca Pruebas Funcionales Tienen por objetivo probar que los sistemas desarrollados cumplan con las funciones específicas para los cuales han sido creados Pruebas De Regresión Se basan principalmente en realizar pruebas sobre funcionalidades de la aplicación que presentan riesgo de haber sido afectadas por los cambios Se comprueba que el desarrollo sea compatible con todas las plataformas en las cuales el software podría llegar a ejecutarse, por ejemplo sobre los navegadores de Internet o diferentes sistemas operativos. Pruebas De Compatibilidad Pruebas de Desempeño Permiten analizar y evaluar las características del software relacionadas con el desempeño. En este tipo de pruebas se califican diferentes aspectos tales como:
- Tiempo de Respuesta: es el intervalo de tiempo que transcurre entre la solicitud de un usuario al sistema y la respuesta de este último.
- Capacidad: Máxima: cantidad de trabajo útil que se puede realizar por unidad de tiempo. Pruebas de Estrés Esta prueba se utiliza normalmente para romper la aplicación.

Determinar la solidez de la aplicación en los momentos de carga extrema

Carga real contra la carga esperada Pruebas de Carga Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones esperada. Pruebas por Unidades De Código Una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Pruebas De Usabilidad Aseguran que la aplicación está diseñada respetando consideraciones básicas de usabilidad.

- Navegabilidad
- Ergonomía Pruebas De Caja Blanca Se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente.

Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) Una Métrica de Seguridad podría definirse como el conjunto de preceptos y reglas, necesarios para poder medir de forma real el nivel de seguridad de un determinado software. Requerimientos comunes: - Autentificación
- Autorización
- Integridad
- Encriptación
- No-repudio Autentificación - Identidad de sus usuarios.
- Otras aplicaciones Autorización Autentifica los usuarios y aplicaciónes que tienen derechos definidos de acceso a los recursos del sistema. No alteración de la información Integridad Encriptación Mensajes enviados y recibidos. No-repudio El remitente del mensaje tiene una prueba de envío y el receptor se asegura de la identidad del remitente Segun el ISO/IEC 2500 los criterios de calidad se agrupan de la siguiente manera: - Qué tan fácil es realizar cambios en una aplicación para proveer nuevos requerimientos funcionales y no funcionales.
- Costo en tiempo y dinero, se conocen hasta el final.
- Los cambios pueden ser especificados previamente. Tips: Estudiar el costo de los cambios
¿Qué tan buenas son las modificaciones?
Mantener bajo acoplamiento y alta cohesión Ejemplo Capacidad para que una aplicación pueda ser ejecutada en una plataforma diferente para la que fue desarrollada. Criterios asociados: Adaptabilidad
Facilidad de instalación
Coexistencia
Facilidad de reemplazo
Cumplimiento de portabilidad Escenarios Importancia: El software se puede mover a través de una amplia gama de sistemas.
El programa trabaja con otras aplicaciones en sistemas locales o remotos.
Los usuarios requieren poco o nada de reciclaje en el programa. - Para cada escenario el impacto debe ser evaluado. Este impacto rara vez es fácil de calcular.
- Análisis de impacto de los componentes en la arquitectura.
- Finalmente basado sobre el costo, tamaño o la estimación de esfuerzos para los componentes afectados, se determina si el cambio puede hacerse.
- Consideración de un rediseño. Se encarga de medir que tan fácil una aplicación es soportada una vez que ha sido implementada. Características: Simples y fáciles de calcular.
Intuitivas.
Consistentes y objetivas.
Independientes del lenguaje de programación.
Eficaz para la retroalimentación. Sus métricas se clasifican en: Métricas de producto.
Métricas de proceso.
Métricas de proyecto. Criterios asociados: Analizabilidad.
Cambiabilidad.
Estabilidad.
Cumplimiento de mantenibilidad. Los atributos de calidad deben ser medibles y cuantificables.
Estos no se encuentran siempre en los requerimientos, se espera que los diseñadores pregunten y desarrollen los modelos contemplando estos atributos.
Debemos evaluar nuestra aplicación respecto a diferentes escenarios posibles.
La calidad no se debe pensar al final del desarrollo ya que causa esfuerzos mayores.
Full transcript