PRUEBAS DE AUDITORA DE SOFTWARE

Pruebas unitarias
Las pruebas unitarios son un procesos de desarrollo de software donde las partes ms pequeas
de una aplicacin; llamadas unidades, se encargan de la verificaron la operacin de partes
especficas de una manera apropiada.
Este tipo de prueba puede ser lenta y tediosa y exige paciencia y minuciosidad por parte del
equipo de desarrollo. Adems de tener una documentacin, las pruebas unitarias se deben hacer
con teniendo en cuenta que puede que no sea posible probar una unidad para cada escenario de
entrada que se producir cuando el programa se ejecuta en un entorno real.
Las pruebas de unidades son a menudo automatizadas pero tambin se puede hacer
manualmente. Este tipo de prueba es componente de la Programacin Extrema, un mtodo de
desarrollo de software que est enfocado a la construccin de un producto por medio de pruebas
continuas y de revisin. Una vez que todas las unidades en un programa se han encontrado para
trabajar de la manera ms eficiente y libre de errores, los componentes ms grandes del programa
pueden ser evaluados por medio de pruebas de integracin.

Pruebas funcionales
La prueba funcional es un proceso de pruebas de auditora utilizada en el desarrollo de Software
en el que se ha probado que el programa o aplicacin cumple con todos los requisitos. La prueba
funcional es una forma de controlar que tiene toda la funcionalidad requerida que se especifica
dentro de sus requisitos de funcionamiento.
Principalmente se usa para verificar que una pieza de software est proporcionando la misma
salida que requiere el usuario final. Por lo general, las pruebas funcionales implican la evaluacin y
la comparacin de cada funcin de software con los requerimientos del negocio. El software se
prueba de modo que cuente con alguna entrada relacionada para que la salida puede ser
evaluada, se relaciona o vara en comparacin con sus necesidades bsicas. Por otra parte, las
pruebas funcionales tambin comprueban la facilidad de uso del mismo.

Pruebas de integracin
Las pruebas de integracin son tipos de pruebas de software que se utiliza para probar los
componentes de software individuales o unidades de cdigo para comprobar la interaccin entre
varios componentes de software y detectar defectos de interfaz. Los componentes son probados
como un solo grupo u organizados de manera iterativa.



Pruebas de validacin y verificacin
Son dos pruebas importantes que se llevan a cabo en un software antes de que haya sido
entregado al cliente. El objetico de estas pruebas es asegurar que el producto se hace de acuerdo
con los requisitos del cliente, y en efecto cumplir la finalidad prevista. La papel de la verificacin es
el proceso de control de calidad, se lleva a cabo antes que el software est listo para la liberacin.
Por otro lado la prueba de validacin. Tiene como objeto validar y tener confianza en el producto
o sistema, y que cumple los requisitos establecidos por el cliente. La aceptacin del software por
parte del cliente final es tambin su parte. A menudo, las actividades de prueba se introducen
temprano en el ciclo de vida de desarrollo de software.

Prueba de Caja Blanca
La prueba de caja blanca se refiere tradicionalmente a la utilizacin de cdigo fuente del programa
como una base de pruebas, es decir, como la base para el diseo de pruebas y casos de prueba. En
otras palabras " las pruebas de caja blanca se basan en las estructuras internas del software.

Prueba de Caja Negra
Es un tipo de prueba en la que la funcionalidad del software ha sido probada sin ninguna
referencia al diseo interno, cdigo o algoritmo utilizado en el programa. Los casos de esta prueba
generalmente son construidas en torno a las necesidades y especificaciones del software
La base de la estrategia de esta prueba se encuentra en la seleccin de datos apropiados como por
la funcionalidad del sistema y la prueba contra las especificaciones funcionales con el fin de
comprobar el comportamiento normal y anormal del sistema.

Prueba de Aceptacin
Es una fase de prueba formal que determina si un sistema es est acorde al propsito por el cual
se solicit, es decir, que satisface todos los requisitos esenciales de los usuarios y est llevando a
cabo a un nivel aceptable segn lo esperado por el cliente y lo acordado por el proveedor. Esto se
hace mediante la definicin de un conjunto de criterios de aceptacin que el sistema debe
satisfacer antes de que el cliente lo aceptar.
Generalmente, antes de iniciar cualquier proyecto de software, el cliente y el proveedor
delinearn un acuerdo sobre el propsito del software y la funcionalidad que debe ofrecer. Una
vez que el software ha sido desarrollado, tiene que ser probado en siguiendo las especificaciones
planteadas por el cliente, la prueba de aceptacin del usuario es una parte esencial de las
prestaciones del proyecto y es especialmente importante en trminos de condiciones legales.


Prueba de Regresin
Las pruebas de regresin se utilizan para verificar los componentes del sistema que han sido
probados. Esto ocurre despus que nuevas funcionalidades o cambios de cdigo han sido
realizados. Las pruebas de regresin verifican que los componentes que antes eran estables lo
sigan siendo y sean adecuados a los objetivos. Normalmente, en un enfoque de pruebas de
regresin se automatiza el uso de herramientas de pruebas de software automatizadas. Suele ser
ms exitosa cuando se implementa mediante un recurso con experiencia.

Punto 3

COBIT Objectives for Information and related Technology (Objetivos de Control para tecnologa
de la informacin y relacionada) es un framework diseado para desarrollar, planear,
implementar, controlar y evaluar el rea de tecnologa de una compaa. Fue publicado (ISACA)
Information Systems Audit and Control Association (Asociacin de Auditora y Control de Sistemas
de Informacin).
El objetivo de COBIT es proporcionar un lenguaje comn para los ejecutivos de negocios para
comunicarse entre s acerca de las metas, objetivos y resultados.
La versin original, publicada en 1996, se centr en gran medida en la auditora, mientras que La
versin ms reciente, publicada en 2013, hace nfasis en el valor que el gobierno TIC puede
proporcionar a un "xito empresarial. Tambin proporciona una buena cantidad de consejos sobre
la gestin de riesgos empresariales.


(ITIL) Information Technology Infrastructure Library ITIL es el enfoque ms ampliamente
adoptado para la gestin de servicios en el mundo. Proporciona un marco prctico y sensato para
identificar, planificar, entregar y apoyar a los servicios de TI con el negocio.
ITIL se encarga de mirar que los servicios de tecnologa estn alineados a las necesidades de la
empresa y apoyan los procesos de negocio. Proporciona orientacin a las organizaciones sobre
cmo utilizar las TI como una herramienta para facilitar el cambio de negocios, la transformacin y
el crecimiento.
ITIL 2011 tiene en cuenta la opinin de los usuarios y la comunidad de la formacin, es una
actualizacin, no una nueva versin". No hay conceptos totalmente nuevos simplemente se
complementaron los que ya existan, pero el objetivo de la actualizacin es "resolver los errores e
incoherencias en el texto y los diagramas en toda la suite".

Capability maturity model integration (CMMI) es un enfoque o metodologa para mejorar y
perfeccionar el proceso de desarrollo de software en una organizacin. Se basa en un modelo de
proceso o una coleccin estructurada de las prcticas.
CMMI se utiliza para guiar el proceso de mejora a travs de un proyecto, la divisin o incluso una
estructura organizativa completa. Tambin permite a las empresas integrar las funciones de
organizacin que son tradicionalmente separadas, establecer objetivos de mejora y las prioridades
del proceso, proporcionar orientacin a los procesos de calidad, y actuar como un punto de
referencia para evaluar los procesos.
Las cinco guas bsicas mapa todo el ciclo de vida del servicio de ITIL , que comienza con la
identificacin de las necesidades y los conductores de los requerimientos de TI de los clientes , a
travs del diseo e implementacin del servicio en funcionamiento y, por ltimo , en la fase de
seguimiento y mejora del servicio .
El primer modelo CMMI fue desarrollado en el Instituto de Ingeniera de Software (SEI) de la
Carnegie Mellon University. Su objetivo era evaluar la madurez de los procesos de desarrollo de
software de una organizacin. CMMI versin 1.3 fue lanzado el 1 de noviembre de 2010. Integr
los tres modelos de CMMI en un comunicado. Estos incluyen CMMI para el Desarrollo, CMMI para
servicios y CMMI for Acquisition.

ISO 27001 (formalmente conocida como ISO / IEC 27001:2005) es una especificacin para un
sistema de gestin de seguridad de la informacin (SGSI). Un SGSI es un marco de polticas y
procedimientos que incluye todos los controles legales, fsicas y tcnicas que intervienen en los
procesos de informacin de gestin de riesgos de una organizacin.
De acuerdo con su documentacin, ISO 27001 fue desarrollada para "proporcionar un modelo
para establecer, implementar, operar, monitorear, revisar, mantener y mejorar un sistema de
gestin de seguridad de la informacin."
ISO 27001 utiliza un enfoque basado en el riesgo de arriba abajo y es tecnolgicamente neutral. La
especificacin define un proceso de planificacin de seis partes:

Definir una poltica de seguridad.
Definir el alcance del SGSI.
Llevar a cabo una evaluacin de riesgos.
Administrar los riesgos identificados.
Seleccionar objetivos de control y que se aplicarn de control.
Preparar una declaracin de aplicabilidad.

La especificacin incluye los detalles de la documentacin, la responsabilidad de gestin, las
auditoras internas, la mejora continua, y la accin correctiva y preventiva. La norma requiere la
cooperacin entre todos los sectores de una organizacin.
La norma 27001 no impone controles de seguridad de la informacin especficas, sino que
proporciona una lista de verificacin de los controles que deben ser considerados en el cdigo que
acompaa a la prctica, la norma ISO / IEC 27002:2005. Esta segunda norma describe un amplio
conjunto de objetivos de control de seguridad de la informacin y un conjunto de buenos
controles de seguridad de las prcticas generalmente aceptadas.


PLAN DE RIESGO PARA EL REA DE INFORMTICA

Anlisis de riesgos
El primer paso en el plan es realizar un anlisis de riesgos, este consiste en la identificacin
de riesgos, evaluacin de la probabilidad de que ocurra un evento, y definir la gravedad o
las consecuencias de ese evento. Tambin puede ser til llevar a cabo una evaluacin de
vulnerabilidad, lo que ayuda a identificar las situaciones en las que la organizacin puede
ponerse en mayor riesgo al no realizar ciertas actividades. Un ejemplo puede ser el
aumento del riesgo de ataques de virus al no usar un anti-virus eficiente o por la falta de
un firewall que filtre correctamente aplicaciones permitidas. Por ltimo, los resultados del
anlisis de riesgos se resumen en un informe, con actividades recomendadas para evitar
fallas o problemas.
Una vez que los riesgos y las vulnerabilidades han sido identificados, podemos realizar
estas 4 actividades para tener una respuesta defensiva adecuada en nuestro plan de
riesgo:

Medidas de proteccin: son actividades diseadas para reducir las posibilidades de un
evento disruptivo ocurra, para este caso las medidas de proteccin se pueden enfocar a la
proteccin adecuada de los equipos de la compaa deben cumplir con polticas de
seguridad requeridas para evitar que el sistema sea vulnerable.
Medidas de mitigacin: Estas actividades estn diseadas para minimizar la gravedad de
un evento, una vez que ha ocurrido. Un ejemplo para este caso es tener dispositivos para
reducir el impacto de la cada de un rayo, y as evitar una sobrecarga, o los sistemas de
alimentacin ininterrumpida tipo UPS para reducir las posibilidades de un cierre
inesperado debido a un corte de luz o un apagn.
Actividades de recuperacin: Estas actividades sirven para traer de vuelta a los sistemas y
la infraestructura afectada a un nivel que puede apoyar las operaciones de negocios; un
ejemplo son los datos crticos que se almacena fuera del sitio que se puede utilizar para
reiniciar las operaciones de negocio a un punto apropiado.
Planes de contingencia: el plan de contingencia es algo muy importante a la hora de crear
un plan de riesgo ya que nos permite documentar un proceso describiendo la solucin
desde la raz de un problema previamente establecido, por lo general se activa con base a
la entrada del equipo de manejo de emergencias.

RIESGOS NATURALES Y HUMANOS
Los desastres son una combinacin nica de eventos y circunstancias. Principalmente
existen dos categoras, las naturales y las hechas por el hombre. Este tipo de eventos, los
podemos definir con mayor precisin las causas deliberadas o accidentales.
Los peligros naturales son tpicamente considerados como actos que no se esperan,
pueden tomarse medidas para evitarlos pero en ocasiones hay peligros naturales que son
difciles de prever debido a la magnitud. En cambio los eventos hechos por el hombre son
aquellos en los que una o varias personas pueden ser consideradas responsables de
contribuir al evento que caus el desastre, de manera voluntaria o involuntaria.

Este es un ejemplo de algunos eventos a tener en cuenta en un plan de riesgo.

Riegos naturales:
Tormentas, Inundaciones, truenos, terremotos, tsunamis, entre otros.

Riegos humanos deliberados:
Fraudes, incendios provocados, protestas, vandalismo, terrorismo, atentados terroristas,
apagar sistemas de manera voluntaria, violacin de sistemas.

Riegos humanos accidentales:
El uso indebido de sistemas por falta de conocimiento, errores de programacin de
software, fuego causado por una falla elctrica, la descarga del extintor, filtraciones de
agua.
Riegos humanos indirectos:

Fallas de energa, fallas en las telecomunicaciones, daos por humo, inundaciones
causadas por sistemas contra incendios, hundimiento de la tierra.

EL PROCESO DE EVALUACIN DE RIESGOS
En este paso vamos a darle un valor al estado de la falla o el riesgo para poder tener un
valor de medida se puede basar en una escala numrica, por ejemplo, de 0,0 a 1,0 o de 1 a
10, o puede identificarse de una manera cualitativa, en este proceso se pueden utilizar
trminos subjetivos como "baja a media", "alta" "bueno a excelente", en lugar de los
valores numricos.
Los mtodos cuantitativos, que asignan un valor numrico para el riesgo, por lo general
requieren el acceso a estadsticas confiables para proyectar las probabilidades futuras.
Como se mencion anteriormente, los mtodos cualitativos a menudo incluyen medidas
subjetivas como baja, media y alta. Sin embargo, a veces el enfoque cualitativo es ms
aceptable para la administracin.
Una vez que todos los riesgos relevantes se han analizado y asignado una categora
cualitativa, se procede a examinar que tipo de estrategias vamos a utilizar para hacer
frente a los riesgos ms altos. Esto depender del tipo de riesgo en la gestin, para
abordar de manera apropiada los riesgos.