Un Fallo inminente crisis Software Tolerancia

[pic 2]

  INGENIERIA: TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

PROFESORA: NORMA ANGÉLICA ROLDÁN OROPEZA

Alumnos:

MORENO GARCÍA JOSÉ DANIEL

Entregable:

Resumen

Grado Y Grupo:

9”B”

Un Fallo inminente crisis Software Tolerancia

En la actualidad las crisis en el software es muy concurrido ver ya que muestra fallos que son claros y que pueden ser detectados con una anticipación clara.

El documento describe las dificultades en la construcción de sistemas tolerantes a fallos y describe el software retos tolerancia a fallos se enfrenta. La solución que se propone es poner especial énfasis en la ingeniería de software tolerancia a fallos que proporcionaría un conjunto de métodos, técnicas, modelos y herramientas que haría exactamente ajuste dominios de aplicación, los supuestos de falta y requisitos del sistema y apoyar la tolerancia a fallos disciplinada y rigurosa en todas las fases del ciclo de vida.

El documento termina con un esbozo de algunas direcciones de trabajo que requieren esfuerzos enfocados especiales de la comunidad de I + D. Palabras clave: tolerancia a fallos, ingeniería de software mal uso de la tolerancia de fallos Según informó Flavio Cristian en los años 80:

Muestra algunos sucesos que se encuentran sucediendo en la descripción del documentó:

• El informe provisional sobre las causas del 14 de agosto 2003 Blackout en los EE.UU. y Canadá [2] muestra claramente que el problema fue causado principalmente por la tolerancia a fallos mal diseñado: diagnósticos pobres de fallas, tiempo más largo thanestimated para la recuperación de componentes, insuficiencia de involucrar todos los componentes necesarios en la recuperación, estado del sistema inconsistente después de la recuperación, los fallos de los sistemas de alarma, etc.
• C. A. R. Hoare informa [3] que en algunos sistemas de EM más de 10% de código está dedicado a ejecutable afirmaciones. Sin embargo, como todos sabemos, muchos clientes siguen descontentos con la calidad de estos productos
• Papel  por investigadores de IBM reporta patrones típicos de manejo de mal uso y abuso de cada cinco clientes y unas aplicaciones J2EE propietarios excepción, refiriéndose a ellos como "la práctica de codificación malo". Se encontró, por ejemplo, que uno de cada diez clases traga excepciones sin hacer nada al respecto.

Seguimos cometiendo errores en el diseño de la tolerancia a fallos! La situación se está deteriorando como la complejidad del software y sistemas en general está creciendo, causando un aumento en la complejidad de la tolerancia a fallos, como los sistemas basados ​​en computadoras proliferen más ampliamente en los negocios, la sociedad y las actividades de los individuos.

En la actualidad, la tolerancia a fallos, no es digno de confianza, ya que es el menos comprendido, documentado y probado parte del sistema, se abusa con frecuencia o mal diseñado, regularmente queda hasta muy tarde en el proceso de desarrollo, no introducido típicamente en un sistemático, disciplinado o rigurosa Así, y con frecuencia no es adecuado para las situaciones específicas en las que se aplica.

La tolerancia a fallos: retos y dificultades de tolerancia de fallos significa lata y socavará la fiabilidad general del sistema si no se aplican correctamente. Los siguientes son algunos de los principales retos de la zona:

• medios de tolerancia de fallos son difíciles de desarrollar o, cuando son proporcionados por un poco de apoyo dedicado, de usar - esto es debido a que aumentan la complejidad del sistema, añadiendo una nueva dimensión al razonar sobre el comportamiento del sistema. Su aplicación requiere un profundo conocimiento de los vínculos complejos entre el comportamiento normal y anormal y estados de los sistemas y componentes, así como el estado del sistema y el comportamiento durante la recuperación.
• Tolerancia a fallos (diversidad de software, rollback, manejo de excepciones) es costoso, ya que siempre utiliza la redundancia. En lugar de mejorar la tolerancia a fallos, los desarrolladores de sistemas demasiado a menudo prefieren gastar recursos en la ampliación de la funcionalidad. No podemos y / o que no siempre quiere poner un costo a los fracasos.
• Los diseñadores de sistemas se resisten a pensar en los fallos en las primeras fases de desarrollo. Tolerancia a fallos es a menudo considerado como un problema de implementación. Por otra parte, la tolerancia a fallos es a menudo ", agregó" después de que se desarrolló la parte normal del sistema, lo que hace que sea menos eficaz, puede requerir el rediseño del sistema o dar lugar a la tolerancia a fallos defectuoso.

Es imprescindible que la tolerancia a fallos significa encaja en el sistema, los tipos de fallos (es decir, los supuestos de fallo), el dominio de aplicación, el paradigma del desarrollo, el entorno de ejecución y las características del sistema. Necesitamos abstracciones de tolerancia a fallos adecuados para una variedad de situaciones particulares.

Fallo supuestos y fallo de la aplicación tolerancia Creemos que debido a

• un aumento en la calidad de hardware y una reducción en el costo de hardware (por ejemplo, la replicación de hardware es barato)
• un aumento dramático en la complejidad del software y el volumen
• La participación de nuevos actores (usuarios no profesionales, múltiples organizaciones, infraestructuras críticas)
• una creciente complejidad del entorno en el que operan los sistemas, para muchas aplicaciones de fallos de hardware ya no son la amenaza predominante. Estas aplicaciones incluyen una amplia gama de sistemas de seguridad-, vida, negocio-y dinero-críticos - ver, por ejemplo, estudios recientes realizados por J.-C. Laprie [7], J. Knight [8] y por el Grupo Standish [9]. Los tipos predominantes de faltas a ser toleradas son
• Fallos de software de aplicación (incluyendo fallas de diseño)
• Fallas ambientales y de infraestructura / deficiencias
• Cambios potencialmente dañinos en los sistemas, componentes, entornos e infraestructuras
• Desajustes de componentes compuestos juntos (incluyendo los desajustes de los mecanismos de tolerancia a fallos [10])
• Desajustes arquitectónicos y de organización e inconsistencias systemlevel
• Degradación de los servicios proporcionados por los componentes y sistemas
• Organizacional, faltas socio-humanos y técnicos.

La tolerancia a fallos y el desarrollo de software de tolerancia de fallos deben ser diseñados de una manera disciplinada y rigurosa. De acuerdo con algunos de mis colegas que trabajan en la tolerancia a fallos, no veo la manera de avanzar en la consecución de las siguientes direcciones:

...