INGENIERÍA DE SOFTWARE II GRUPO: Capt. Rudel HuancasCapt. Rudel Huancas Pablo GuanoluisaPablo Guanoluisa Mishell ParedesMishell Paredes FIABILIDAD.

Slides:



Advertisements
Presentaciones similares
Planeamiento y diseño del producto TEMA: Planeamiento y diseño del producto Ing. Larry D. Concha B. UNIVERSIDAD AUTONOMA SAN FRANCISCO.
Advertisements

[Nombre del producto] Su logotipo Inserte la fotografía del producto.
Sistemas de Información Enfoques para la Construcción de los Sistemas de Información MBA Luis Elissondo.
Norma iso/iec TIPOS DE PRUEBA DE SOFTWARE
ESTIMACION DE PROYECTOS DE SOFTWARE La gestión de todo proyecto de software comienza con la planificación de proyecto y sus actividades. Antes de que.
Errores por el instrumento o equipo de medición pueden deberse a defectos de fabricación (dado que es imposible construir aparatos perfectos). Estos pueden.
Ciclo: VIIIMódulo: I INGENIERIA DE METODOS II Semana Nº 1 Bertha Luz, Rafael Hidalgo.
Período Septiembre 2011– Enero 2012 Prof. Román Lara C.
ENFOQUE PRÁCTICO RECOMENDADO PARA EL DISEÑO DE CASOS Integrantes del equipo: Rosa Isela Gerónimo Miguel Ángel Cruz Juan Guadalupe Alegría Humberto Mendoza.
Universidad Católica del Norte Escuela de Negocios Mineros Magister en Gestión Minera ANÁLISIS DE MANTENIBILIDAD VERSION VII MGM Antofagasta, Octubre de.
Lcdo. Eddy Cortez Sistemas II. Ingeniería de Requisitos.
ALCIBIADES VALLEJO BERRIO 2.1 INTRODUCCION 2- Requerimientos  Una de las fases más importantes en el proceso de construcción de software es la de adquisición,
Mantenimiento: Combinación de actividades mediante las cuales un equipos ó un sistema se mantiene en, o se restablece a, un estado en el que puede realizar.
La Norma ISO 25000, proporciona una guía para el uso de las series de estándares internacionales llamados requisitos y Evaluación de Calidad de Productos.
TEMA: PSP (Personal Software Process) ANALISIS DE SISTEMAS I ING. EDGAR RAUL MOLINA INTEGRAMTES: HANNSEL E. CORDON AC JESSICA IDALMY KRESS FREDERIC HESTIB.
ALUMNO: Angel Minga TEMAS: ESTÁNDARES Y PROCEDIMIENTOS PLANES Y SIMULACROS PARA LA RECUPERACIÓN EN CASO DE DESASTRE Instituto Superior Tecnológico “Daniel.
International Organization for Standardization. Organización Internacional de Normalización La ISO es una organización no gubernamental establecida el.
ESTEC GALILEO GABRIELA CIFUENTES CONTROL DE LA CALIDAD.
Teoría de Juegos Introducción Dixit & Skeath, 1,2.
Construcción de Indicadores
Evaluación de la calidad del software
TEMAS SELECTOS DE LA ENERGIA SOLAR
Paul Leger Casos de Usos Paul Leger
Sistemas de Gestión.
MANTENIMIENTO BASADO EN CONDICIONES RBI
Fundamentos de Auditoría
¿Qué es? ¿Para que se utiliza?
Mantenimiento preventivo
DISEÑO Y AUDITORIA DE SISTEMAS
U.T. 11: Introducción A Las Bases De Datos
Inserte la fotografía del producto
Administración de proyectos
Instrumentos de medición
LÍMITE DE UNA FUNCIÓN.
Especificación de Requisitos
METODOLOGÍA DE SISTEMAS
Ingeniería de Sistemas Requerimientos
PLANEAMIENTO DE LA AUDITORIA FINANCIERA
UNIVERSIDAD NACIONAL DE LOJA Área de la Educación, el Arte y la Comunicación Informática Educativa IV INGENIERIA DE SOFTWARE Taller de Análisis y Diseño.
LÍMITE DE UNA FUNCIÓN.
ADMINISTRACION DE LA PRODUCCION II 2017
Inserte la fotografía del producto
Qu é define el Plan Maestro de Producci ó n - MPS?
Mantenimiento basado en el Riesgo (Inspección basada en el Riesgo)
INSTITUTO TECNOLÓGICO SUPERIOR DE LIBRES Organismo Público Descentralizado del Gobierno del Estado de Puebla   INGENIERÍA EN SISTEMAS COMPUTACIONALES.
3.2 Etapa de definición.
PLAN DE MUESTREO.
NIAS 320 IMPORTANCIA RELATIVA.
INSTITUTO TECNOLÓGICO SUPERIOR DE LIBRES Organismo Público Descentralizado del Gobierno del Estado de Puebla   INGENIERÍA EN SISTEMAS COMPUTACIONALES.
MAESTRÍA EN GERENCIA DE SISTEMAS
Modelo de interacción de usuario.  El Desarrollo basado en modelos de la interfaz de usuario, en inglés Model-based User Interface Development (MB-UID),
CAPACITACIÓN PARA VENDEDORES
Capítulo 4 Validación del Producto y el Proceso. Características principales para validar un proceso de manufactura a través de la evaluación de una corrida.
Cover Análisis y diseño de sistemas 7. Métricas en el proceso de software personal.
LAS ETAPAS DE LA SIMULACION NUMERICA
Administración de redes
Autores: Ñauñay Colcha Jorge Luis Bravo Maldonado Paulo Dennis
UNIVERSIDAD "ALONSO DE OJEDA"
DIPLOMADO INTEGRAL DE LA CONTADURIA
Compensación reactiva Para una eficiente operación y confiabilidad de los sistemas de potencia, la potencia reactiva debe satisfacer los siguientes objetivos:
diseño de investigación
FACTORES DE RIESGO # de Enero de 2015 Recuerda: MUY PRONTO INICIAREMOS CON EL LEVANTAMIENTO DE LOS ANÁLISIS DE RIESGO DE NUESTRAS OPERACIONES ¿Que.
ASIGNATURA: REINGENIERÍA DEL SOFTWARE CUATRIMESTRE: I DOCENTE: ING. IRENE MARTÍNEZ MEJÍA CORREO: Managua, 26 de Enero 2019
CRITICIDAD.
NORMA ISO/IEC 9126 Norma publicada en Usada para la evaluación de la calidad de software. Establece las características de calidad para productos.
TEORIA de ERRORES. Generalidades:  Una “discrepancia" es la diferencia entre dos valores medidos de la misma cantidad.-  La “precisión” se refiere al.
Desarrollo de sistemas
PRUEBAS DE CAJA NEGRA. -Internationa Software Testing Qualification Board (ISTQB) Internationa Software Testing Qualification Board (ISTQB) Técnica de.
LA EVIDENCIA 1 Enlace:
ANÁLISIS DE ALIMENTOS I. MILITARY STANDART. MUESTREO POR ACEPATACIÓN
Transcripción de la presentación:

INGENIERÍA DE SOFTWARE II GRUPO: Capt. Rudel HuancasCapt. Rudel Huancas Pablo GuanoluisaPablo Guanoluisa Mishell ParedesMishell Paredes FIABILIDAD

DEFINICIÓN DE FIABILIDAD Capacidad del software de mantener las prestaciones requeridas del sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.

SUB CARACTERÍSTICAS:  Madurez. - Se debe verificar las fallas del sistema y si muchas de estas han sido eliminadas durante el tiempo de pruebas o uso del sistema.  Recuperabilidad.- Verificar si el software puede reasumir el funcionamiento y restaurar datos perdidos después de un fallo ocasional.  Tolerancia a fallos.- Evalúa si la aplicación desarrollada es capaz de manejar errores.  Conformidad de la fiabilidad: La capacidad del software de cumplir a los estándares o normas relacionadas a la fiabilidad.

SUB CARACTERÍSTICAS: La calidad del software se evalúa teniendo en cuenta la etapa del desarrollo, se deben fijar las metas de la calidad tanto para el software final como para desarrollos incompletos y tener en cuenta que es imposible que las metas y criterios sean iguales para un software pequeño y un gran software empresarial.

MÉTRICAS MÉTRICAEXPLICACIÓN Probabilidad de fallos en la petición La probabilidad de que el sistema falle cuando se solicite una petición de servicio. PODFOD de 0,001 significa que una de cada peticiones de servicio conduce a un fallo. Tasa de ocurrencia de fallos La frecuencia de ocurrencia con la que es probable que ocurra un comportamiento inesperado. Un ROCF de 2/100 significa que es probable que ocurran dos fallos a cada 100 unidades de tiempo de funcionamiento. Esta métrica se conoce algunas veces como la intensidad de fallos. Tiempo medio entre fallos El tiempo medio entre fallos de sistemas observados. Un MTTF de 500 significa que puede esperarse un fallo cada 500 unidades de tiempo. Disponibilidad La probabilidad de que el sistema esté disponible para su utilización en un momento determinado. Una disponibilidad de 0,998 significa que el sistema es probable que esté disponible durante 998 de cada 1000 unidades de tiempo.

PROBABILIDAD DE FALLOS EN LA PETICIÓN.  Esta métrica es la mas adecuada para sistemas en lo que los servicios se demanda a intervalos de tiempo impredecibles o relativamente largos y en los que existen serias consecuencias si el servicio pedido no se proporciona. Se podría utilizar para especificar sistemas de protección como la fiabilidad de un sistema de liberación de presión en una planta química o el sistema de apagado de emergencia en una planta de energía.

TASA DE OCURRENCIA DE FALLOS  Esta métrica debería utilizarse en donde se hagan peticiones regulares de los servicios del sistema y en donde sea importante que estos servicios se proporcionen correctamente. Debería utilizarse en la especificación de un sistema de cajero automático que procesa transacciones de clientes o en un sistema de reservas de hoteles.

TIEMPO MEDIO ENTRE FALLOS.  Esta métrica debería utilizarse en sistemas con transacciones largas; esto es, en donde la gente utiliza el sistema durante largos periodos de tiempo. El MTTF debería ser mayor que la longitud media de cada transacción.

DISPONIBILIDAD.  Esta métrica debería utilizarse en sistemas que no se detienen y en los que los usuarios esperan que el sistema proporcione un servicio continuado. Ejemplos de tales sistemas son los sistemas de centralita telefónica y sistemas de señalización ferroviaria.

MEDICIONES  Hay tres tipos de mediciones que pueden realizarse cuando se valora la fiabilidad de un sistema: 1. El número de fallos del sistema dado un número de peticiones de servicios del sistema. Se usa para medir el POFOD. 2. El tiempo (o número de transacciones) transcurrido entre fallos del sistema. Se utiliza para medir el ROCOF y el MTTF 3. El tiempo consumido en reparar o reiniciar el sistema cuando ocurre un fallo. que el sistema debe estar disponible continuamente, éste se utiliza para medir el AVAIL  Las unidades tiempo que se pueden utilizar en estas métricas son fechas de calendario, tiempo de procesador o algunas unidades discretas, como por ejemplo el número de transacciones.

CONCLUSIONES  La elección de qué métrica debería utilizarse depende del tipo de sistema sobre el que se aplica y de los requerimientos del dominio de la aplicación.  La utilización de métricas en la fiabilidad del sistema nos permite darle madurez a este para obtener una cobertura adecuada de los fallos y pruebas que se le han realizado.  La fiabilidad de los sistemas debería especificarse como un requerimiento no funcional el cual se exprese de forma cuantitativa utilizando una de las métricas definidas anteriormente.

RECOMENDACIONES  Utilizar las métricas adecuadas para evaluar el sistema con el fin de no tener especificaciones de fiabilidad subjetivas y no formales.  Es necesario y cada vez más importante añadir estos procesos de cálculo de fiabilidad del software y poco a poco se va engranando dentro del proceso normal de desarrollo de software con un ciclo más.