ERROR DE SOFTWARE

Foto del origen de la leyenda acerca del primer "bug" informático conocido

Un defecto de software (software bug en inglés), es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software). Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Los errores pueden suceder en cualquier etapa de la creación de software.

En 1947, los creadores de Mark II informaron del primer caso de error en un ordenador causado por un bug. El Mark II, ordenador sucesor de ASCC Mark I, construido en 1944, sufrió un fallo en un relé electromagnético. Cuando se investigó ese relé, se encontró una polilla que provocó que el relé quedase abierto.

Grace Murray Hopper, licenciada en Física y destacada matemática que trabajó como programadora en el Mark II, pegó el insecto con cinta adhesiva en la bitácora (imagen) y se refirió a ella como "bicho" para describir la causa del problema.

Este incidente es erróneamente conocido por algunos como el origen de la utilización del término inglés "bug" (bicho) para indicar un problema en un aparato o sistema.1 2 En realidad, Thomas Alva Edison ya había utilizado "bug" en algunas anotaciones relacionadas con interferencias y mal funcionamiento. Grace lo asoció por primera vez a la informática, en este caso, relacionado a un insecto real. No obstante, durante los años 50 del Siglo XX, Grace también empleó el término "debug" al hablar de la depuración de errores en los códigos de programación.

Los programas que ayudan a detección y eliminación de errores de programación de software son denominados depuradores (debuggers).

Defectos de diseño de programas

Diseños con colores inapropiados para las personas que padecen daltonismo.

Diseños que usan textos con tipografías de difícil lectura por su tamaño o diseño.

Diseños que fuerzan el uso del ratón o mouse sin dejar alternativas de teclado para personas con disfunciones motrices.

Diseños con implicaciones culturales, por ejemplo usando partes del cuerpo que en una determinada cultura sean objeto de vergüenza o burla o símbolos con características de identidad cultural o religiosa.

Estimar que el equipo donde se instalará tiene determinadas características (como la resolución de la pantalla, la velocidad del procesador, la cantidad de memoria o conectividad a internet) propias de un equipo de gama alta, en vez de diseñar el software para su ejecución en equipos.

Errores de programación comunes

División por cero Ciclo infinito Problemas aritméticos como desbordamientos (overflow) o

subdesbordamientos (underflow). Exceder el tamaño del array. Utilizar una variable no inicializada. Acceder a memoria no permitida (access violation). Pérdida de memoria (memory leak). Desbordamiento o subdesbordamiento de la pila (estructura de datos). Desbordamiento de búfer (buffer overflow). Bloqueo mutuo (deadlock). Indizado inadecuado de tablas en bases de datos.

Defectos de instalación o programación

Eliminación o sustitución de bibliotecas comunes a más de un programa o del sistema (DLL Hell).

Reiniciar arbitrariamente la sesión de un usuario para que la instalación tenga efecto.

Presuponer que el usuario tiene una conexión permanente a internet. Utilizar como fuente de datos enlaces simbólicos a ficheros que pueden

cambiar de ubicación.

Códigos de errores de lenguajes de programación

La mayor parte de los lenguajes de programación presentan al menos dos tipos de errores que permiten a los programadores manejar las fallas de los programas de

una manera eficiente y que no resulte agresiva con el usuario final. Dichos errores son de compilación y errores en tiempo de ejecución.

Los errores de compilación normalmente inhiben que el código fuente derive en un programa ejecutable, mientras que los errores en tiempo de ejecución son situaciones específicas en las que un evento externo al programa impide su ejecución. Regularmente un programador eficiente debe intentar imaginar cómo debe responder ante esos eventos de manera que sea el programa y no el usuario o el sistema operativo los que resuelvan el problema. Así por ejemplo un bloque de error no manejado podría hacer lo siguiente:

Abre el archivo "miarchivo" para escritura comienza a escribir datos en mi archivo cierra el archivo

Si "miarchivo" no existe (o el programa o el usuario no tienen privilegios suficientes para abrirlo), el sistema operativo regresará un error que el programa no atrapará y tendremos un mensaje como "El archivo "miarchivo" no puede ser abierto para escritura" y botones para reintentar, cancelar y abortar (en el sistema operativo Windows), que no tendrán otra acción que repetirse indefinidamente sin posibilidad de salir de ese ciclo como no sea dando por terminado violentamente el programa. Un código que permitiese atrapar el error en tiempo de ejecución sería:

Abre el archivo "miarchivo" para escritura Si el sistema operativo lo permite comienza a escribir datos en "miarchivo" si no lo permitió informa al usuario de lo que sucede regresa al usuario a un punto donde no haya conflicto (el menú principal, por ejemplo) Continúa operando normalmente

Los diferentes lenguajes de programación permiten diferentes construcciones lógicas a los programadores para atrapar y resolver errores en tiempo de ejecución, como pueden ser las sentencias assert, try y on error en diferentes lenguajes de programación.

MINISTERIO DE EDUCACIÓN

INSTITUTO PROFESIONAL Y TÉCNICO NOCTURNO DE COLÓN

BACHILLER EN REPARACIÓN DE COMPUTADORAS

MANEJO DE RECURSO INFORMÁTICO

EJERCICIO # 1

NOMBRE: FACILITADOR: PROF. PEDRO E. FRÍAS

CÉDULA: VALOR: 20 pts.

FECHA: EVALUACIÓN:

I. Realice el siguiente Pareo. Valor: 10 pts.

1. Bug ____ Desbordamiento.

2. Software ____ Pérdida de Memoria.

3. Grace M. Hopper ____ Subdesbordamiento.

4. Bug ____ Bloqueo mutuo.

5. Debug ____ Bicho.

6. Debuggers ____ Fallo o deficiencia.

7. Overflow ____ Programas de ordenador o computador.

8. Underflow ____ Depuradores.

9. Memory leak ____ Pegó el insecto en la bitácora (imagen).

10. Deadlock ____ depurador de errores en los códigos.

II. Llene los siguientes espacios con el término correcto. Valor: 10 pts.

1. Un ___________________, es el resultado de un fallo o deficiencia

durante el proceso de creación de programas de ordenador o

computadora (software).

2. _______________________, licenciada en Física, pegó el insecto

con cinta adhesiva en la bitácora (imagen) y se refirió a ella como

"bicho" para describir la causa del problema.

3. Grace también empleó el término _________________al hablar de la

depuración de errores en los códigos de programación.

4. Los programas que ayudan a detección y eliminación de errores de

programación de software son denominados depuradores

__________________________.

5. “buffer Overflow” en español significa ________________________.

“Solo se eleva la voz cuando se acaban las ideas”

¡BUENA SUERTE!

ALGUNOS ERRORES FRECUENTES EN WINDOWS

* STOP 0x0000000A (IRQL_NOT_LESS_OR_EQUAL)

CAUSA: Drivers incompatibles o mal hechos

EXPLICACIÓN: Este error indica que un proceso en modo kernel o un driver ha intentado acceder a una

dirección de memoria para la que no tiene permisos. Se suele producir porque en el código hay un puntero

que hace referencia a una parte de la memoria que no corresponde al proceso. Esto provoca una violación de

la separación de procesos en Windows y una parada para evitar que se sobrescriba código o datos de otro

proceso.

* STOP 0x0000001E (KMODE_EXCEPTION_NOT_HANDLED

CAUSA: Drivers incompatibles o mal hechos, software con fallos graves, hardware defectuoso.

EXPLICACIÓN: El manejador de excepciones del kernel ha detectado que un proceso ha intentando

ejecutar una instrucción inválida.

* STOP 0x00000024 (NTFS_FILE_SYSTEM)

CAUSA: Disco duro dañado, cables en mal estado, sistema de ficheros dañado

EXPLICACIÓN: Windows no puede acceder a la partición NTFS donde están sus ficheros

* STOP 0x00000023 ó 0x00000024 (FAT_FILE_SYSTEM o NTFS_FILE_SYSTEM)

CAUSA: Error en Ntfs.sys (el archivo de controlador que permite al sistema leer y escribir en unidades

NTFS).

Para solucionar el error grave 0x00000023 ó 0x00000024:

Ejecute el software de diagnóstico del sistema proporcionado por el fabricante del equipo, especialmente el

diagnóstico de hardware.

Deshabilite o desinstale cualquier programa antivirus, de desfragmentación de disco o de copia de seguridad.

Ejecute Chkdsk /f en el símbolo del sistema para comprobar que el disco duro no está dañado y, a

continuación, reinicie el equipo.

* STOP 0x00000050 (PAGE_FAULT_IN_NONPAGED_AREA)

CAUSA: Drivers incompatibles, software incompatible, RAM defectuosa, placa o tarjeta defectuosas

EXPLICACIÓN: Un driver o programa ha solicitado una página de una dirección de memoria inválida.

Para solucionar el error grave 0x00000050:

Quite cualquier componente de hardware (memoria RAM, adaptadores, discos duros, módems, etc.) que haya

instalado recientemente.

Ejecute el software de diagnósticos del sistema que le haya proporcionado el fabricante del equipo,

especialmente la comprobación de memoria.

Compruebe si el hardware o el software nuevo está instalado correctamente. Si se trata de una nueva

instalación, póngase en contacto con el fabricante del hardware o del software para obtener las actualizaciones

o los controladores de Windows 2000 necesarios.

Si el equipo tiene formato NTFS, reinícielo y, a continuación, ejecute Chkdsk /f /r en la partición de sistema.

Si no puede iniciar el sistema debido al error, utilice la Consola de comandos y ejecute Chkdsk /r.

Deshabilite o desinstale cualquier programa antivirus.

Deshabilite las opciones de memoria del BIOS, como caché o vigilancia.

* STOP 0x0000003F (NO_MORE_SYSTEM_PTES)

CAUSA: Un controlador no se está liberando correctamente.

Para solucionar el error grave 0x0000003F:

Deshabilite o desinstale cualquier programa antivirus, de desfragmentación de disco o de copia de seguridad.

* STOP 0x00000077 (KERNEL_STACK_INPAGE_ERROR)

CAUSA: Sector defectuoso en el archivo de intercambio, cables IDE defectuosos, virus

EXPLICACIÓN: Una página de memoria solicitada por el kernel no ha podido ser leída del fichero de

intercambio a la RAM.

Para solucionar el error grave 0x00000077:

Analice su equipo en busca de virus con una versión actualizada de su software antivirus. Si encuentra un

virus, lleve a cabo los pasos necesarios para eliminarlo del equipo. Para ello, consulte la documentación del

software antivirus.

Si el equipo tiene formato NTFS, reinícielo y, a continuación, ejecute Chkdsk /f /r en la partición de sistema.

Si no puede iniciar el sistema debido al error, utilice la Consola de comandos y ejecute Chkdsk /r.

Ejecute el software de diagnósticos del sistema que le haya proporcionado el fabricante del equipo,

especialmente la comprobación de memoria.

Deshabilite las opciones de memoria del BIOS, como caché o vigilancia.

* STOP 0x0000007B (INACCESSIBLE_BOOT_DEVICE)

CAUSA: Cambio de placa o controladora, cambio de disco a otro PC, virus

EXPLICACIÓN: Windows no puede encontrar la partición donde están sus ficheros. Es una situación

parecida a la del error 0x000000ED

Para solucionar el error grave 0x0000007B:

- Con frecuencia, este error se debe a un virus en el sector de inicio. Analice su equipo en busca de virus con

una versión actualizada de su software antivirus. Si encuentra un virus, lleve a cabo los pasos necesarios para

eliminarlo del equipo. Para ello, consulte la documentación del software antivirus.

- Quite cualquier componente de hardware (memoria RAM, adaptadores, discos duros, módems, etc.) que

haya instalado recientemente.

- Compruebe la Lista de compatibilidad de hardware (HCL) de Microsoft para asegurarse de que todo el

hardware y los controladores son compatibles con Windows 2000.

Para ver la versión más reciente de la lista HCL, visite el sitio Web de Microsoft:

http://www.microsoft.com/hcl/

-Si está utilizando un adaptador SCSI, pida al fabricante de hardware el controlador más reciente para

Windows 2000, deshabilite la negociación de sincronización del dispositivo SCSI, compruebe que la cadena

SCSI está terminada y compruebe los Id. SCSI de los dispositivos. Si no sabe con seguridad cómo realizar

alguno de estos pasos, consulte la documentación del dispositivo.

-Si está utilizando dispositivos IDE, defina el puerto IDE de la placa como Sólo principal (Primary only).

- Compruebe la configuración de Maestro, Esclavo y Único de los dispositivos IDE. Quite todos los

dispositivos IDE excepto el disco duro. Si no sabe con seguridad cómo realizar alguno de estos pasos,

consulte la documentación del hardware.

-Si el equipo tiene formato NTFS, reinícielo y, a continuación, ejecute Chkdsk /f /r en la partición de sistema.

Si no puede iniciar el sistema debido al error, utilice la Consola de comandos y ejecute Chkdsk /r.

Ejecute Chkdsk /f para determinar si el sistema de archivos está dañado. Si Windows 2000 no puede ejecutar

Chkdsk, mueva la unidad a otro equipo que ejecute Windows 2000 y ejecute el comando Chkdsk en la unidad

de ese equipo.

* STOP 0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED)

CAUSA: Drivers o software incompatibles, BIOS incompatible, hardware incompatible

EXPLICACIÓN: Un proceso del sistema ha generado una excepción que no ha sido procesada por el

manejador de excepciones.

Si el error se produce al conectar un dispositivo USB, es porque el bus USB está siendo utilizado al 100% ya.

Conectar ese dispositivo en otra controladora USB o parar el otro dispositivo antes de conectar el nuevo.

Si el error es en Kbdclass.sys, es provocado por la utilidad Logitech iTouch. Bajar la última versión

dehttp://www.logitech.com.

* TOP 0x0000007F (UNEXPECTED_KERNEL_MODE_TRAP)

CAUSA: Hardware defectuoso, normalmente RAM o placa base, software incompatible

EXPLICACIÓN: Un proceso del kernel o un driver se ha encontrado que no hay suficiente espacio en el

stack para efectuar la operación que pretendía.

Una de las causas más frecuentes es Norton Antivirus (ver información oficial de Symantecaquí)

Para solucionar el error grave 0x0000007F:

Compruebe la Lista de compatibilidad de hardware (HCL) de Microsoft para ver que el hardware y los

controladores que tiene instalados son compatibles con Windows 2000. Es posible que el problema se deba a

una incompatibilidad con la placa base del equipo.

Para ver la versión más reciente de la lista HCL, visite el sitio Web de Microsoft:

http://www.microsoft.com/hcl/

Quite cualquier componente de hardware (memoria RAM, adaptadores, discos duros, módems, etc.) que haya

instalado recientemente.

Ejecute el software de diagnósticos del sistema que le haya proporcionado el fabricante del equipo,

especialmente la comprobación de memoria.

Deshabilite las opciones de memoria del BIOS, como caché o vigilancia.

* STOP 0x0000008E (KERNEL_MODE_EXCEPTION_NOT_HANDLED)

CAUSA: Hardware, drivers o BIOS incompatible. Lo más habitual es RAM defectuosa o drivers de nvidia.

EXPLICACIÓN: Un proceso del kernel ha producido una excepción no procesada por el manejador de

excepciones. Es similar al error 0x0000007F.

* STOP 0x0000009F (DRIVER_POWER_STATE_FAILURE)

CAUSA: Driver que no funciona correctamente con las funciones de ahorro de energía

Para solucionar el error grave 0x0000009F:

Deshabilite el controlador identificado en el mensaje de detención o cualquier otro controlador instalado

recientemente.

Actualice cualquier software que utilice controladores de filtro, por ejemplo, programas antivirus o de copia

de seguridad.

Para confirmar si su hardware está diseñado para usarlo con la familia Windows Server 2003, haga clic en el

vínculo correspondiente en Recursos de soporte.

Si el equipo no se inicia correctamente, trate de iniciarlo con la Última configuración válida conocida o en el

Modo a prueba de errores y, a continuación, quite o deshabilite los programas o controladores agregados

recientemente. Para obtener información sobre cómo iniciar el equipo en el Modo a prueba de errores, vea

Iniciar el equipo en modo a prueba de errores. Para obtener más información acerca de cómo iniciar el equipo

con Última configuración válida conocida, vea Iniciar el equipo con la última configuración válida conocida.

Importante

- Si utiliza Última configuración válida conocida, se perderán los cambios en la configuración del sistema que

se hicieran después de iniciarlo correctamente por última vez.

Nota

- Busque información actualizada acerca de este mensaje de detención en el sitio Web de Microsoft. Para ello,

vaya al sitio Web de Microsoft, haga clic en una opción de búsqueda y siga las instrucciones que aparecen en

la página. Al escribir las palabras clave, utilice stop 0x0000009F.

Para obtener más información acerca de artículos, asistentes para la solución de problemas y elementos que

puede descargar, vea Información técnica actualizada.

* STOP 0x000000C2 (BAD_POOL_CALLER)

CAUSA: Driver o software mal hecho

* STOP 0x000000D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL)

CAUSA: Driver mal hecho

EXPLICACIÓN: La causa es la misma que la del error 0x0000000A, pero en esta ocasión se sabe seguro

que es un driver.

* STOP 0x000000EA (THREAD_STUCK_IN_DEVICE_DRIVER)

CAUSA: Driver, típicamente el de la tarjeta gráfica, mal hecho

EXPLICACIÓN: El driver ha entrado en un ciclo sin fin, repitiendo las mismas instrucciones una y otra vez.

* STOP 0x000000ED (UNMOUNTABLE_BOOT_VOLUME)

CAUSA: Cambio de placa o controladora, cables IDE defectuosos o inadecuados, cambios en la conexión de

los discos

EXPLICACIÓN: Windows no puede acceder a la partición donde están sus ficheros

* STOP 0xC0000218 (UNKNOWN_HARD_ERROR)

CAUSA: Ficheros del registro dañados o borrados, RAM defectuosa

EXPLICACIÓN: Windows no puede cargar los ficheros del registro porque faltan o están dañados

* STOP 0xC000021A (STATUS_SYSTEM_PROCESS_TERMINATED)

CAUSA: Software o drivers incompatibles

EXPLICACIÓN: Un subsistema en modo usuario (WinLogon o CSRSS por ejemplo) ha tenido un error

grave.

* STOP 0xC0000221 (STATUS_IMAGE_CHECKSUM_MISMATCH)

CAUSAS: Ficheros modificados, errores en el acceso al disco, RAM defectuosa

EXPLICACIÓN: Para comprobar que los ficheros que se cargan al iniciar Windows no han sido

modificados, se calcula un checksum en el momento de cargarlos y se compara con el que hay almacenado. Si

no son iguales, se genera este error.

* STOP 0x0000009C (0x00000004, 0x00000000, 0xb2000000, 0x00020151)...

(MACHINE_CHECK_EXCEPTION)

CAUSAS: Este comportamiento se debe a que el procesador del equipo ha detectado un error de hardware

irrecuperable y ha informado de él a Windows XP. Para ello, ha empleado la característica Excepción de

comprobación de equipo (MCE, Machine Check Exception) de los procesadores Pentium o la característica

Arquitectura de comprobación de equipo (MCA, Machine Check Architecture) de algunos procesadores

Pentium Pro.

Este error puede ser consecuencia de lo siguiente:

• Errores de bus del sistema.

• Errores de memoria que pueden incluir problemas de paridad o de Código de corrección de errores (ECC,

Error Correction Code).

• Errores de caché en el procesador o en el hardware.

• Errores de los Búferes de traducción de direcciones (TLB, Translation Lookaside Buffer) en el procesador.

• Otros problemas de hardware detectados específicos del proveedor de la CPU.

• Problemas de hardware detectados específicos del proveedor.

EXPLICACIÓN: Una excepción de comprobación del equipo se produce cuando Windows XP y la

plataforma de hardware no pueden recuperarse de algún tipo de error de hardware, por lo que el sistema no

puede seguir funcionando correctamente o de forma fiable. El diagnóstico específico de las excepciones de

comprobación del equipo es difícil y no existe una solución general. Póngase en contacto con el fabricante o

con un técnico de hardware a fin de obtener ayuda para la solución de este problema.

Las excepciones de comprobación de equipo suelen deberse a una de las situaciones siguientes:

• El procesador o la placa base funcionan más allá de lo que permiten sus especificaciones. Por ejemplo, el

procesador o el bus están sobreutilizados. Microsoft recomienda que el hardware funcione a la velocidad

indicada por el fabricante.

• Los ruidos en el sistema de alimentación, la sobrecarga de las conexiones eléctricas, un suministro de

alimentación excesivo o los cortes en el suministro eléctrico pueden desestabilizar el equipo. Asegúrese de

que el equipo disponga de un sistema de alimentación estable y fiable.

• Condiciones de temperaturas extremas debidas al mal funcionamiento de los dispositivos de ventilación.

Asegúrese de que los dispositivos de ventilación funcionen.

• Daños en la memoria o un tipo de memoria que no es el adecuado para el equipo. Si cambió recientemente

la configuración de la memoria, vuelva a la configuración anterior para determinar si ésta es la causa del

error. Asegúrese de utilizar la memoria adecuada para el equipo.

NOTA: el hardware puede admitir características de registro de errores adicionales que capturan excepciones

de comprobación de equipo y sugieren una solución más específica.

Los procesadores Pentium y Pentium Pro disponen de un mecanismo que detecta y crea informes sobre

problemas relacionados con el hardware, como errores de paridad de memoria y errores de caché. Para señalar

un error de hardware, el procesador genera una excepción de comprobación de equipo (Interrupción 18) a fin

de informar de la detección de un error de comprobación de equipo. Windows XP informa de que se ha

producido el error y muestra los parámetros que pueden utilizarse para descodificar la excepción.

Póngase en contacto con el proveedor del hardware o con el fabricante del procesador para obtener

información acerca de la Arquitectura de comprobación de equipo o consulte Intel Pentium Pro Family

Developer"s Manual - Volume 3: Operating System Writer"s Manual.

SXE INJECTED - ERRORES FRECUENTES Y SOLUCIONES

Error: [C:\Archivos de programa\StrikeC\Mss32.dll] -> Incorrect version

[ba2b3f10b8997299e96a176c9b5d5f96](BLOCKED)

Descripcion: Esta no es una dll original

Solucion: reemplazar con la original o reinstalar el Half Life (Counter Strike, Day of Defeat, etc)

Error: Error:[ SYSENTER / Int2E ALTERED [0x804DE6F0][0xB78A8AD0]

[\WINDOWS\system32\TUKERNEL.EXE] ]

Descripción: sXe Injected tiene problemas con los boot screens

Solución: Eliminar TUKERNEL.EXE y reiniciar

Error: ERROR: [(\SystemRoot\system32\drivers\HBKernel.sys). (sXe Injected

subsystem altered 2[35])]

Descripción: HBKernel.sys es un virus que hookea el kernel e intenta desactivar al sXe Injected

Solución: Remover el virus con un antivirus o antispyware (googleen para encontrar la mejor

solución)

Error: - ERROR: [(Dirty). (sXe Injected subsystem altered 2[XXX])]

Descripción: Otra aplicación intento desactivar al sXe Injected

Solución: En la mayoría de los casos esto se debe a un malware, se soluciona corriendo un buen

antispyware o antivirus para remover el malware en cuestión. En otros casos se debe a una

incompatibilidad de software, si se da esto la unica solución es encontrar el software en cuestión y

reportarmelo para intentar encontrar una solución(info@sxe-injected.com.ar)

Error: - [D:\Juegos\SIERRA\Half-Life\hl.exe] -> Incorrect version

[a6873754f9be227d28514a8b188c3935](BLOCKED)

Error: - [D:\Games\Counter-Strike\cstrike.exe] -> Incorrect version

[1604114ef0abc105386b461c80627275](BLOCKED)

Error: - [C:\Archivos de programa\Valve\hl.exe] -> Incorrect version

[8f33bcf8c28725796f63884df77eda6b](BLOCKED)

Descripción: Este error se da con versiones de Counter Strike (Day of Defeat, etc) que el sXe

Injected no conoce

Solución: La solucion es simplemente instalar otra version. En otros casos se debe a que un virus

modifico el cstrike.exe (hl.exe, Day Of Defeat.exe, etc) por lo tanto la solucion es eliminar el virus y

reinstalar el juego

Error: - [C:\Archivos de programa\Counter-Strike 1.6\cstrike\dlls\mp.dll] -> Incorrect

version [b23185bea98fe01f86e85da1c4f75dce](BLOCKED)

Descripción: mp.dll es usada para crear listener servers, cuando se ejecuta el juego esta dll no es

cargada, pero algunas veces, no se porque razon, el juego intenta cargarla, como el sXe Injected

no la conoce se cierra a si mismo.

Solución: Cerrar el juego y ejecutar nuevamente el sXe Injected y el juego.

Error: -

Error:[[00d](f7ba3318)[124](f7ba3560)[17f](f7ba3854)[1a0](f7ba38f0)[1f6](f7ba3c8

8)[225](f7ba3b0c)[23a](f7ba3bf4)]

Descripción: Esto se debe a una incompatibilidad de software.

Solución: Ninguna. Reportar el error, todos los programas instalados en la pc y esperar una

solución (info@sxe-injected.com.ar). Los programas instalados deben ser reportados con el log del

HiJackThis (HijackThis Logfileauswertung)

Error: - ERROR: [(\WINDOWS\system32\ntkrnlpa.exe)(sXe Injected subsystem

altered 2)]

Error: - ERROR: [ SYSENTER / Int2E ALTERED [0x804DE6F0][0xB92494B0]

[\WINDOWS\system32\SINGKRNL.EXE] ]

Descripción: Alguna clase de incompatibilidad

Solución: Ninguna. Reportar la versión exacta de windows instalada (info@sxe-injected.com.ar)

Error: - * Game Altered, remove modifications * (###) [######]

Descripción: La version de los mapas/modelos/sprites difiere de los originales del juego.

Solución: Copiar los archivos originales o reinstalar el Counter Strike

Error: - * Game Altered, remove modifications * (map) [gas_puff_01.spr]

Descripcion: El sprite instalado no coincide con el original.

Solucion: Copiar el original o reinstalar el Counter Strike.

Error: - * Game Altered, remove modifications * (b) [30]

Descripción: Algunas aplicaciones para medir FPS's modifican funciones de OpenGl. Estas

modificaciones no pueden diferenciarse de las modificaciones realizadas por un cheat.

Solución:Desinstalar la aplicación (una aplicacion conocida es FRAPS)

Error: - GetLastError(87)(El parámetro no es correcto.)

Descripción: Windows posee una lista finita de aplicaciones que pueden suscribirse a la creación

de procesos, esta lista posee solo 8 posiciones, el sXe Injected consume una, cuando la lista esta

completa el sXe Injected no puede subscribirse y por lo tanto finaliza su ejecución.

Solución:En la mayoría de los casos al desinstalar las aplicaciones (como el Norton 2008) estas no

eliminan el 100% de sus drivers, por lo cual quedan cargados sin hacer nada. La solución es

encontrar estos drivers y eliminarlos. La lista de drivers se puede encontrar con aplicaciones como

Deep System Explorer (Account Suspended) una vez encontrados pueden eliminarse con Autoruns

(www.sysinternals.com) en el tab de "Drivers". NOTA: sean cuidadosos!

Ejemplo:

Error: GetLastError(1275)(Se ha bloqueado la descarga de este controlador)

Descripción: Alguna aplicación está bloqueando la carga del driver del sXe Injected, otra razon es

que Windows sea de 64 bits

Solución: Encontrar la aplicación (antivirus, anti-rootkit, etc) y darle permisos al sXe Injected para

cargar drivers. Si están corriendo en Windows de 64 bits no hay nada que puedan hacer al

respecto.

ERRORES DE SOFTWARE Y SUS CONSECUENCIAS

La certificación de la calidad de los diferentes productos siempre ha sido una preocupación universal, el proveer al usuario de un producto de calidad es un asunto de suma importancia para garantizar el éxito de las empresas. Para garantizar el acercamiento al consumidor, las empresas suelen recurrir a grandes campañas de marketing que les permitan fijar en el consumidor la imagen de su producto. Este modelo generalmente no es aplicado por las

ciber-empresas tipo web 2.0”, estas no acuden a las clásicas campañas de marketing agresivo, en su lugar permiten que la calidad de sus productos atraiga a sus clientes por el efecto boca a boca, confían en que un cliente satisfecho atrae más clientes, y que la mejor campaña de marketing es el beneplácito del cliente al usar un producto de alta calidad.

La Ingeniería del Software persigue como objetivo esencial el proporcionar las herramientas fundamentales para la producción de software de alta calidad, sin embargo, este es un punto básicamente imposible de lograr en un 100% debido a la complejidad inherente al software y la imposibilidad práctica de realizar una prueba exhaustiva sobre el mismo. Una prueba total para un software requeriría el recorrido de un árbol infinito de opciones compuesto por todas las posibles secuencias de operaciones que un usuario puede realizar sobre el aplicativo.

El mantener un nivel adecuado de prestaciones del aplicativo se hace imperante cuando del correcto funcionamiento del producto dependen las vidas de seres humanos, aplicativos dedicados al soporte de la vida humana como los controladores de incubadoras o maquinas de diálisis, deben cumplir con altos niveles de calidad y garantizar su corrección, de igual manera sucede con los aplicativos creados para proyectos con grandes inversiones investigativas, sociales y económicas.

Desafortunadamente, la incorrecta validación de los criterios de calidad en los aplicativos software a conducido a través de la historia a grandes desastres, he aquí algunos ejemplos.

Therac 25

Instrumental médico de aplicación de radiación. Por lo menos 5 personas murieron por una incorrección en las validaciones de entrada de su interface grafica.

Nasa

El Orbitador climatológico de Marte y el Mars Polar Lander son solo 2 de las muy costosas misiones de la NASA que fracasaron a causa de errores software. Generalmente las misiones de este nivel pueden costar cientos de millones de dólares y varios años de investigación. Sin embargo en la actualidad la NASA trabaja en la construcción de software que le permita validar automáticamente el funcionamiento de sus aplicativos. Una interesante aplicación a nivel de SQA. (Software Quality Assurance).

Ariane 5

El 4 de junio de 1996 la ESA (Agencia Espacia Europea) reutilizó el software de su predecesor el Ariane 4 para el montaje de su nave el Ariane 5, la conversión de un valor de 64 bits a uno de 16 bits causó un desbordamiento que terminó con la desintegración de la nave 40 segundos después de su despegue.

División de coma flotante en Intel Pentium

En 1993 en la intrincada carrera entre empresas productoras de

microprocesadores, Intel sacó al mercado un procesador con un error en la

unidad de punto flotante, al descubrir el error se hizo necesario recoger toda la

producción entregada y reemplazarla por procesadores no defectuosos. Esta

operación tuvo un costo de 475 millones de dólares.

LOS 25 ERRORES DE SOFTWARE MÁS PELIGROSOS

El CWE (Common Weakness Ennumeration) y el SANS Institute, dos organizaciones

dedicadas a la seguridad informática, han publicado una lista con los 25 errores de

software más comunes y peligrosos. Estos fallos permiten que los atacantes afecten a los

usuarios, por ejemplo, robándoles datos o haciendo que los programas no funcionen.

Estos errores, explican en CWE, “son normalmente fáciles de encontrar y fáciles de

explotar”. Además, son peligrosos “porque permitirán frecuentemente que los atacantes

controlen por completo el software, roben datos o impidan que el software funcione en

absoluto”. En algunos casos, no obstante, los propios trabajadores son más peligrosos

que los hackers.

La lista, actualizada periódicamente, es una herramienta para advertir a los programadores,

de modo que puedan prevenir las vulnerabilidades “que plagan la industria del software”.

La lista de los 25 errores más comunes ha sido elaborada por CWE, el Instituto SANS,

organizaciones como MITRE, y expertos en seguridad de Europa y Estados Unidos.

En primera posición se encuentra la “neutralización inapropiada de elementos especiales

utilizados en un comando SQL”. Este error es el que facilita los ataques de inyección de

código.

En segundo lugar aparece la “neutralización inapropiada de elementos especiales utilizados

en un comando OS”, mientras que la tercera posición la ocupa “copiar el buffer sin

comprobar el tamaño del input”.

La “neutralización impropia del input durante la generación de páginas web” es el cuarto

de estos errores. El quinto, por su parte, es la “falta de autentificación para funciones

críticas”.

LOS 25 ERRORES DE SOFTWARE MÁS PELIGROSOS

Rank Score ID Name

[1] 93.8 CWE-89

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').

Inadecuado neutralización de elementos especiales utilizados en un comando SQL (‘SQL injection').

[2] 83.3 CWE-78

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection').

Inadecuado neutralización de elementos especiales utilizados en un comando OS (‘OS Mando inyección').

[3] 79.0 CWE-120

Buffer Copy without Checking Size of Input ('Classic Buffer Overflow').

Copy buffer sin comprobar Tamaño de entrada (“Clásico desbordamiento de búfer').

[4] 77.7 CWE-79

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').

Neutralización impropia del input durante la generación de página web (“cross-site scripting').

[5] 76.9 CWE-306

Missing Authentication for Critical Function.

Falta de Autenticación para funciones críticas.

[6] 76.8 CWE-862

Missing Authorization.

Falta de autorización.

[7] 75.0 CWE-798

Use of Hard-coded Credentials.

Uso de preprogramado credenciales.

[8] 75.0 CWE-311

Missing Encryption of Sensitive Data.

Faltan cifrado de los datos sensibles.

[9] 74.0 CWE-434

Unrestricted Upload of File with Dangerous Type.

Carga de archivo sin restricciones de tipo peligroso.

[10] 73.8 CWE-807

Reliance on Untrusted Inputs in a Security Decision.

Dependencia de insumos confía en una decisión en materia de seguridad.

[11] 73.1 CWE-250 Execution with Unnecessary Privileges.

Rank Score ID Name

Ejecución con privilegios innecesarios.

[12] 70.1 CWE-352

Cross-Site Request Forgery (CSRF).

Secuencia solicitud falsificación (CSRF).

[13] 69.3 CWE-22

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').

Limitación indebida de una ruta en un directorio de acceso restringido (‘Ruta Transversal’).

[14] 68.5 CWE-494

Download of Code Without Integrity Check.

Descarga de Código sin comprobación de integridad.

[15] 67.8 CWE-863

Incorrect Authorization.

Autorización incorrecta.

[16] 66.0 CWE-829

Inclusion of Functionality from Untrusted Control Sphere.

Inclusión de la funcionalidad de control sea dudosa esfera.

[17] 65.5 CWE-732

Incorrect Permission Assignment for Critical Resource.

Incorrecta Asignación de permiso de recurso crítico.

[18] 64.6 CWE-676

Use of Potentially Dangerous Function.

Uso de función potencialmente peligrosas.

[19] 64.1 CWE-327

Use of a Broken or Risky Cryptographic Algorithm.

Uso de una fractura o Arriesgado Algoritmo criptográfico.

[20] 62.4 CWE-131

Incorrect Calculation of Buffer Size.

Cálculo incorrecto de tamaño de búfer.

[21] 61.5 CWE-307

Improper Restriction of Excessive Authentication Attempts.

Restricción indebida de excesivos intentos de autenticación.

[22] 61.1 CWE-601

URL Redirection to Untrusted Site ('Open Redirect').

Redirección de URL sea dudosa de Sitio (‘Open Redirector’).

[23] 61.0 CWE-134

Uncontrolled Format String.

La cadena de formato.

Rank Score ID Name

[24] 60.3 CWE-190

Integer Overflow or Wraparound.

Desbordamiento de enteros o envolventes.

[25] 59.9 CWE-759

Use of a One-Way Hash without a Salt.

Uso de un hash Unidireccionales sin sal.

LOS 25 ERRORES DE SOFTWARE MÁS PELIGROSOS

Rank Score ID Name

[1] 93.8 CWE-89

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

[2] 83.3 CWE-78

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

[3] 79.0 CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

[4] 77.7 CWE-79

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

[5] 76.9 CWE-306 Missing Authentication for Critical Function

[6] 76.8 CWE-862 Missing Authorization

[7] 75.0 CWE-798 Use of Hard-coded Credentials

[8] 75.0 CWE-311 Missing Encryption of Sensitive Data

[9] 74.0 CWE-434 Unrestricted Upload of File with Dangerous Type

[10] 73.8 CWE-807 Reliance on Untrusted Inputs in a Security Decision

[11] 73.1 CWE-250 Execution with Unnecessary Privileges

[12] 70.1 CWE-352 Cross-Site Request Forgery (CSRF)

[13] 69.3 CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

[14] 68.5 CWE-494 Download of Code Without Integrity Check

[15] 67.8 CWE-863 Incorrect Authorization

[16] 66.0 CWE-829 Inclusion of Functionality from Untrusted Control Sphere

[17] 65.5 CWE-732 Incorrect Permission Assignment for Critical Resource

[18] 64.6 CWE-676 Use of Potentially Dangerous Function

[19] 64.1 CWE-327 Use of a Broken or Risky Cryptographic Algorithm

[20] 62.4 CWE-131 Incorrect Calculation of Buffer Size

Rank Score ID Name

[21] 61.5 CWE-307 Improper Restriction of Excessive Authentication Attempts

[22] 61.1 CWE-601 URL Redirection to Untrusted Site ('Open Redirect')

[23] 61.0 CWE-134 Uncontrolled Format String

[24] 60.3 CWE-190 Integer Overflow or Wraparound

[25] 59.9 CWE-759 Use of a One-Way Hash without a Salt

CWE - COMMON WEAKNESS ENUMERATION

The Common Weakness Enumeration Specification (CWE) provides a common

language of discourse for discussing, finding and dealing with the causes of

software security vulnerabilities as they are found in code, design, or system

architecture. Each individual CWE represents a single vulnerability type. CWE is

currently maintained by theMITRE Corporation with support from the National

Cyber Security Division (DHS). A detailed CWE list is currently available at the

MITRE website; this list provides a detailed definition for each individual CWE.

All individual CWEs are held within a hierarchical structure that allows for

multiple levels of abstraction. CWEs located at higher levels of the structure

(i.e. Configuration) provide a broad overview of a vulnerability type and can

have many children CWEs associated with them. CWEs at deeper levels in the

structure (i.e. Cross Site Scripting) provide a finer granularity and usually have

fewer or no children CWEs. The image to the right represents a portion of the

overall CWE structure, the red boxes represent the CWEs being used by NVD.

(click to enlarge).

NVD integrates CWE into the scoring of CVE vulnerabilities by providing a cross

section of the overall CWE structure. NVD analysts score CVEs using CWEs

from different levels of the hierarchical structure. This cross section of CWEs

allows analysts to score CVEs at both a fine and coarse granularity, which is

necessary due to the varying levels of specificity possessed by different CVEs.

The cross section of CWEs used by NVD is listed below; each CWE listed links

to a detailed description hosted by MITRE. For a better understanding of how

the standards link together please visit: MITRE - Making Security Measurable

CWE is not currently part of the Security Content Automation Protocol (SCAP).

NVD is using CWE as a classification mechanism that differentiates CVEs by the

type of vulnerability they represent.

AUTOMATICALLY BUILDING CUSTOM TOP-N LISTS

Using CWRAF, an organization can pre-select which CWE entries are of greatest interest - i.e., creating a custom Top-N list. For example, a vignette that is centered around a product search capability for an e-Commerce web site might be composed of a database, web client and server, and a mobile application.

A set of relevant CWE entries could be selected as follows:

The process of creating a custom Top-N list involves several steps.

Manual steps:

1) Select or manually define an appropriate vignette, including its Technical Impact Scorecard.

2) Select the set of relevant CWE entries (see previous image). This could be partially automated, or use a selection from elsewhere (e.g., the Top 25).

3) Identify which CWSS factors should be treated as Not Applicable (e.g., Remediation Cost).

Automatic steps:

4) for each relevant CWE entry, extract its potential Technical Impacts.

5) use the vignette's Technical Impact Scorecard to evaluate each Technical Impact that is part of the relevant CWE entry. Select the maximum available subscore, regardless of the affected layer.

6) calculate the CWSS Impact factor using the maximum available subscore (i.e, use Quantified weighting instead of the pre-defined values for the Impact).

7) perform the full CWSS calculation to obtain a general score for the CWE entry (using the "Not Applicable" factors from step 3).

8) Rank all relevant CWE entries according to their CWSS scores.

PPRRUUEEBBAA DDEE SSOOFFTTWWAARREE

LLaa pprruueebbaa ddee ssooffttwwaarree eess uunn ccoonnjjuunnttoo ddee hheerrrraammiieennttaass,, ttééccnniiccaass yy

mmééttooddooss qquuee hhaacceenn aa llaa eexxcceelleenncciiaa ddeell ddeesseemmppeeññoo ddee uunn pprrooggrraammaa,, aassíí ccoommoo

ttaammbbiiéénn llaa mmeejjoorr ppuubblliicciiddaadd qquuee uunnaa eemmpprreessaa ddeeddiiccaaddaa aa llaa pprroodduucccciióónn ddee

ssooffttwwaarree ppuueeddaa tteenneerr.. LLaass ttééccnniiccaass ppaarraa eennccoonnttrraarr pprroobblleemmaass eenn uunn pprrooggrraammaa ssoonn

eexxtteennssaammeennttee vvaarriiaaddaass yy vvaann ddeessddee eell uussoo ddeell iinnggeenniioo ppoorr ppaarrttee ddeell ppeerrssoonnaall ddee

pprruueebbaa hhaassttaa hheerrrraammiieennttaass aauuttoommaattiizzaaddaass qquuee aayyuuddaann aa aalliivviiaarr eell ppeessoo yy eell ccoossttoo

ddee ttiieemmppoo ddee eessttaa aaccttiivviiddaadd.. PPeerroo ddee nnaaddaa sseerrvviirrííaa ccoonnoocceerr ttooddaass llaass ttééccnniiccaass ddee

pprruueebbaa ddee ssooffttwwaarree,, ssii uunn pprrooggrraammaa ccaarreeccee ddee ddooccuummeennttaacciióónn,, eell ccóóddiiggoo eess

ccoonnffuussoo,, oo nnoo ssee hhaann sseegguuiiddoo ppaassooss ppaarraa llaa ppllaanniiffiiccaacciióónn yy ddeessaarrrroolllloo ddeell ssooffttwwaarree,,

yyaa qquuee sseerrííaa ccoommoo bbuussccaarr uunnaa aagguujjaa eenn uunn ppaajjaarr..

¿Qué es el control de calidad del software?

El control de calidad del software incluye desde el monitoreo de desarrollo de procesos haciendo respetar los estándares y procedimientos concordados asegurándose un buen seguimiento de programa y la detección y corrección de errores. El control de calidad del software está orientado a la prevención.

¿Que es prueba de software?

La prueba de software involucra las operaciones del sistema bajo condiciones controladas y evaluando los resultados.

Las condiciones controladas pueden ser normales o anormales. La prueba puede intencionalmente esforzar al programa y producir errores en las respuestas para determinar si los sucesos ocurren cuando no tendrían que ocurrir o cuando los hechos no suceden cuando deberían suceder.

La prueba de software esta detectada a la detección. La mayoría de las grandes organizaciones asumen la responsabilidad del control de calidad y prueba de software a tal medida que en la producción se incluyen desarrolladores de sistemas (analistas, programadores) y un grupo dedicado a la prueba de software para que estos grupos antes mencionados trabajen en conjunto cumpliendo el control de calidad (prevención) y la prueba de software (detección) logrando una tarea exitosa.

Fallos más recientes causados por software con bug en sistemas de computación:

En enero del 2000 se registro la mayor cantidad de fallas de sistemas, en organizaciones europeas, de todos los tiempos al sufrir las consecuencias del efecto Y2K (Y2K bug).Como por ejemplo el sistema de trenes se vio afectado al no reconocer la fecha 01-01-00 y los trenes no salieron o salieron a destiempo, de la misma manera se produjeron problemas de comunicación en correos electrónicos en aquellos sistemas que utilizaban agenda de pedidos o informes que se enviaban automáticamente en cada fecha.

Otro problema fue causado en una escuela pública de los Estados Unidos donde alrededor de 100.000 estudiantes solicitaron la inscripción y el sistema no contemplaba el manejo de tal cantidad de inscriptos causando errores en las tarjetas de reportes de los alumnos inclusive inscriptos en otros años y en el sistema de registros de materias. Esta escuela decidió reinstalar el sistema viejo de hace 25 años hasta que los bug del sistema hayan sido corregidos.

En octubre de 1999 un modulo de la nave espacial para el estudio de Marte valuado en 125 Millones de dólares fue perdido en el espacio debido a un simple error de conversión de datos. Fue ciertamente determinado que el software de la nave utilizaba datos en el sistema métrico inglés, el error fue causado cuando se ejecutaban procesos concurrentes donde uno de ellos establecía comunicación para el descenso en el sistema métrico ingles y el otro proceso calculaba los parámetros de órbita con otro tipo de unidades, entonces estos dos procesos utilizaron el mismo procedimiento para la conversión de datos, aunque no se ha determinado que modulo del sistema causaron el bug.

Un bug en el programa de soporte de una red comercial de alta velocidad afectó 70.000 negocios de clientes por el periodo de 8 idas en agosto de 1999, entre los afectados fue la empresa Electronic Trading System Futures Exchange, la cual tuvo que suspender sus tareas. Esto fue causado por el repentino paro del programa de soporte en este sistema Non Stop.

¿Por qué es tan difícil para el desarrollo de sistemas incluir seriamente un control de calidad y una buena prueba de errores?

Resolver los problemas cuando se presentan es un proceso fácilmente determinado, pero prevenir problemas es una tarea muy minuciosa y muy difícil de determinar.

En la antigua china existía una familia de curadores, uno de los integrantes de esta familia siendo ya muy reconocido fue contratado por uno de los grandes Señores del territorio como su médico personal. Una noche mientras cenaban el Señor le pregunta al médico cual de sus otros familiares era tan poderoso como él, entonces el médico comento; Yo atiendo a personas con grandes males, casi moribundos llegan a mí con cierta fe, y algunas veces logro curarlos, y mi nombre es reconocido en casi todo el territorio. Mi hermano mayor cura las enfermedades

cuando recién comienzan a hacer raíz en el cuerpo y su nombre es reconocido en los vecindarios, mi hermano menor cura enfermedades antes de que aparezcan y solo es conocido por la familia y su nombre no ha salido de la casa.

Es decir, arreglar o corregir un problema o bug después que sale a la luz es una tarea relativamente sencilla, ya que se conoce el foco del problema, el inconveniente esta en corregir un error que no está visible o no ha sucedido todavía.

¿Cuáles son las razones para que un programa contenga bug?

Poca o falta de comunicación entre diferentes aplicaciones. (Requerimientos de las aplicaciones.)

Complejidad del software. Causa dificultad en la reutilización de código y generalmente requiere personas con experiencia en desarrollo de software moderno como por ejemplo en sistemas cliente servidor, aplicaciones distribuidas, comunicación de datos, manejo de enormes bases de datos relacionales y un gran manejo de técnicas orientadas a objetos. A veces estos conocimientos también pueden causar más errores de los que corrigen.

Errores de programación. Los programadores son uno de los principales factores en la causa de errores o bug.

Requerimiento de cambio en el sistema. El rediseño y la re planificación causan efectos en otros proyectos que trabajan en conjunto o a partir de resultados del sistema modificado.

Estos procesos cooperativos generan más complejidad en las diferentes pruebas y en el control y generalmente el entusiasmo de los desarrolladores del sistema se ve afectado al tener que realizar actividades diferentes o no correspondientes a su labor.

Como por ejemplo el de los ingenieros al tener que hacer un análisis funcional a partir de su planificación, todo esto influye y atenta con la integridad del programa y genera riesgos de una gran cantidad de errores.

Presiones de tiempos. Una buena planificación y un buen análisis con sus respectivos controles de calidad y prueba se ven afectados por un lapso corto de tiempo para que esto sea completo. La falta de tiempo generalmente conlleva a no considerar u omitir ciertas fases de prueba y control.

El ego (aspecto psicológico del personal).A veces la situación y el contexto lleva a que la gente diga:

o No hay problema o Es muy fácil. o Puedo terminar esto en pocas horas.

o No habrá inconvenientes en adaptar ese viejo código en vez de decir:

Eso es muy complejo. Nos llevara a cometer varios errores. No puedo estimar cuanto tiempo me llevara este trabajo. No sé como readaptar ese código.

Son muchas las ocasiones en las que un ¨ No hay problema ¨ genera un bug:

Pobre documentación del código. Es difícil poder modificar código cuya documentación es escasa o está mal escrita.

En muchas organizaciones los directivos no incentivan a los programadores a realizar una buena documentación e incluso a no darle importancia a la entendibilidad del código, como también el hecho de incentivar demasiada seguridad en la documentación y escritura del código. Lo que fue difícil de escribir podría llegar a ser difícil de leer y aun más complicado de modificarlo.

Herramientas de desarrollo de software. Herramientas visuales, librerías de clases, compiladores, herramientas de escritura, etc., a menudo introducen código extra con pobre documentación lo cual genera un bug en el programa en cuestión.

¿Cómo un nuevo software con control de calidad puede ser introducido en una organización existente?

Depende del tamaño de la organización y de los riesgos involucrados.

Para grandes organizaciones con altos niveles de riesgos en términos de capital y vida evolutiva de la empresa un serio manejo de control de calidad es absolutamente necesario por lo que un nuevo software debe garantizar una muy buena seguridad y cumplir con lo formalizado.

En organizaciones donde los riesgos son menores la implementación con control de calidad puede ir disminuyendo su intensidad con el tiempo sin que la organización con el tiempo. Esta falta de procesos con control de calidad podría ser equilibrada con mayor productividad eliminando niveles de burocracia.

Para pequeños proyectos el control de calidad de procesos puede ser enfocado a partes específicas del sistema dependiendo del tipo de organización o de clientes, aunque es importante asegurar una adecuada comunicación entre desarrolladores y personal ocupado de la prueba de programa asegurando también una retroalimentación del sistema optimizando la relación cliente empresa.

En todos los casos, lo más valioso es el esfuerzo en la prueba de software y un control de calidad del sistema garantizando buena especificación y cumpliendo con las expectativas pero generalmente el desempeño y los requerimientos de la empresa principalmente el factor tiempo hace que las pruebas de software y controles sean limitadas.

¿Que es verificación y validación?

La verificación típicamente incluye por parte de los desarrolladores la revisión de los planes, del código, de los requerimientos, de la documentación y las especificaciones y posteriormente una reunión con los usuarios para evaluar dichos documentos. Esto puede ser hecho con listas de chequeos, listas de problemas, walkthrough.

La validación típicamente incluye las pruebas del software y comienza después que la verificación este completa.

Este proceso de verificación y validación da lugar al termino ¨IV&V¨ “Independent verification and validation”.

¿Qué es walkthrough?

Es una reunión informal entre analistas y usuarios para la evaluación de propuestas informacionales, generalmente es requerida una pequeña preparación de documentos.

¿Qué es la inspección?

La inspección es una reunión formal luego del walkthrough, generalmente incluye personal de diferentes sectores esencialmente analistas, programadores, y personal de prueba (testers) donde acuerdan con los usuarios los metodos de seguridad prueba a llevar a cabo. A menudo en estas reuniones se incluye un moderador el cual representa a la empresa y que da a conocer al usuario una lista de operaciones de métodos de prueba y controles de calidad en las cuales el usuario debe optar definiendo el mismo el nivel de calidad.

¿Qué tipos de prueba de programa deben ser considerados?

Caja negra. No está basada en el conocimiento del código o diseño interno, determina la funcionalidad del sistema.

Caja blanca. Está basada en la lógica interna de la aplicación y el código. Hace una cobertura de declaraciones del código, ramas, caminos y condiciones.

Unidad de testeo o prueba. Es la escala más pequeña de la prueba, está basada en la funcionalidad de los módulos del programa, como funciones, procedimientos, módulos de clase, etc. En ciertos sistemas también se verifican o se prueban los drivers y el diseño de la arquitectura.

Integración incremental. Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo.

Prueba de integración. Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente servidor o red.

Prueba funcional. La caja negra hace la prueba funcional de los requerimientos de la aplicación y generalmente es realizada por el programador, en cambio, la prueba funcional es realizada por los testers.

Prueba de sistema. Es una prueba de caja negra incluyendo todos los componentes del sistema desde el hardware a la documentación.

Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la interacción con otros hardwares, bases de datos y redes.

Prueba de sanidad. Determina si la nueva versión de un software está bien realizada y si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no está en una condición sana.

Prueba de regresión. Es una nueva revisión en las pruebas del programa luego de que este haya sufrido algún cambio o por apuros de tiempo o la modificación fue en el ambiente en que se desenvuelve. Actualmente aparecieron herramientas automatizadas que hacen que este tipo de pruebas no lleve demasiado tiempo.

Prueba de aceptación. Es la prueba final basada en las especificaciones del usuario o basada en el uso del programa por el usuario final luego de un periodo de tiempo.

Prueba de carga. Está basada en las aplicaciones bajo cargas pesadas, generalmente usadas en sitios web y en servidores con gran cantidad de datos donde se determina en cuales puntos existen degradaciones del sistema.

Prueba de estrés. Es una prueba de carga y performance basada en la funcionalidad del sistema bajo cargas pesadas, un gran número de repeticiones, manejo de grandes datos y demasiadas preguntas a bases de datos grandes.

Prueba de performance. Es una de las pruebas finales y sirve para definir los requerimientos y la calidad del software, en base a las pruebas de carga y estrés. Incluye entrevistas con el usuario y programador.

Prueba de instalación y desinstalación. Determina la eficiencia de los procesos que instalan y desinstalan las aplicaciones del programa.

Prueba de recuperación. Es la prueba que evalúa que tan bien se recupera el sistema luego de bloqueos, fallas del hardware u otros problemas catastróficos.

Prueba de seguridad. Evalúa que tan bien el sistema se protege contra accesos, internos o externos, no autorizados, esta prueba requiere sofisticadas técnicas y herramientas.

Prueba de compatibilidad. Evalúa el desempeño del software en diferentes hardwares, sistemas operativos, redes, etc.

Prueba de exploración. Es una prueba informal del software que no está basada en ningún plan o caja de prueba y a menudo los testers aprenden del programa al explorar todas las aplicaciones posibles.

Prueba de anuncio. Es similar a la prueba de exploración pero los testers deben tener suficiente noción sobre el funcionamiento del programa antes de comenzar esta prueba. Incluye reunión con analistas y programadores.

Prueba de usuario. Determina si el usuario se desenvuelve satisfactoriamente con el programa.

Prueba de comparación. En esta prueba se comparan el pro y el contra del programa con los programas creados con la competencia.

Prueba alfa. Es la prueba cuando la aplicación esta cerca de la entrega al usuario. Se hacen pequeños cambios generalmente en el diseño de interfaces. Esta prueba es hecha por usuarios.

Prueba beta. Es la búsqueda de bug en el programa completo. Generalmente es hecha por usuarios.

Prueba de mutación. Esta prueba está basada en la introducción deliberada de diferentes códigos externos al programa (bug) para reexaminar si estos bug pueden ser detectados. Requiere gran disponibilidad de recursos de computación.

¿Cuáles son los cinco problemas más comunes en el desarrollo de procesos. ?

Pobre definición de requerimientos. Es normal que se comience a trabajar en base a requerimientos que están en bruto, si no hay una buena prueba de requerimientos con el usuario se crearan problemas.

Planificación irreal. Planifica sobre supuestos para acortar el tiempo de desarrollo, los problemas serán inevitables.

Pruebas inadecuadas. Es imprescindible asegurarse que el programa funciona antes de la entrega al usuario.

Falta de comunicación. Si desarrolladores de programas, clientes o usuarios y directivos del proyecto tienen una mala o escasa comunicación los problemas estarán garantizados.

Carencia de rasgos. Definir nuevos rasgos una vez que el programa se haya terminado es muy común y genera problemas. Se deben definir las características del programa.

¿Cuáles son las cinco soluciones para los problemas de desarrollo?

Requerimientos sólidos. Deben ser claros, completos, detallados, probables, posibles, cohesivos y coherentes. Son imprescindibles los prototipos para que se cumplan estas condiciones.

Planificación real. Se debe ser sincero y dedicar el tiempo adecuado a la planificación. Esto agilizara el diseño, la prueba y dará tiempo a posibles cambios.

Pruebas adecuadas. Las pruebas deben ser tempranas y adecuadas durante el desarrollo pudiendo establecer puntos de prueba (checkpoints) en caso de cambios, y pruebas finales una vez concluido el programa.

Comunicación continua. Con la tecnología existente hoy en día, un buen profesional debe poder utilizar todas las herramientas posibles, desde teléfonos celulares, e-mail, hasta reuniones formales e informales en los diferentes ámbitos que conciernan al desarrollo del software.

Seguimiento de rasgos. Es deseable realizar una buena preparación de las características a seguir por el programa. Interfaces, salidas, equipos etc. Una buena prototipación de las entradas y salidas es lo ideal para defenderse de posibles cambios y potenciales problemas.

¿Cómo realizar un buen código?

Un Buen código es aquel que funciona sin bug, además debe ser legible y mantenible, se debe ajustar a los estándares de la organización para que todos los desarrolladores del sistema manejen y entiendan las mismas herramientas y mecanismos en la codificación.

A continuación definiremos reglas que la mayoría de las organizaciones consideran importantes para evitar problemas en la mayoría de los lenguajes de programación mas usados como el C, C++.

Minimizar el uso de variables globales.

Nombres descriptivos de funciones, variables, módulos, objetos y métodos.

Minimizar el tamaño de funciones, métodos y procedimientos. Acercamiento al caso ideal de no exceder las 50 líneas.

Descripciones deben ser cortas y claras para no confundir la lectura del código.

Organización de los métodos, una buena disposición del código hará que futuros cambios sean posibles.

Uso generoso de espacios en blanco.

Es importante que cada línea de código no supere los 70 caracteres.

Una sentencia por línea.

Es fundamental que el grupo de desarrolladores respete el mismo estilo de codificación.

Toda aplicación debe ser documentada no importa lo pequeña que sea dicha aplicación.

¿Cómo pueden las nuevas herramientas automatizadas de prueba simplificar el proceso de detección de errores?

Una de las herramientas automatizadas que ha logrado ser muy popular en el entorno del diseño de software, por su simplicidad y, además, por el último gran disgusto en cuestión a problemas de software, el efecto Y2K, es la herramienta RECORD-PLAYBACK, al ejecutar dicha aplicación antes de hacer correr el programa a probar, se activa la opción récord, el Tester navega por las diferentes aplicaciones del software, menús, cuadros de dialogo, plantillas, tablas, botones, y los resultados son grabados en forma de texto para un reporte, y en el lenguaje de la herramienta en un archivo de grabado, cuando nuevas aplicaciones son agregadas al software o son modificadas las aplicaciones actuales, la opción playback de la herramienta navega automáticamente por el programa y luego emite un reporte de resultados y operaciones aun no testeadas.

Otras herramientas automatizadas existentes en el mercado son:

Analizador de código. Es una especie de depurador externo que examina además de las sentencias, los caminos e hilos del programa.

Analizador de cobertura. Solamente prueba las ramas y caminos de todas las funciones que trabajan, internamente o externamente, con el programa.

Analizador de memoria. Evalúa si las aplicaciones no exceden los limites de memoria en los peores casos, o situaciones críticas.

Performance de carga. En sistemas cliente servidor, esfuerza al programa para que trabaje con cargas pesadas y en situaciones extremas.

Analizador de sitios WEB. Examina los enlaces y las aplicaciones en los diferentes nodos y en el servidor.

Reporte de bug. Trabaja en conjunto con analizadores de código y de cobertura, haciendo un reporte de las partes de códigos no examinadas o confusas.

Reporte de configuración. Hace un reporte de los requerimientos del programa en cuestión a hardware y los parámetros mínimos que se deben cumplir para que el software pueda trabajar al máximo.

Reporte de desempeño. Hace un reporte del nivel de desempeño, aplicación por aplicación, del programa en el hardware instalado.

Estudio de técnicas de prueba básicas.

Hoy en dia, la mayor parte de las técnicas de prueba se basan en las tecnicas aparecidas en los años 70, dandole fundamental importancia los avances tecnologicos, los avances en lenguajes de programacion y la gran variedad de tipos de software, las pruebas de caja negra y caja blanca han tomado un lugar muy importante en el desarrollo de sistemas de cualquier tipo, tanto que sin dichas pruebas un sistema desarrollado careceria de garantias y credibilidad en sus resultados.

Prueba de caja negra

Esta prueba implica una variada seleccion de los datos de prueba asi como una buena interpretacion de los resultados para determinar el nivel de optimizacion de la funcionalidad del sistema.

Se ha determinado con diferentes estudios estadisticos, que el software no debe ser probado por el creador o grupo de creadores del sistema ya que el extenso conocimiento de la estructura interna del programa limita la variedad de datos probados o el encaminamiento de las pruebas es hacia ciertos rasgos del programa olvidando otras partes del software poco valoradas por su simpleza en la creacion.

Segun C. Kaner en su libro ¨Testing Computer Software¨ de 1993, el aspecto humano es esencial en la prueba de caja negra aplicando factibles sucesos de la vida real a la prueba, errores de tipeo, trabajar en aplicaciones equivocadas creyendo trabajar en la aplicacion deseada, etc., pero sucede que los programadores han pasado tanto tiempo en la creacion del sistema y al ser la prueba de caja negra una de las mas tempranas sus hechos factibles de la vida real estan entre el ¨begin¨ y el ¨end¨ de cada aplicacion.

La prueba de caja negra ha hecho que cada organizacion dedicada al desarrollo de software contemple dentro de ella un departamento especial dedicado a las pruebas.

El principal objetivo es determinar la funcionalidad del software y parte de tratar al programa como si fuera una función matemática, estudiando si las respuestas o salidas son ¨codominio¨ de los datos entrantes ¨dominio¨. La prueba de caja negra tiene otras metas, determinar la eficiencia del programa desde el desempeño en el equipo, el tiempo de retardo de las salidas hasta el nivel de recuperacion del sistema luego de fallas o caidas sean estas producidas por manejo incorrecto de datos, equipo, o producidas externamente como cortes de energia.

La prueba de caja negra debe cubrir el espectro entero de sucesos factibles, de esto se debe ocupar el departamento de prueba, pero nunca se sabe si se han cubierto todos los casos o gran parte de ellos, no olvidemos que los testers pertenecen a la organizacion por lo que la prueba de caja negra no termina una vez que salio del laboratorio.

La prueba con intervencion del usuario es un pequeño periodo de tiempo en el cual el usuario bajo el asesoramiento de testers, se desenvuelve en el software y examina la operabilidad de los datos que el maneja. El usuario dara la puntada final en la cuestion de datos de prueba. Esta parte de la prueba no podría hacerse sin que el usuario haya tenido previo contacto con los prototipos del sistema, y para los testers una efectiva interacción con herramientas CASE.

Prueba de caja blanca

Para esta prueba se consideran tres importantes puntos.

I) Conocer el desarrollo interno del programa, determinante en el análisis de coherencia y consistencia del código.

II) Considerar las reglas predefinidas por cada algoritmo.

III) Comparar el desarrollo del programa en su código con la documentación pertinente.

La primera parte de esta prueba es el análisis estático.

Análisis estático Manual

Inspección: Determina si el código esta completo y correcto, como también las especificaciones.

Walkthrough: Interrelación informal entre testers, creadores y usuarios del sistema.

Análisis estático Automático

Verificación estática: Compara los valores generados por el programa con los rangos de valores predefinidos haciendo una descripción del funcionamiento de los procedimientos en términos booleanos determinando los puntos de falla

Ejecución simbólica: Hace un seguimiento de la comunicación entre funciones, módulos, aplicaciones, luego de que todas las partes hayan sido verificadas por separado.

La segunda parte de esta es el análisis dinámico. Para esto se cuenta con diferentes tipos de herramientas.

Análisis de cobertura: Examina las extensiones del código, haciendo una caja blanca por modulo.

Trafico: Sigue todos los caminos de comunicación entre módulos guardando los valores de las variables en cada uno de ellos.

Simulador: Simula partes del sistema para el cual el hardware no está habilitado.

Sintonía: Testea los recursos utilizados durante la ejecución del programa.

Prueba de certeza: Examina las construcciones lógicas del programa.

Generación de datos de prueba.

La selección de datos de prueba es una de las más importantes disciplinas dentro de la caja blanca. Usualmente se generaban en forma aleatoria y hacían un acercamiento a una sofisticada prueba estructural determinando el desempeño de los módulos con dichos valores.

A partir del gran colapso causado por el efecto Y2K han aparecido en el mercado herramientas automatizadas que generan datos de prueba y que, además examinan paso a paso la ejecución del programa.

¿Que cosas hacen a un buen ingeniero en pruebas y control de calidad?

El ingeniero debe tener una actitud de probar para romper, o sea, la habilidad de conseguir el punto de vista del cliente y un buen análisis de detalle para encontrar errores que no se ven a simple vista. Aunque no parezca importante, la actitud de trabajo en equipo, la diplomacia con usuarios, desarrolladores y ejecutivos dará a este la noción de los focos de prueba más importantes cuando el tiempo de prueba es extremadamente limitado y los riesgos de un mal control son altos.

Un buen ingeniero dedicado a esta disciplina debe ser paciente y tener la habilidad de saber encontrar los problemas y las omisiones.

Pasos para el desarrollo de pruebas:

- Obtener los requerimientos en forma clara.

- Obtener planificación de diseño.

- Determinar funcionalidad.

- Identificar aplicaciones de alto riesgo o con prioridad de prueba.

- Determinar métodos de prueba.

- Determinar contexto de la prueba.

- Obtener datos de prueba.

- Estimar tiempo de prueba.

- Clasificar errores del programa.

- Documentar errores del programa.

- Redactar los casos de prueba que encontraron fallas.

- Aprobar una revisión en la prueba.

- Evaluar resultados en reportes.

- Buscar bug.

- Volver a probar si es necesario.

- Actualizar el plan de prueba.

¿Cómo se define un plan de prueba?

- Titulo

- Identificación, números de versión, creador, fecha de creación.

- Tabla de contenidos.

- Reportes de reuniones.

- Reportes de requerimientos.

- Reportes de documentación.

- Análisis de riesgos.

- Prioridades y focos de prueba.

- Limites. (Tiempo, riesgos, etc.)

- Reporte de datos de prueba.

- Reporte de resultados.

- Reporte de aplicaciones conjuntas al programa.

- Informe de herramientas automatizadas.

- Determinación de la sanidad del programa.

- Personal implicado.

- Reportes relevantes. (Licencias, clasificaciones, métodos, etc.)

- Apéndices, glosario, cronología.

Bibliografia.

Revista Programacion Actual

Prueba de Software y Seguridad en entornos distribuidos

M. Vasquez C. Falcato Editorial Prensa Tecnica S. L. España

Material de Internet

Computer Organization (Computer.org)

Testing Computer Software C. Kaner

Software Testing in the Real World E. Kit

Software Engineering R. Pressman

Practical Testing Advice Diomidis Spinellis

Sistema de seguimiento de errores

Un sistema de seguimiento de errores es una aplicación informática diseñada para ayudar a asegurar la calidad de software y asistir a los programadores y otras personas involucradas en el desarrollo y uso de sistemas informáticos en el seguimiento de los defectos de software. El término usado en inglés es Bug Tracking System, y frecuentemente se usa el acrónimo BTS. Puede considerarse como una especie de sistema de seguimiento de incidentes. Son usados intensivamente por cualquier empresa o institución que realice desarrollo de software.

Si bien muchos sistemas de seguimiento de errores de software libre permiten que los usuarios directamente den de alta la incidencia detectada, en muchas empresas de desarrollo de software se usan de manera estrictamente interna. Muchos de los sistemas de seguimiento de errores de software se integran frecuentemente con otras herramientas, como pueden ser correo electrónico, control de versiones, y otras herramientas de gestión administrativa.

Componentes

Uno de los componentes principales de un sistema de seguimiento de errores es la base de datos donde se almacenan los hechos e historia de un fallo de software. Los hechos pueden ser una descripción detallada del fallo, la

severidad del evento, forma de reproducirlo y los programadores que intervienen en su solución así como información relacionada al proceso de administración de la corrección del fallo como puede ser personal asignado, fecha probable de remedio y código que corrige el problema.

La mayor parte de los sistemas de seguimiento de errores identifican un ciclo de vida al cual se le da seguimiento mediante el estado del problema desde su descubrimiento y reporte hasta su solución final. De la misma manera, son regularmente configurables para permitir que diferentes personas consulten o editen diferentes aspectos del reporte, así como permitir a los administradores clasificar los diferentes estados del problema.

Clasificación de errores

No todos los grupos de desarrollo de software están de acuerdo en la clasificación o gradación de la severidad y prioridad de un problema de software. Bugzilla y GNOME proponen la siguiente clasificación de severidad:

Bloqueador: inhibe la continuidad de desarrollo o pruebas del programa. Crítico: Crash de la aplicación, pérdida de datos o fuga de memoria severa. Mayor: pérdida mayor de funcionalidad, como menús inoperantes, datos de

salida extremadamente incorrectos, o dificultades que inhiben parcial o totalmente el uso del programa.

Normal: Una parte menor del componente no es funcional. Menor: Una pérdida menor de funcionalidad, o un problema al cual se le

puede dar la vuelta. Trivial: Un problema cosmético, como puede ser una falta de ortografía o un

texto desalineado. Mejora: Solicitud de una nueva característica o funcionalidad.

Uso

En un entorno corporativo, un sistema de reporte de errores puede ser utilizado para generar reportes de la productividad de programadores al reparar errores. Sin embargo, esto puede a veces producir resultados inexactos debido a que diferentes errores pueden tener diferentes niveles de gravedad y complejidad. La severidad de un error puede no estar relacionada directamente a la complejidad de resolver el error. Pueden haber distintas opiniones entre administradores y arquitectos.

Un sistema local de reporte de errores (local bug tracker, LBT) es generalmente un programa utilizado por un equipo de profesionales de soporte (a veces un help desk) para mantener registro de incidentes reportados a los desarrolladores de software. El uso de un LBT permite a los profesionales de soporte llevar registro de los incidentes en su "propio lenguaje" y no en el "lenguaje de los desarrolladores". En suma, el uso de LBT permite a un equipo de profesionales de soporte reportar información específica acerca de los usuarios

que han llamado a quejarse de aquello que no siempre puede ser necesario en la lista de tareas pendientes de desarrollo (así, hay dos sistemas de registro cuando un LBT está disponible).