Antologia DSS

INSTITUTO TECNOLOGICO SUPERIOR DE CENTLA LICENCIATURA EN INFORMTICA ANTOLOGA DE DESARROLLO DE SOFTWARE SEGURO
Unidad I
Introduccin a la seguridad del software Objetivo: El alumno conocer y comprender los fundamentos tericos, tendencias y metas de la seguridad en el software.
Contenido: 1.1 1.2 1.3 1.4 Concepto de Software Casos reales de fallas en el software Futuro del software Fuentes para informacin de vulnerabilidades 1.4.1. Buqtraq 1.4.2. CERT Advisores 1.4.3. RISK Digest Tendencias tcnicas que afectan a la Seguridad del Software Breanking and patch (romper y actualizar) Metas de la Seguridad enfocadas al Software 1.7.1. Prevencin 1.7.2. Auditable y trazable 1.7.3. Monitoreo 1.7.4. Privacidad y Confidencialidad 1.7.5. Seguridad Multiniveles 1.7.6. Anonimato 1.7.7. Autenticacin 1.7.8. Integridad Conocer al enemigo Metas de proyecto de Software
1.5 1.6 1.7
1.8 1.9
DESARROLLO DE SOFTWARE SEGURO
1.1 Concepto
de software.
Es el conjunto de programas de cmputo, procedimientos, reglas, documentacin y datos asociados que forman parte de las operaciones de un sistema de computacin.
1.2
Casos reales de fallas en el software.
Las fallas se pueden dividir en tres bloques. fallos debido a errores desconocidos en el software, o conocidos solo por terceras entidades hostiles. fallos debido a errores conocidos pero no arreglados. fallos debido a una mala configuracin del software.
El primero de ellos se puede achacar debido a la calidad del cdigo. El segundo a la capacidad de arreglo de los errores descubiertos por parte del proveedor del mismo. El tercero la falta de documentacin del software o falta de formacin adecuada de los administradores para hacer una adaptacin correcta del mismo. Los fallos pueden dar lugar a un mal funcionamiento del programa. Tales fallos pueden ocasionarse por:

implementacin de algoritmos de forma incorrecta. pueden disearse servicios, que en contra de sus especificaciones deseadas ofrezcan funcionalidades no deseadas. pueden no tomarse las medidas de precaucin adecuadas para asegurar el correcto tratamiento de los parmetros de entrada.
Ejemplo:
Uno de los casos reales. Caso real: fraude con tarjetas de crdito
1.3
El futuro del software
El futuro del software es la planificacin de los proyectos se hace con rigor y est bien ajustada a la complejidad y tamao de las aplicaciones. La cual determina la existencia de cuatro factores que van a redefinir el panorama del software en el futuro. Utilizndolos como los cuatro jinetes (en alusin a los jinetes del Apocalipsis), Los cuatros jinetes son: 1) SOA (Arquitectura creada para el servicio) 2) SaaS (Software como servicio) 3) Cdigo abierto o software libre 4) Offshore sourcing
1.4
Fuentes para la informacin de vulnerabilidades
Vulnerabilidades de software: errores de aplicaciones, errores de sistemas operativos, rutinas de acceso no autorizados, servicios no autorizados. Los elementos presentados a continuacin responden a experiencias en el desarrollo de software que de alguna manera materializan la ausencia de uso de estndares de desarrollo de software y de adecuadas prcticas de programacin, las cuales se encuentran directamente relacionadas con los escenarios de pruebas requeridos para verificar las condiciones y confiabilidad del software.
Las cuales se mencionan cada una de ellas: 1. Cambios en el ambiente de ejecucin 2. Desbordamientos y chequeos de sintaxis 3. Convenientes pero peligrosas caractersticas del diseo del software. 4. Invocaciones no controladas. 5. Bypass a bajo nivel. 6. Fallas en la implementacin de protocolos
A continuacin se describen cada una de las tcnicas:

1.- Cambios en el ambiente de ejecucin: Los parches, los cambios en la configuracin y variables de entorno alrededor de las aplicaciones son elementos crticos para mantener una ejecucin adecuada y controlada de las rutinas y acciones previstas en el software. 2. Desbordamientos y chequeos de sintaxis: Dos elementos importantes en la revisin y evaluacin de software. Por un lado la evaluacin de los desbordamientos bien sea de memoria o de variables especficas dentro de un programa y por otro lado, la verificacin de buen uso de los comandos o palabras reservadas en el lenguaje de programacin, que permitan al programador un uso adecuado y eficiente de las estructuras. 3. Convenientes pero peligrosas caractersticas del diseo del software: Esta fuente de vulnerabilidad nos presenta funcionalidades que son deseables en el software para aumentar la versatilidad de uso de las aplicaciones. Los programadores y usuarios, pero que generalmente abren posibilidades de ingresos no autorizados que comprometen la integridad de sistemas y socavan la confianza del usuario frente a la aplicacin. 4. Invocaciones no controladas: Son referencia a un inadecuado manejo de errores o excepciones en las aplicaciones o exceso de privilegios de ejecucin, los cuales se manifiestan en comportamientos inesperados del software que generalmente ofrecen mayores privilegios o accesos adicionales a la informacin del sistema. 5. Bypass a bajo nivel. Las implicaciones de esta fuente de vulnerabilidades hace referencia al aseguramiento que la aplicacin debe tener al ser invocada o eje
6. Fallas en la implementacin de protocolos. Los elementos de seguridad
mencionados en este apartado, hacen referencia a las medidas de seguridad en redes.
En su sentido ms amplio, el trmino vulnerabilidad se refiere a la violacin de una poltica de seguridad. Definir claramente el trmino vulnerabilidad y separar los dos significados. MITRE, un grupo de investigacin y desarrollo fundado en Estados Unidos, que se concentra en el anlisis y la solucin de situaciones crticas de seguridad. El grupo propone las siguientes definiciones: Segn la Terminologa de MITRE's CVE. Una vulnerabilidad universal es un estado en un sistema de ordenadores o un grupo de sistemas que:

permite que un atacante ejecute rdenes como otro usuario permite que un atacante tenga acceso a los datos de acceso restringido permite que un atacante hacerse pasar por otra entidad permite que un atacante conduzca una denegacin de servicio.
MITRE: cree que cuando un ataque se hace posible por una debilidad o una poltica de seguridad inapropiada, es mejor descrita como "exposicin" Una exposicin es un estado en un sistema de ordenadores (o grupo de sistemas) que no es una vulnerabilidad universal, pero:

permite que un atacante rena informacin sobre las actividades del sistema permite que un atacante disimule sus actividades Incluye una funcin que se comporta como se espera, pero puede ser fcilmente puesta en peligro Es un punto primario de entrada que un atacante puede intentar usar para obtener acceso al sistema o a los datos. Es considerado un problema de acuerdo a alguna poltica de seguridad razonable.
Los riesgos, en trminos de seguridad, se caracterizan por lo general mediante la siguiente ecuacin.
1.5
Tendencias Tcnicas Que Afectan la Seguridad del Software
Dentro de seguridad de software se engloban mltiples facetas; desde la creacin de sistemas de backup hasta el anlisis antivirus pasando por el hacking tico o la correlacin de logs. Algunas tendencias:
El uso de Internet por parte de mafias organizadas con la intencin de
usarlo como medio de estafa y enriquecimiento ha supuesto un punto de inflexin en este sentido. El robo o suplantacin de identidad es una de las amenazas ms alarmantes de los ltimos aos no slo por su vertiginoso ritmo de crecimiento sino tambin por la gravedad de los daos asociados a este hecho En la seguridad: Las economas nacionales y su seguridad se enfrentan al cada vez ms frecuente y complejo peligro del software malicioso (Malware, en ingls), Malware es un software que tiene como objetivo infiltrarse en o daar un ordenador sin el conocimiento de su dueo y con finalidades muy diversas, ya que en esta categora encontramos desde un troyano_ hasta un Spyware (programas espa)
1.6
breaking Patch (romper y actualizar )
En informtica, un parche es una seleccin de cdigo que se introduce a un programa. Dicho cdigo puede tener varios objetivos: Sustituir
Agregar Aplicar Los parches suelen ser desarrollados por los programadores ajenos al equipo de diseo inicial del proyecto, cualquier tipo de programa, incluso un sistema operativo, suele ser objeto de un parche. Tipos de parches: Parches de depuracin:
Su objetivo de este tipo de parches es reparar bugs, o errores de programacin que no fueron detectados a tiempo en su etapa de desarrollo. Parches de seguridad:
Los parches de seguridad mantienen sin cambio algunos aspectos de funcionalidad de ciertos programas. Se usan frecuentemente en los navegadores Web y se centra a resolver vulnerabilidades de los programas. Parches de actualizacin:
Consiste en modificar un programa para convertirlo en un programa que se utilice metodologas ms nuevas.
1.7
Metas de la seguridad enfocados al software.
1.7.1 Prevencin (antes):

Mecanismos que aumentan la seguridad (o fiabilidad) de un sistema durante su funcionamiento normal. Por ejemplo el cifrado de informacin para posterior transmisin.
1.7.2 Auditable y trazable.

La Auditabilidad es el procedimiento utilizado en la elaboracin de exmenes, demostraciones, verificaciones o comprobaciones del sistema. Estas comprobaciones deben ser peridicas y tales que brinden datos precisos y aporten confianza a la direccin. Deben apuntar a contestar preguntas como: La trazabilidad de productos, personas, documentos, puede realizarse a travs de diferentes medios. Uno de ellos es la biometra, metodologa que permite identificar personas basndose en rasgos fsicos o de comportamiento (huellas digitales, caracteres faciales, lectura de iris, etc.). Trazabilidad es la capacidad que tiene una organizacin o sistema para rastrear, reconstruir o establecer relaciones entre objetos monitoreados, para identificar y analizar situaciones especficas o generales en los mismos. Es importante aclarar que la trazabilidad exige algunas caractersticas bsicas en la arquitectura para lograr rastrear, reconstruir o establecer,:

Sincronizacin Control y aseguramiento de registros de monitoreo Confiabilidad de la generacin de registros de monitoreo
1.7.3 Monitoreo. Desarrollo de tareas de supervisin capaz de controlar resultados de operaciones diversas, programas o funciones especfico por medio de circuitos programados, permitiendo la observacin de un proceso en ejecucin, en funcionamiento, examinando el transcurso del mismo por medio de ciertas variables seleccionadas Es el seguimiento preciso a todas las fases del programa y a los aspectos crticos.
1.7.4 Privacidad y confidencialidad: Es la necesidad de que la informacin solo sea conocida por personas autorizadas. En casos de falta de confidencialidad, la informacin puede provocar severos daos a su dueo (por ejemplo conocer antecedentes mdicos de una persona) o volverse obsoleta (por ejemplo: los planes de desarrollo de un producto que se "filtran" a una empresa competidora, facilitaran a esta ltima desarrollar un producto de caractersticas semejantes). 1.7.5 Seguridad multiniveles Seguridad multinivel (tambin escrito como seguridad de niveles mltiples o abreviado como MLS) es la aplicacin de un sistema informtico para procesar la informacin con diferentes sensibilidades (es decir, a diferentes niveles de seguridad), permitir el acceso simultneo de usuarios con diferentes de seguridad y las necesidades saben, y evitar que los usuarios obtengan acceso a la informacin para los que carecen de autorizacin. El concepto de seguridad multinivel (MLS) que proviene de los sistemas de alta seguridad utilizados en Defensa, donde la informacin es manejada de acuerdo a su nivel de sensibilidad y a los permisos que tiene la persona que desea acceder a ella. 1.7.6 Anonimato: El anonimato es el estado de una persona siendo annima, es decir, que la identidad de dicha persona es desconocida. 1.7.7 Autenticacin: Permite definir que la informacin requerida es vlida y utilizable en tiempo, forma y distribucin. 1.7.8 Integridad Un sistema integro es aquel en el que todas las partes que lo constituyen funcionan en forma correcta y en su totalidad.
1.8
Conocer al enemigo
Las series Conoce a tu enemigo estn escritas para ensear las herramientas, tcticas y motivos de la comunidad blackhat (sombrero negro). Conoce a tu enemigo se centra en cmo puedes detectar estos atacantes, detectar que herramientas estn usando y en que vulnerabilidades se centran. Conoce a tu enemigo se fija en que pasara una vez ellos ganan privilegios de root. Concretamente, como borran sus huellas y que harn a continuacin. Conoce a tu enemigo Resultados forenses cubre como puedes analizar un ataque de ese tipo. Conoce a tu enemigo motivos explica los motivos y la psicologa de algunos miembros de la comunidad blackhat capturando sus comunicaciones. Finalmente. Conoce a tu enemigo Gusanos en la guerra relata como gusanos automatizados atacan sistemas Windows vulnerables. Script Kiddie: El Script Kiddie es alguien que busca una presa fcil.
Como protegerse contra este peligro

Hay medidas que puedes tomar para protegerte contra esta amenaza. Primero, el script kiddie ira por una presa fcil, ellos buscan sistemas con fallos comunes. Asegrate de que tus sistemas y redes no son vulnerables a esos son excelentes fuentes para informarte de lo que es un fallo comn. Tambin, la lista de correo es una de las mejores fuentes de informacin. Otra forma de protegerte a ti mismo es ejecutando solo los servicios que necesites. Si no necesitas un servicio, cirralo/desactvalo. Si lo necesitas, asegrate de que esta actualizado a su ultima versin. Para ver ejemplos de como hacer esto, lee "Blindando Solaris", "Blindando Linux" o "Blindando NT".
1.9
Metas de proyecto de software
Existen diversos tipos de metas la cuales se presentan y definen cada una de ellas: Metas de Gestin de Requerimientos Los requerimientos son controlados para establecer una lnea base para la ingeniera de software y el uso de gestin. Los planes de software, los productos y las actividades se mantienen consistentes con los requerimientos del sistema. Metas de Planificacin de Proyectos Las estimaciones de software son documentadas para su uso en la planificacin y seguimiento del proyecto de software. Se planifican y documentan las actividades y compromisos del proyecto de software. Los grupos e individuos afectados estn de acuerdo con sus compromisos relacionados al proyecto de software. Metas de Seguimiento y Supervisin Los resultados y performance reales son comparados con los planes. Se toman acciones correctivas y se gestionan hasta su cierre cuando los resultados y performance actuales se desvan significativamente de los planes de software. Los cambios a los compromisos son acordados con los grupos e individuos afectados. Metas de Gestin de Subcontratacin de Software El contratista principal selecciona subcontratistas de software calificados. El contratista principal y el subcontratista de software acuerdan sus compromisos entre ellos.
El contratista principal y el subcontratista de software mantienen una comunicacin continua. El contratista principal realiza un seguimiento de los resultados y performance reales del subcontratista de software contra sus compromisos. De esta forma se logra la visibilidad del avance de los proyectos o de las partes de los proyectos que fueron tercerizados. Metas de Aseguramiento de Calidad de Software Las actividades de Aseguramiento de Calidad de Software son planificadas. La adherencia de los productos y actividades de software a los estndares, procedimientos y requerimientos aplicables es verificada. Los grupos e individuos afectados son informados sobre las actividades y resultados de aseguramiento de calidad. Los asuntos de no cumplimiento que no pueden ser resueltos dentro del proyecto de software son diseccionados por la gerencia. Los roles de aseguramiento de calidad se integran a la ejecucin de los proyectos, asegurando de esta forma la calidad de los productos generados. Metas de Gestin de Configuracin de Software Estn disponibles productos de software de trabajo seleccionados, los cuales son identificados y controlados. Se controlan los cambios para identificacin de productos de software de trabajo. Los grupos afectados y las personas son informados sobre el estado y contenido de las lneas base del software.
Unidad II Administracin de los riesgos en la seguridad del software

Objetivo: El alumno conocer e identificar los riesgos que se tienen al poner en prctica la seguridad del software, as como los mecanismos para la evaluacin del desarrollo de sistemas seguros.
Contenido: 2.1 Descripcin de la administracin de los riesgos en la Seguridad del Software 2.2 Administracin de los riesgos en la seguridad del Software en la prctica 2.2.1 Pruebas de Caja Negra 2.2.2 Equipo Rojo 2.3 Criterios Comunes
2.1 Descripcin de la administracin de los riesgos en la Seguridad del Software

Ingeniera de sistema de computacin: Se refiere a la seguridad de informacin comnmente como la proteccin de sistemas de informacin contra el acceso desautorizado o la modificacin de informacin, si esta en una fase de almacenamiento, procesamiento o trnsito. Tambin protege contra la negacin de servicios a usuarios desautorizados y la provisin de servicio a usuarios desautorizados, incluyendo las medidas necesarias para detectar, documentar, y contraer tales amenazas. Confiabilidad del software: Significa que un programa particular debe de seguir funcionando en la presencia de errores. Los errores pueden ser relacionados al diseo, a la implementacin, a la programacin.
Administracin de los riesgos en la Seguridad del Software

Los lectores que ya tengan experiencia en administracin de riesgos de seguridad pueden consultar el captulo rpidamente. Se recomienda que los que tengan poca experiencia en la seguridad o la administracin de riesgos lo lean detenidamente. Informacin general acerca de la administracin de riesgos de seguridad Tambin se ofrece orientacin acerca de cmo prepararse para el proceso mediante un planeamiento eficaz y la creacin de un equipo de administracin de riesgos de seguridad slido con funciones y responsabilidades bien definidas.
Evaluacin de riesgos: Los pasos de esta fase incluyen el planeamiento, la recopilacin de datos facilitados y la asignacin de prioridades a los riesgos. consta de varias tareas, La identificacin y la determinacin de los valores de los activos de negocios pueden durar mucho tiempo Otras tareas, como la identificacin de amenazas y de vulnerabilidades, Los riesgos principales se someten a un anlisis detallado mediante tcnicas cuantitativas. El resultado es una lista breve de los riesgos ms importantes con mtricas detalladas que el equipo puede utiliz ar para tomar decisiones durante la siguiente fase del proceso. Apoyo a la toma de decisiones El equipo de administracin de riesgos de seguridad determina cmo afrontar los riesgos clave del modo ms eficaz. El equipo identifica los controles, determina los costos asociados a la adquisicin, implementacin y soporte de cada control, evala la reduccin del nivel de riesgo que logra cada control y, finalmente, trabaja con seguridad para determinar los controles que se implementarn. El resultado final es un plan claro y aplicable para controlar o aceptar cada uno de los riesgos principales identificados en la fase de evaluacin de riesgos.
2.2 Administracin de los riesgos en la seguridad del Software en la prctica.

Administracin de los riesgos de seguridad Se ofrece orientacin acerca de cmo prepararse para el proceso mediante un planeamiento eficaz y la creacin de un equipo de administracin de riesgos de seguridad slido con funciones y responsabilidades bien definidas. Evaluacin de riesgos: Planeamiento La recopilacin de datos facilitados La asignacin de prioridades de los riesgos. Tareas: La identificacin y la determinacin de los valores de los activos de negocios. La identificacin de amenazas y de vulnerabilidades. Los retos relacionados con estas tareas ilustran la importancia de un planeamiento correcto y de la creacin de un equipo de administracin de riesgos de seguridad Pueden durar mucho tiempo. Apoyo a la toma de decisiones El equipo de administracin de riesgos de seguridad determina cmo afrontar los riesgos del modo ms eficaz y posible. Mide la calidad del programa El resultado final es un plan claro y aplicable para controlar o aceptar cada uno de los riesgos principales identificados en esta fase.
Pruebas Las pruebas son de gran importancia en la garanta de la calidad del software. Los objetivos principales de realizar una prueba son: Detectar un error Tener un buen caso de prueba Descubrir un error no descubierto antes Los mtodos de prueba del software tienen el objetivo de disear pruebas que descubran diferentes tipos de errores con menor tiempo y esfuerzo.
2.2.1 Pruebas de caja negra

Conocido como prueba de comportamiento. La prueba de la caja negra intenta encontrar errores de las siguientes categoras: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin.
Los casos de prueba de la caja negra pretende demostrar que: Las funciones del software son operativas. La entrada se acepta de forma adecuada. Se produce una salida correcta, y La integridad de la informacin externa se mantiene.
Criterios mnimos que guiarn al escoger los datos de prueba: o Valores Fciles. o Valores tpicos realistas. o Valores ilegales. Limitaciones Un programa puede pasar con holgura millones de pruebas y sin embargo tener defectos internos que surgen en el momento ms inoportuno Por ejemplo, un PC que contenga el virus Viernes-13 puede estar pasando pruebas de caja negra durante aos y aos. Slo falla si es viernes y es da 13; pero a quin se le iba a ocurrir hacer esa prueba? Mtodos: Particin equivalente: Una particin equivalente es un mtodo de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos. El diseo de casos de prueba para la particin equivalente se basa en la evaluacin de las clases de equivalencia. Anlisis de valores limite: Nos lleva a elegir las pruebas que nos ejecuten los valores lmite, con esta tcnica se complementa la particin equivalente. Prueba de comparacin: Esta tcnica consiste en la comparacin de salidas de un mismo software pero de sus diferentes versiones
2.2.2 Equipo Rojo

La Agencia de Seguridad Nacional, uno de los organismos ms poderosos del planeta, ayud a mejorar la seguridad de Windows Vista.
La NSA utiliz un equipo azul y otro rojo para analizar el software. El equipo rojo tena el rol de tratar de corromper o robar informacin como si de un "adversario tcnicamente competente y muy decidido" se tratase. El equipo azul ayud a los administradores del departamento de defensa con la configuracin de Windows Vista. Los problemas del grupo rojo son los ms serios y suponen que el sistema est abierto a un atacante potencial, es decir, posee problemas de seguridad conocidos en disposicin de ser explotados. As por ejemplo, un problema de seguridad del grupo rojo es un equipo que tiene el servicio de FTP annimo mal configurado.
2.3 Criterios comunes.
Es un conjunto de normas de seguridad aprobado internacionalmente que proporciona una evaluacin clara y fiable de las capacidades de seguridad en los productos de tecnologa de la informacin. A travs de una evaluacin independiente de la capacidad del producto para cumplir las normativas de seguridad, Criterios comunes proporciona al cliente ms confianza en la seguridad en los productos de tecnologa de la informacin y le permite tomar decisiones ms sopesadas. Los clientes preocupados por la seguridad requieren el cerificado de Criterios comunes como factor determinante para tomar decisiones de compra. El alcance internacional de Criterios comunes, adoptado actualmente en catorce pases, permite a los usuarios de otros pases comprar productos de tecnologa de la informacin con el mismo nivel de confianza ya que el certificado se reconoce en todos los pases que lo cumplen. Evaluar un producto en relacin a la seguridad requiere identificar las necesidades de seguridad del cliente y valorar las capacidades del producto.
Criterios comunes ayuda a los clientes en ambos procesos a travs de dos componentes clave: perfiles de proteccin y evaluacin de niveles de seguridad. Los CC no contienen criterios de evaluacin de la seguridad correspondientes a medidas de seguridad administrativa no relacionadas directamente con las medidas de seguridad de TI. Los CC no tratan ni la metodologa de evaluacin ni el marco administrativo y legal bajo el cual los criterios pueden ser aplicados por las autoridades de evaluacin. Sin embargo, se espera que los CC sean usados para propsitos de evaluacin en el contexto de un determinado marco administrativo y con una determinada metodologa. Los procedimientos para el uso de los resultados de la evaluacin en la acreditacin de productos o sistemas estn fuera del objetivo de los CC.
Unidad III Cdigo abierto o cerrado
Objetivo: El alumno conocer los mecanismos que emplea la industria del software para proteger sus cdigos, tanto de los competidores como de los crackers; as como las ventajas y desventajas del cdigo abierto.
Contenido: 3.1 3.2 3.3 3.4 Seguridad por Oscuridad Ingeniera en Reversa Cdigo Fuente Abierto Falacias del cdigo abierto
3.1 seguridad por oscuridad.
Seguridad: certeza, firmeza, confianza. Sin riesgo. Oscuridad: Puedes estar seguro... de que, al final la vulnerabilidad ser encontrada. Definicin de seguridad por oscuridad: Es un controvertido principio de ingeniera de seguridad, la cual intenta utilizar el secreto para garantizar la seguridad. Un sistema que se apoya en la seguridad por ocultacin puede tener vulnerabilidades de seguridad tericas o prcticas, pero sus propietarios o diseadores creen que estos puntos dbiles no se conocen, y que es probable que los atacantes no los descubran. Argumentos Si la seguridad de un sistema depende nica o principalmente de mantener oculta una debilidad. Se argumenta que permitir a cualquier persona revisar la seguridad repercutir en una pronta identificacin y correccin de cualquier fallo o debilidad.
3.2 Ingeniera inversa

Definicin: Es la actividad que se ocupa de descubrir cmo funciona un programa, funcin o caracterstica de cuyo cdigo fuente no se dispone, hasta el punto de poder modificar ese cdigo. Trata de tomar algo (un dispositivo mecnico o electrnico, un software de computadora, etc.) para analizar su funcionamiento en detalle, generalmente para intentar crear un dispositivo o programa que haga la misma o similar tarea sin copiar la original.
Es denominado ingeniera inversa porque avanza en direccin opuesta a las tareas habituales de ingeniera, que consisten en utilizar datos tcnicos para elaborar un producto determinado. Objetivo: Es obtener informacin a partir de un producto accesible al pblico, con el fin de determinar de qu est hecho, qu lo hace funcionar y cmo fue fabricado. Usos de la ingeniera inversa Suele ser empleada por empresas, para analizar si el producto de su competencia infringe patentes de sus propios productos. En el software y en el hardware, es empleada para desarrollar productos que sean compatibles con otros productos, sin conocer detalles de desarrollo de stos ltimos. Es empleada para comprobar la seguridad de un producto. La gran mayora del software de pago incluye en su licencia una prohibicin expresa de aplicar ingeniera inversa a su cdigo, con el intento de evitar que se pueda modificar su cdigo y que as los usuarios tengan que pagar si quieren usarlo.
3.3 Cdigo fuente abierto.

Cdigo abierto (open source). Definicin: Es el trmino con el que se conoce al software distribuido y desarrollado libremente Open Source centra su atencin en la premisa de que al compartir el cdigo el programa resultante tiende a ser de calidad superior al software propietario. Fue utilizado por primera vez en 1998
Por qu es importante el open source? los programadores en Internet pueden leer, modificar y redistribuir el cdigo fuente de un programa. El software evoluciona, se desarrolla y mejora. Los usuarios lo adaptan a sus necesidades, corrigen sus errores a una velocidad impresionante, mayor a la aplicada en el desarrollo de software convencional o cerrado. Se obtiene la produccin de un mejor software.
Declogo para ser cdigo abierto open source 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Libre redistribucin: Cdigo fuente: Trabajos derivados: Integridad del cdigo fuente del autor: Sin discriminacin de personas o grupos: Sin discriminacin de reas de iniciativa: Distribucin de la licencia: La licencia no debe ser especfica de un producto: La licencia no debe restringir otro software: La licencia debe ser tecnolgicamente neutral:
Caractersticas y ventajas Flexibilidad. Fiabilidad y seguridad. Rapidez de desarrollo. Relacin con el usuario. Libre. Combate efectivamente la piratera de software
Diferencia entre cdigo de fuente abierto & software libre. El Cdigo Fuente Abierto se basa en hacer software confiables y poderosos. Enfatizan los valores prcticos y se garantiza los derechos de modificacin y redistribucin de dichas versiones modificadas del programa. En tanto que el software libre brinda libertad a los usuarios sobre su producto adquirido puede ser usado, copiado, estudiado, modificado y redistribuido libremente. Se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. Ejemplo: VCIUDADES: Es un cdigo abierto velneo Se trata de un desarrollo que incluye una base de datos de ms de 3 millones de ciudades de todo el mundo. Contiene datos de ciudades creados por MaxMind (www.maxmind.com). Cada ficha est compuesta de los siguientes campos: cdigo, nombre, pas, ciudad, latitud y longitud.
Unidad IV Principios guas del software seguro
Objetivo: El alumno conocer e identificar los principios ms importantes que deben estar presentes usando el diseo o construyendo un sistema seguro, evitando los problemas ms comunes de seguridad.
Contenido: 4.1 Principio 1. Reducir las lneas dbiles 4.2 Principio 2. Defensa por pasos o capas 4.3 Principio 3. Seguramente fallar 4.4 Principio 4. Menos privilegios 4.5 Principio 5. Segmentacin 4.6 Principio 6. Mantenerlo simple 4.7 Principio 7. Promover la privaca 4.8 Principio 8. Ocultar secretos es difcil 4.9 Principio 9. Transparentar el cdigo 4.10Principio 10. Usar recursos comunes
4.1 Principio 1 reducir las lneas dbiles

Los intrusos buscan el eslabn mas dbil. Tener un buen anlisis. El programa no siempre es dbil.
4.2 Principio 2 Defensa por pasos o capas

Garantiza que al penetrar el intruso en una de las capas ser detenido en la siguiente capa y deben aplicarse desde el nivel ms bsico al nivel ms complejo. Modelo informtico de red tradicional: Seguridad a nivel de sistema Seguridad a nivel de red Seguridad a nivel de aplicacin seguridad a nivel de transmisin
4.3 Principio 3 Seguramente fallara.

Cualquier sistema suficientemente complejo fallar procurando que eso no suponga un problema de seguridad.
4.4 Principio 4 menos privilegios

Dar el acceso mnimo necesario para la tarea encargada. EJEMPLO: Si alguien nos recoge el correo durante las vacaciones ... >le damos tambin las llaves del piso? Si necesitamos permiso para leer un objeto, no darlo tambin para escribir.
4.5 Principio 5 segmentacin

Consiste en descomponer la ejecucin de cada instruccin en varias etapas para poder empezar a procesar una instruccin diferente en cada una de ellas y trabajar con varias a la vez.
4.6 Principio 6 mantenerlo simple

Concentrar las operaciones crticas de seguridad en Pocos puntos. El diseo y la implementacin debern ser tan sencillos Como se pueda: Diseos complejos son ms difciles de entender. Ms fallos.
4.7 Principio 7 promover la privacia

Tenemos que tratar de no comprometer los datos de nuestros usuarios. EJEMPLO: La mayora de sitios `serios' no guarda nuestra clave, ni el Numero de la tarjeta: Al menos, no mostrarla (nunca entera). Almacenarla cifrada. Almacenarla en otra maquina diferente.
4.8 Principio 8 Ocultar secretos es difcil

A caso cree lo contrario Es necesario que sepas ocultar una informacin confidencial. Se necesita de personales que guarden bien la informacin y que se requiera de toda la confianza.
Hay programas que rechazaba todas aquellas palabras que no tuvieran la longitud exacta de las palabras que probablemente cubran la zona oculta de un documento. Para guardar un secreto es muy difcil decir si. Robar para hacer la identificacin de palabras ocultas mucho ms difcil.
4.9 Principio 9 Transparentar el cdigo

Diseo para transparencia Adems de aplicar toda las tcticas para mantener el cdigo simple se debe pensar en las maneras que el cdigo se va comunicar con los seres humanos. Las cualidades en la reaccin humana al software son esenciales para reducir sus errores y incrementar su mantenibilidad.
4.10
Principio 10 Usar recursos comunes
Uso Aceptable Aquel que demande un gasto adicional para el organismo, excepto el que derive del uso normal de los recursos informticos. Usos Indebidos Acceder al cdigo fuente de una obra de software sin autorizacin explcita del autor (rea de software y aplicaciones) con la finalidad de modificarlo.
Usos Prohibidos Prohibido el uso de cualquier recurso informtico para: Grabar, modificar o borrar software, informacin, bases de datos, que no estn incluidas como tareas propias del usuario.
Unidad V Auditoria de software

Objetivo: El alumno conocer e identificar las etapas que se requieren para poder llevar a cabo la auditoria de software una vez que ste ha sido terminado; as como las herramientas que permiten realizar auditoria al cdigo fuente.
Contenido: 5.1 Definicin de Arquitectura de Seguridad 5.2 Principios de la Arquitectura de Seguridad 5.3 Anlisis de la Arquitectura de Seguridad 5.3.1 Diseo 5.3.2 Implementacin 5.3.3 Automatizacin y pruebas 5.3.4 rboles de Ataque 5.3.5 Reporte del Anlisis 5.4 Implementacin del Anlisis de Seguridad 5.4.2 Auditoria de Cdigo Fuente 5.4.3 Herramientas de Auditoria de Seguridad de Cdigo
5.1 Definicin de Arquitectura de Seguridad Concepto:

La infraestructura tecnolgica requerida para controlar el registro, proceso
almacenamiento y flujo de la informacin de forma segura. Tipos de arquitectura: Seguridad de aplicaciones Seguridad de desarrollo Seguridad del usuario final Requisitos normativos Arquitectura de acceso remoto
5.2
Principios de la Arquitectura de Seguridad
Los principios son leyes naturales de carcter general que actan independientemente a que nosotros tengamos conocimiento o no de ellos, los principios pueden aparecer en la mayora de las doctrinas. Principios: Confidencialidad. Integridad. Disponibilidad. Autenticacin. Autorizacin. Auditabilidad.
A continuacin se definen cada uno de los principios de la arquitectura de seguridad: Confidencialidad: Asegura que solo los individuos autorizados tengan acceso a los recursos que se intercambien.
Integridad: Garantizar que los datos sean los que se suponen que son. Disponibilidad: Garantiza el correcto funcionamiento de los sistemas de informacin Autenticacin: Asegurar que solo los individuos autorizados tengan acceso a los recursos (confirmacin de la entidad de un usuario). Autorizacin: Asegurar que los individuos que accedan a la informacin tienen la suficiente autorizacin para ello. Auditabilidad: Asegurar de que el sistema pueda ser sometido a demostraciones, verificaciones, o comprobaciones con el fin de buscar una mejora.
5.3 Anlisis de la Arquitectura de Seguridad

5.3.1 Diseo Diseo De Entradas Y Salidas Entradas El diseo de entradas consiste en realizar formatos que permitan al usuario introducir datos.; los formatos sern pantallas que simularan que en estas se escribe la informacin. Salidas El diseo de salidas en si, es disear los formatos de salidas comnmente estas pueden ser reportes de resultados
ANALISIS Seleccionar un lenguaje de programacin El lenguaje que se selecciono cumple con los requisitos tales como fcil de manejar y es conocido por el equipo de trabajo, cada cdigo debe ser explicado a los trabajadores o a la persona que tendr uso de este, se tuvo que seleccionar un lenguaje que permitiera que el manejo de este fuera
mas sencillo, adems de que lo mas comn, seria que la persona que se encargara de trabajar con el sistema (usuario), est familiarizado. 5.3.2 Implementacin . En la implementacin se considera siempre la implementacin del software (es decir dentro de la implementacin del sistema de informacin siempre deber implementar el software a utilizarse).Se podran seguir los siguientes pasos: a.- Recopilacin y anlisis de datos b.- Seleccin de datos idneos a ingresarse o utilizarse c.- Ingreso y manipulacin de datos d.- Procesamiento e.- Anlisis de resultados EL OBJETIVO debe ser detectar las debilidades y potencialidades de la organizacin frente al riesgo, en este proceso debe incluir la implantacin y la ejecucin de planes de contingencia y la simulacin de posibles delitos para poder detectar posibles defectos cuanto antes. Sin embargo, todo sistema o aplicacin, independientemente de estas revisiones, debe ser probado mediante su ejecucin controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo del software, se denominan habitualmente pruebas. Las pruebas no comienzan formalmente hasta que un nmero mnimo predeterminado ha instalado el software. En particular, usuarios que tardan en comenzar, generalmente nunca lo hacen y ponen en peligro todo el proceso. En la prctica, pasarn al menos cuatro semanas antes del punto de partida.
5.3.3. Automatizacin de pruebas
Estos programas de prueba sern vlidos para diferentes Versiones de la aplicacin Facilita mejoras en el proceso pruebas
Detecta y previene errores
5.3.4 RBOLES DE ATAQUES
Forma parte de le Seguridad en la etapa de anlisis Anlisis de Riesgo (todos los tipos de riesgos, virus, ataques, etc.)
5.3.5 REPORTE DE ANALISIS

Reporte de Auditoria de Software
.Ingrese la fecha y hora especfica de cada PC, estacin de trabajo, o Server que se visiten para capturar los datos durante la auditoria de software. Resumen de Auditoria de Software
La Plantilla del Resumen de Auditoria de Software est diseada para asistir en la tabulacin de datos, anlisis de resultados e implementacin de acciones correctivas u otros cambios en la utilizacin de software dentro de su organizacin.
5.4
Implementacin del Anlisis de Seguridad
Cuando se habla de utilizar software libre para implementar seguridad en sistemas no se habla, de la utilizacin de software para implementar mecanismos de cifrado (ya sea asimtrico o simtrico) sino de herramientas para implementar la cadena completa de un ciclo de vida (en lo que a seguridad) se refiere de un sistema informtico:
proteccin (o prevencin), deteccin, reaccin (o respuesta) y recuperacin. Evidentemente, es necesario herramientas para cubrir todos y cada uno de estos aspectos, no siendo tiles ninguno de ellos de forma aislada y debiendo combinarse para adaptarse a la poltica de seguridad.
5.4.1 auditoria de cdigo abierto

Mediante la auditoria de cdigo fuente se le pueden proporcionar a empresas que desarrollen su propio software, la facilidad de externalizar las auditorias de cdigo, que permitirn a sus aplicaciones convertirse en software ms seguro y que le garantizarn la eliminacin de gran cantidad de vulnerabilidades conocidas en su cdigo.
5.4.2 Herramientas de Auditoria de seguridad de Cdigo
Esttico = se analiza sin ejecutar el software Ventajas: Consistencia. Apuntan a la causa raz, no a los sntomas. Deteccin precoz. Su ejecucin es barata.
CRITERIOS PARA SELECCIN DE HERRAMIENTAS Tipos de anlisis (AFD, semntico, estructural) Categoras de vulnerabilidades que pueden detectarse Precisin (falsos positivos y negativos) Capacidad de configuracin Calidad de las recomendaciones correctivas Posibilidad de trabajar en modo hbrido Posibilidades de deteccin de defectos de diseo
Ejemplo open-source: OWASP LAPSE

Plugin Eclipse (Java). Muy bsico. Basado en tainting. Detecta vulnerabilidades de tipo inyeccin.
Unidad VI Cdigo seguro

Objetivo: El alumno conocer, identificar y aplicar diferentes lenguajes de programacin que le permitan analizar, disear y desarrollar las diferentes tcnicas de cdigo de seguro.
6.1 Definicin de Cdigo Seguro 6.2 Lenguaje Ensamblador 6.3 Lenguajes de Programacin 6.4 Tcnicas de Cdigo Seguro
6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6 6.4.7 6.4.8
Buffer Overflows Heap Overflows Formato de cadena Exploits Race conditions SQL injection Cross Site & Cross-Domain Scripting Fault Injection
6.1 Definicin de cdigo seguro.

Es un cdigo diseado para soportar ataques de usuarios maliciosos.
6.2 lenguaje ensamblador.

El lenguaje ensamblador es un tipo de lenguaje de bajo nivel utilizado para escribir programas informticos, y constituye la representacin ms directa del cdigo mquina especfico para cada arquitectura de computadoras legible por un programador. Fue usado ampliamente en el pasado para el desarrollo de software, pero actualmente slo se utiliza en contadas ocasiones, especialmente cuando se requiere la manipulacin directa del hardware o se pretenden rendimientos inusuales de los equipos Caractersticas: Programar en lenguaje ensamblador es difcil de aprender, entender, leer, escribir, depurar y mantener, por eso surgi la necesidad de los lenguajes compilados. A pesar de perder rendimiento en un proceso de compilacin, en la actualidad la mayora de las computadoras son suficientemente rpidas. El lenguaje ensamblador no es portable. Programar en lenguaje ensamblador lleva mucho tiempo. Los programas hechos en lenguaje ensamblador son generalmente ms rpidos. Al programar cuidadosamente en lenguaje ensamblador se pueden crear programas de 5 a 10 veces ms rpidos que con lenguajes de alto nivel. Los programas hechos en lenguaje ensamblador generalmente ocupan menos espacio. Un buen programa en lenguaje ensamblador puede ocupar casi la mitad de espacio que su contraparte en lenguaje de alto nivel.
Con el lenguaje ensamblador se pueden crear segmentos de cdigo imposibles de formar en un lenguaje de alto nivel. Ventajas del Ensamblador La primera razn para trabajar con ensamblador es que proporciona la oportunidad de conocer ms a fondo la operacin de su PC, lo que permite el desarrollo de software de una manera ms consistente. La segunda razn es el control total de la PC que se tiene con el uso del mismo. Otra razn es que los programas de ensamblador son ms rpidos, ms compactos y tienen mayor capacidad que los creados en otros lenguajes. Por ltimo el ensamblador permite una optimizacin ideal en los programas tanto en su tamao como en su ejecucin.
6.3 Lenguaje de programacin.

Los lenguajes de programacin son herramientas que nos permiten crear programas y software. Entre ellos tenemos Delphi, Visual Basic, Pascal, Java, etc.. Una computadora funciona bajo control de un programa el cual debe estar almacenado en la unidad de memoria; tales como el disco duro. Los lenguajes de programacin de una computadora en particular se conocen como cdigo de mquinas o lenguaje de mquinas.
Un lenguaje de programacin es un lenguaje que puede ser utilizado para controlar el comportamiento de una mquina, particularmente una computadora. Consiste en un conjunto de smbolos y reglas sintcticas y semnticas que definen su estructura y el significado de sus elementos y expresiones. Un lenguaje de programacin permite a uno o ms programadores especificar de manera precisa: sobre qu datos una computadora debe operar, cmo deben ser estos almacenados, transmitidos y qu acciones debe tomar bajo una variada gama de circunstancias. Todo esto, a travs de un lenguaje que intenta estar relativamente prximo al lenguaje humano o natural, tal como sucede con el lenguaje Lxico. Una caracterstica relevante de los lenguajes de programacin es
precisamente que ms de un programador puedan tener un conjunto comn de instrucciones que puedan ser comprendidas entre ellos para realizar la construccin del programa de forma colaborativa. Clasificacin de los lenguajes de programacin Segn su nivel de abstraccin Lenguajes de bajo nivel Los lenguajes de bajo nivel son lenguajes de programacin que se acercan al funcionamiento de una computadora. El lenguaje de ms bajo nivel es, por excelencia, el cdigo mquina. A ste le sigue el lenguaje ensamblador, ya que al programar en ensamblador se trabajan con los registros de memoria de la computadora de forma directa.
Lenguajes de medio nivel Hay lenguajes de programacin que son considerados por algunos expertos como lenguajes de medio nivel (como es el caso del lenguaje C) al tener ciertas caractersticas que los acercan a los lenguajes de bajo nivel pero teniendo, al mismo tiempo, ciertas cualidades que lo hacen un lenguaje ms cercano al humano y, por tanto, de alto nivel.
Lenguajes de alto nivel Artculo principal: Lenguaje de alto nivel Los lenguajes de alto nivel son normalmente fciles de aprender porque estn formados por elementos de lenguajes naturales, como el ingls. En BASIC, el lenguaje de alto nivel ms conocido, los comandos como "IF CONTADOR = 10 THEN STOP" pueden utilizarse para pedir a la computadora que pare si CONTADOR es igual a 10. Por desgracia para muchas personas esta forma de trabajar es un poco frustrante, dado que a pesar de que las computadoras parecen comprender un lenguaje natural, lo hacen en realidad de una forma rgida y sistemtica.
6.4 Tcnicas de cdigo seguro.
6.4.1 Buffer Overflows.

Una de las mayores vulnerabilidades de seguridad que tienen los actuales sitemas operativos y programas es ser sensibles a un desbordamiento de buffer, o como mejor se les conoce: Buffer Overflows. Bsicamente un desbordamiento de buffer no tiene mucho secreto. Normalmente este fallo se da cuando el programador no tiene en cuenta el tamao de algn buffer dentro de su programa y si este se llena de datos que no tienen salida, afecta a otras partes de la memoria en las cuales hay otros datos o partes de otro programa vindose afectados y pudiendo causar un bloqueo tanto del programa afectado y del propio software que lo produce. El buffer es un espacio contiguo de memoria que se reserva para el almacenamiento de datos.
6.4.2 Heap Overflows.

El heap Overflow es un tipo de buffer Overflow que se produce en un rea de memoria denominada heap. La memoria heap se reserva dinmicamente con funciones como por ejemplo malloc () y puede ser sobreescrita de forma similar a la que se produce en los buffer overflow, es decir, en situaciones en las que el programador no verifica correctamente el tamao de los datos que copia.
6.4.3 Formato de cadena.

Cadena, en informtica, son datos compuestos por una secuencia de caracteres que normalmente representan un texto legible. Es posible que la longitud de una cadena no sea la misma que su tamao mximo asignado. Como consecuencia, algunos lenguajes disponen de formas de controlar la longitud de una cadena, normalmente usando un carcter de delimitacin al final o contando el nmero de caracteres. El formato de cadenas vulnerabilidad ataques se dividen en tres categoras: la denegacin de servicio, la lectura y la escritura.
El formato de cadenas vulnerabilidad ataques de denegacin de servicio se caracterizan por la utilizacin de mltiples instancias del formato% s especificador para leer datos de la pila hasta que el programa intenta leer datos de una direccin ilegal, lo que har que el programa se bloquee. El formato de cadenas vulnerabilidad lectura ataques suelen utilizar el formato% x especificador para imprimir secciones de memoria que normalmente no tienen acceso. El formato de cadenas vulnerabilidad escrito utilizar los ataques% d,% u% x o especificadores de formato para sobreescribir el puntero de instrucciones y la fuerza de ejecucin de usuario suministrado por el cdigo shell.
6.4.4 Exploits.
Un Exploits es un programa o cdigo que "explota" una vulnerabilidad del sistema o de parte de l para aprovechar esta deficiencia en beneficio del creador del mismo. Si bien el cdigo que explota la vulnerabilidad no es un cdigo malicioso en s mismo, generalmente se lo utiliza para otros fines como permitir el acceso a un sistema o como parte de otros malware como gusanos y troyanos. Es decir que actualmente, los Exploits son utilizados como "componente" de otro malware ya que al explotar vulnerabilidades del sistema permite hacer uso de funciones que no estaran permitidas en caso normal.
6.4.5 Race Condition.

Este tipo de vulnerabilidad ocurre cuando un evento se produce fuera del periodo previsto, con un resultado imprevisible. El fallo puede ser utilizado para falsificar la barra de direcciones en la ventana del navegador, mostrando un archivo .SWF desde un sitio web malicioso. Sin embargo, el impacto de este problema se ve reducido porque la direccin (URL) del archivo flash malicioso, es visible como ttulo de la ventana del navegador. La vulnerabilidad ha sido confirmada en un sistema con todas las actualizaciones al da, con Internet Explorer 6.0 y Microsoft Windows XP SP2. Versiones anteriores tambin son afectadas.
6.4.6 SQL Injection.

Inyeccin SQL es una vulnerabilidad informtica en el nivel de la validacin de las entradas a la base de datos de una aplicacin. El origen es el filtrado incorrecto de las variables utilizadas en las partes del programa con cdigo SQL. Es, de hecho, un error de una clase ms general de vulnerabilidades que puede ocurrir en cualquier lenguaje de programacin o de script que est incrustado dentro de otro. Una inyeccin SQL sucede cuando se inserta o "inyecta" un cdigo SQL "invasor" dentro de otro cdigo SQL para alterar su funcionamiento normal, y hacer que se ejecute maliciosamente el cdigo "invasor" en la base de datos. La inyeccin SQL es un problema de seguridad informtica que debe ser tomado en cuenta por el programador para prevenirlo. Un programa hecho con descuido, displicencia, o con ignorancia sobre el problema, podr ser vulnerable y la seguridad del sistema puede quedar ciertamente comprometida. Esto puede suceder tanto en programas corriendo en computadores de escritorio, como en
pginas Web, ya que stas pueden funcionar mediante programas ejecutndose en el servidor que las aloja. La vulnerabilidad puede ocurrir cuando un programa "arma" descuidadamente una sentencia SQL, con parmetros dados por el usuario, para luego hacer una consulta a una base de datos. Dentro de los parmetros dados por el usuario podra venir el cdigo SQL inyectado. Al ejecutarse esa consulta por la base de datos, el cdigo SQL inyectado tambin se ejecutar y podra hacer un sinnmero de cosas, como insertar registros, modificar o eliminar datos, autorizar accesos e, incluso, ejecutar cdigo malicioso en el computador.
6.4.7 Cross Site & Cross-Domain Scripting.

Son una vulnerabilidad que afecta tpicamente a las aplicaciones Web, y que se basa en la insercin de cdigo Web malicioso aprovechando las carencias de filtrado de la Web afectada. La vulnerabilidad "Cross-Domain" (dominio cruzado), permite a un atacante acceder a datos de un dominio diferente. La vulnerabilidad permite engaar al navegador para que un simple cambio en el URI de un sitio, le haga creer que dos pginas de sitios diferentes, parezcan pertenecer al mismo dominio. URI (Uniform Resource Identifier o Identificador Universal de Recursos), es la secuencia de caracteres que identifica cualquier recurso (servicio, pgina, documento, direccin de correo electrnico, etc.) accesible en una red. Consta de dos partes, el identificador del mtodo de acceso o protocolo (http:, ftp:, mailto:, etc.), y el nombre del recurso (//dominio, usuario@dominio, etc.). Un URL (Uniform Resource Locators), es un URI que muestra la localizacin explcita de un recurso (pgina, imagen, etc.). El problema es ocasionado por una incorrecta validacin de la propiedad DOM llamada "location.hostname", lo que favorece el robo (por ejemplo), de cookies de autenticacin de sitios al azar, siempre que el atacante convenza al usuario a visitar un sitio Web malicioso conteniendo una pgina especialmente modificada.
Unidad VII Pruebas de software

Objetivo: El alumno conocer e identificar las fases y los diferentes tipos de
pruebas que se realizan al software.
Contenido: 7.1 Fases de las Pruebas de Software 7.1.1 Modelado del ambiente del software 7.1.2 Seleccin de escenarios de prueba 7.1.3 Ejecucin y evaluacin de los escenarios de prueba 7.1.4 Medicin del progreso de las pruebas 7.2 Prcticas de las Pruebas de Software 7.2.1 Bsicas 7.2.1.1 Especificaciones funcionales 7.2.1.2 Revisin e inspeccin 7.2.1.3 Entrada formal y criterios de salida 7.2.1.4 Prueba funcional 7.2.1.5 Pruebas multiplataforma 7.2.1.6 Ejecucin automatizada de prueba 7.2.1.7 Programas beta 7.2.2 Fundamentales 7.2.2.1 Escenarios de usuario 7.2.2.2 Pruebas de utilidad 7.2.2.3 Requerimientos para la planificacin de la prueba 7.2.2.4 Generacin automatizada de la prueba 7.2.3 Incrementales 7.2.3.1 Cobertura de cdigo 7.2.3.2 Generador de ambiente automatizado 7.2.3.3 Diagrama del estado de la prueba 7.2.3.4 Simulacin de falla en la memoria 7.2.3.5 Pruebas estadsticas 7.2.3.6 Mtodos semiformales
7.2.3.7 7.2.3.8 7.2.3.9
Registro de la prueba para el cdigo Benchmark Generacin de errores (bugs)
7.1 Fases de las Pruebas de Software En la ingeniera del software el trmino fases de desarrollo expresa cmo ha progresado el desarrollo de un software y cunto desarrollo puede requerir. Cada versin importante de un producto pasa generalmente a travs de una etapa en la que se agregan las nuevas caractersticas (etapa alfa), despus una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los bugs importantes (etapa estable). Las etapas intermedias pueden tambin ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los trminos se utilizan a veces de manera informal para describir el estado de un producto. Normalmente muchas compaas usan nombres en clave para las versiones antes del lanzamiento de un producto, aunque el producto y las caractersticas reales son raramente secretas. La fase conocida como pre-alfa se publica a veces antes del lanzamiento de una versin alfa o beta. En contraste con la versin alfa y las versiones beta, la pre-alfa no tiene sus caractersticas completas. Los diseadores todava estn determinando en esta etapa exactamente qu funcionalidades debe tener el producto. Tales etapas se pueden llamar tambin development releases o nightly builds. La versin alfa de un producto es la primera para la que el equipo de desarrollo decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versin del programa que se enva a los verificadores para probarla. Algunos equipos de desarrollo utilizan el trmino alfa informalmente para referirse a una fase donde un producto todava es inestable, aguarda todava a que se eliminen los errores o a la puesta en prctica completa de toda su funcionalidad, pero satisface la mayora de los requisitos. Cuando una versin beta llega a estar disponible para el pblico en general, a menudo es utilizada extensamente por los tecnolgicamente expertos o familiarizados con versiones anteriores, como si el producto estuviera acabado.
Generalmente los desarrolladores de las versiones betas del software gratuito o de cdigo abierto los lanzan al pblico en general, mientras que las versiones betas propietarias van a un grupo relativamente pequeo de probadores. El trmino candidata a definitiva o candidata para el lanzamiento (si traducimos ms literalmente desde el trmino en ingls, release candidata) se refiere a un producto final, preparado para lanzarse como versin definitiva a menos que aparezcan errores que lo impidan. En esta fase el producto implementa todas las funciones del diseo y se encuentra libre de cualquier error que suponga un punto muerto en el desarrollo. Microsoft utiliza frecuentemente este trmino. Otros trminos relacionados incluyen gamma, delta (y tal vez ms letras griegas) para versiones que estn prcticamente completas pero todava en pruebas; y omega para versiones que se creen libres de errores y se hallan en el proceso final de pruebas. Gamma, delta y omega son, respectivamente, la tercera, cuarta y ltima letras del alfabeto griego.
7.1.1 Modelado del ambiente del software

Trabajo con ordenador o computadora, actividad laboral que implica el uso de ordenadores o computadoras. Al trabajo con ordenador se destina hoy gran parte del tiempo laboral. Sin embargo, las facilidades que genera el uso de datos digitales implican para el trabajador nuevas cargas de ndole fsica y anmica. Esta actividad, que el usuario lleva a cabo la mayor parte del tiempo sentado, puede ocasionar daos en la columna vertebral y la musculatura, adems de producir una mala circulacin sangunea, dolores de cabeza y trastornos de la visin. Por otro lado, debido a que la comunicacin y colaboracin entre colegas es poco frecuente, esta situacin puede implicar a largo plazo el aislamiento social. Los trabajos que se llevan a cabo con ordenador deben cumplir determinadas exigencias de seguridad tcnica y de salud laboral. Un puesto informtico correctamente equipado debe constar de monitor (una pantalla de tamao no inferior a 15 pulgadas, no radiactiva, ni deslumbrante, centelleante o mvil), de teclado y ratn (orientado para su manejo, de forma ergonmica y pulsacin suave), y de software o hardware (orientados al dilogo y utilizados de forma satisfactoria). Es muy importante controlar de forma regular la capacidad visual;
por ello es conveniente realizar un examen ocular antes de comenzar a trabajar y llevar a cabo un reconocimiento cada cierto tiempo. La distancia correcta entre la pantalla y el trabajador debe ser entre 45 y 60 cm, y los contrastes del fondo del monitor deben ser ptimos (sin sol, iluminacin indirecta de la habitacin o del techo), mostrando una densidad de luz regulable que evite reflejos y reflexiones. Una mala iluminacin puede provocar malestares fsicos, como dolores musculares y de espalda, excesivo cansancio de los ojos y otros. Segn un decreto de la Unin Europea sobre seguridad y proteccin de la salud ante el trabajo con ordenadores, aprobado el 21 de agosto de 1997, las empresas de ms de diez trabajadores deben cumplir una serie de normativas que hacen referencia al lugar de trabajo (mesa, silla, superficie de trabajo), a las herramientas utilizadas (tipo de monitor y tamao del mismo, teclado, escabel, software), al ambiente de trabajo (iluminacin, acstica, temperatura, humedad del aire) y a la propia habitacin (superficie de movimiento, altura de la habitacin, contacto visual). En la prctica son numerosas las empresas que ignoran esta normativa debido a los costes que generara su puesta en prctica.
7.1 .2 Seleccin de escenario de prueba.

1.-Creando escenarios: Cuando ya tenemos un producto debemos saber a quien se lo queremos vender. Debemos olvidar mercados y hablar de personas. Muchas veces escucho a gente decir, tengo un ERP o un CRM, y ese es mi mercado. No vendemos a mercados vendemos a personas. Caracteriza a la persona a la que le quieres vender. En nuestro caso llegamos a poner una foto de nuestro cliente objetivo con sus caractersticas en la oficina. As no se nos olvida A quin estamos vendiendo? Por tanto crea al menos 5 fichas que definan a la persona a la que le quieres vender. Coloca una foto y al menos 20 caractersticas de cada uno. (Piensa y dale vueltas no lo hagas en un da). 2.-Elige a alguien de tu tamao: No importa cuan pequeo seas lo importante es ser un pez grande en una piscina pequea. Hay una regla que no puede fallar, debes ser capaz de llegar al menos a la mitad del escenario que elijas en el primer ao. Si eres pequeo elige a alguien de tu tamao. 3.- Crea una pgina por cada escenario, y numera cada escenario. Despus y al final realiza una hoja de Excel con todos los datos numricos de todos los escenarios. Nmero de clientes posibles, facturacin, n empleado, todos los campos claves que utilices para definir el escenario.
4.-Haz tormenta de ideas con tu equipo: Debes involucrar a todo el mundo en las valoraciones de los diferentes escenarios, y realiza media de las puntuaciones que haga cada uno. (Ejem: dificultad de venta, instalacin, facilidad de mantenimiento (0 a 5). 5.-Ordena, los resultados por puntuaciones medias y elimina los escenarios que no pasen el primer corte. Repite una votacin privada de los escenarios finales: Vuelve a discutir, puedes introducir ms indicadores de decisin sobre el escenario previsto. Lo importante es que el grupo de trabajo se implique en la decisin final. 6.-Resultado final: Depende los resultados puede pasar los siguientes: a) El grupo est de acuerdo de cual es el escenario adecuado: A por l, sin miramientos, sin dudas, sin arrepentimientos, sin cambios, pelea por conseguir los objetivos marcados. b) El grupo no se pone de acuerdo en el escenario a elegir: Elige a una persona para que desarrolle la teora de bolos y elige el primer bolo de la teora (lo explicar en otro post) c) No hay ningn escenario que supere los mnimos: No trates de crecer, quiz no sea el momento, o el producto no est preparado, o la empresa, sigue vendiendo a early adopters y clientes cercanos hasta que el momento y el escenario correcto se presenten.
7.1.3 Ejecucin y evaluacin de los escenarios de pruebas
La evaluacin educacional se ha desarrollado, ms por razones sociales que educacionales, para facilitar la seleccin social y econmica y no tanto por motivos educacionales propiamente dichos. Sin embargo, recientemente el inters se ha centrado en paliar los efectos negativos de la evaluacin en el sistema escolar y su repercusin individual en los estudiantes, en aras a desarrollar una evaluacin motivadora en el alumnado ms que controladora de sus procesos de aprendizaje. Tambin se debate en la actualidad si la evaluacin muy severa puede conducir a un restrictivo currculo acadmico. Las pruebas de papel y lpiz son muy fciles de aplicar a un amplio nmero de candidatos, y sta es una de las razones que han llevado al desarrollo de la evaluacin, ya que resulta sencillo comprobar a travs de tales procedimientos recuerdo de conocimientos qu habilidades prcticas, comprensin intelectual y desarrollo general personal y social tiene un individuo. Las crticas a este sistema han coincidido con otras referidas a la evaluacin en el aprendizaje, y se considera un sistema competitivo, que produce ms perdedores que ganadores, lo cual acarrea consecuencias muy negativas en la motivacin individual y la autoestima personal. Los psiclogos han comenzado a prestar atencin de nuevo a las diferencias individuales supuestamente fijas e innatas y a considerar que la evaluacin puede incidir en el proceso de aprendizaje para identificar las necesidades y problemas del aprendizaje individual, y poner en evidencia los puntos fuertes y dbiles de los estudiantes, de modo que stos y sus profesores puedan sacar conclusiones para incrementar su competencia y buenos resultados. El futuro de las evaluaciones de los escenarios de pruebas La poltica y la prctica de la evaluacin siempre incluirn transacciones y compromisos. Todo sistema pblico de evaluacin comportar una variedad de consecuencias para los estudiantes, los profesores y los centros, y por ello tendr que ser pblicamente aceptado en trminos de validez y oportunidad. El sistema tendr que demostrar ser el mejor posible, y esto significa incorporar alguna prueba externa o averiguacin de los estndares por otros medios como inspeccin o referencias que crucen los datos de las escuelas.
La abundante investigacin existente en la actualidad referida a la elaboracin de pruebas de evaluacin vlida y fiable, debe ser tenida en cuenta en todas las disciplinas (tanto cientficas como no cientficas).
7.1.4 Medicin de progreso de prueba.

Nuevas Necesidades para Pruebas La necesidad de pruebas nunca haba sido tan grande. A medida que se ha incrementado el ritmo de innovacin, tambin lo ha sido la presin por sacar nuevos productos que hagan una diferencia en el mercado. Las expectativas del consumidor han aumentado: en mercados electrnicos, por ejemplo, se requiere la integracin de funciones en espacios reducidos y a un bajo costo. Los problemas econmicos de los ltimos tres aos no han alterado la curva de innovacin; al contrario, slo han agregado limitaciones en recursos. El cumplir con estas demandas es un factor importante para que un negocio tenga xito; quien sea que cumpla estas demandas; rpido, confiable y consistentemente, tiene la ventaja competitiva del mercado. Todas estas condiciones conllevan a una gran necesidad de validacin, verificacin y pruebas de manufactura. Una plataforma de prueba que pueda mantener este paso no es opcional; es esencial. La plataforma debe incluir herramientas de desarrollo de pruebas rpidas y adaptables a lo largo del flujo de desarrollo del producto. La necesidad de tener productos en volumen y manufacturarlos eficientemente requiere de pruebas efectivas. Para probar los productos multifuncinales y complejos que exige el consumidor, se necesitan mediciones precisas y sincronizadas. Y a medida que se incorporan innovaciones a su producto para diferenciarlo, su sistema de prueba debe adaptarse rpidamente para probar las nuevas caractersticas. La instrumentacin virtual es una solucin innovadora a estos retos: combina el rpido desarrollo de software con el hardware modular y flexible para crear sistemas de prueba definidos por el usuario. La instrumentacin virtual ofrece: Herramientas de software intuitivas para pruebas de desarrollo rpidas; E/S basadas en tecnologas comerciales innovadoras, rpidas y precisas;
Una plataforma basada en PC con sincronizacin integrada para gran exactitud a lo largo del proceso.
Rapidez en el Desarrollo de Software de Prueba A medida que la automatizacin se ha convertido en un requisito para probar rpidamente sistemas complejos, el software se ha convertido en un elemento esencial en todos los sistemas de prueba desde verificacin de diseo hasta pruebas de manufactura automatizadas. Para entregar sistemas de prueba que se adapten a probar nuevas caractersticas rpidamente, se requiere de un conjunto de herramienta de desarrollo de pruebas integradas. Estas pruebas incluyen pruebas de administracin y desarrollo, as como hardware de Entrada/Salida. Las pruebas administradas por software ofrecen un marco para sistemas de prueba altamente automatizados, incluyendo secuencia, ramificaciones / saltos, generacin de reportes e integracin con bases de datos. Esta herramienta tambin proporciona alta integracin con ambientes de desarrollo donde se crean pruebas de aplicaciones especficas. TestStand de National Instruments, ambiente de pruebas administradas lder en la industria, incluye la conectividad a todos los ambientes de desarrollo para pruebas ms comunes, y puede transmitir datos libremente desde y hacia estos ambientes, creando un sistema completamente integrado. El ambiente de desarrollo es el componente ms importante que ayuda a cumplir con la necesidad de ejecutar pruebas rpidamente. Es esencial que este ambiente proporcione las herramientas que permitan desarrollar el cdigo o procedimiento de prueba rpidamente. A travs de los aos, ha emergido una tecnologa de software importante que ofrece desarrollos rpidos y una programacin grfica. sta utiliza conos o funciones simblicas que representan de manera visual la accin que se llevar a cabo. Estos smbolos se encuentran conectados entre s a travs de cables que pasan datos y determinan el orden de ejecucin. Debido a que los procedimientos en pruebas deben verificarse en vez de leerse, el desarrollo y comprensin de la prueba generalmente es rpido. LabVIEW de NI ofrece el ambiente de desarrollo grfico ms completo en la industria. El lenguaje de flujo de datos jerrquico de LabVIEW tambin promueve un alto grado de reutilizacin entre programas de prueba.
El software del controlador de E/S, aunque muchas veces ignorado, es uno de los elementos ms cruciales en la estrategia de desarrollo de pruebas rpidas. Este software proporciona conectividad entre el programa de la prueba y el hardware para medicin y control. Incluye controladores de instrumentos, herramientas de configuracin, y asistentes rpidos de E/S.
E/S Modular
La segunda tecnologa esencial para pruebas son las E/S Modulares. Este hardware reside en un circuito impreso que puede conectarse a una PC o a en un chasis PXI. Un mdulo de E/S utiliza la tecnologa de circuitos integrados comerciales para crear instrumentos virtuales de alto desempeo y bajo costo. Explotar estas tecnologas comerciales altamente utilizadas, como ADCs, DACs, FGPAs y DSPs, ha resultado en un crecimiento en la funcionalidad y el desempeo de los mdulos. La figura 4 muestra el desempeo actual de digitalizadores modulares mostrando su resolucin en bits segn la velocidad de muestreo. En muchos casos la exactitud del instrumento virtual excede la del instrumento tradicional. Plataforma de Prueba Basada en PC Hoy en da, todos los sistemas de prueba modernos incluyen una PC. La PC se ha convertido no slo en parte del sistema, sino en una plataforma de integracin esencial. Procesadores en GHz, buses de alta velocidad, software ampliamente disponible, desempeo en crecimiento constante, y precios extremadamente bajos, hacen de la PC una plataforma de prueba ideal.
7.2 Practicas de las pruebas de software

Las Pruebas de software es el proceso que permiten verificar y revelar la calidad de un producto software. Las Pruebas de software se integran dentro de las diferentes fases del Ciclo del software dentro de la Ingeniera de software. As se ejecuta un programa y mediante tcnicas experimentales se trata de descubrir que errores tiene. La calidad de un sistema software es algo subjetivo que depende del contexto y del objeto que se pretenda conseguir. Para determinar dicho nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema. Las pruebas de software, testing, beta testing es un proceso usado para identificar posibles fallos de implementacin, calidad, o usabilidad de un programa de ordenador o videojuego. Bsicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas. nicamente un proceso de verificacin formal puede probar que no existen defectos. Hay muchos planteamientos a la hora de abordar el testeo de software, pero para verificar productos complejos de forma efectiva requiere de un proceso de investigacin ms que seguir un procedimiento al pie de la letra. Una definicin de "testing" es: proceso de evaluacin de un producto desde un punto de vista crtico, donde el "tester" (persona que realiza el testeo) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reaccin. Por supuesto, nunca se debe testear el software en un entorno de produccin. Es necesario testear los nuevos programas en un entorno de pruebas separado fsicamente del de produccin. Para crear un entorno de pruebas en una mquina independiente de la mquina de produccin es necesario crear las mismas condiciones que en la mquina de produccin. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc...). Esas utilidades reproducen automticamente las bases de datos para simular un entorno de produccin. En general, los informticos distinguen entre errores de programacin (o "bugs") y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programacin puede describirse como un fallo en la semntica de un programa de ordenador. ste podra presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de clculo.
Una prctica comn es que el testeo de un programa sea realizado por un grupo independiente de "testers" al finalizar su desarrollo y antes de sacarlo al mercado. Una prctica que viene siendo muy popular es distribuir de forma gratuita una versin no final del producto para que sean los propios consumidores los que la testeen. En ambos casos, a la versin del producto en pruebas y que es anterior a la versin final (o "master") se denomina beta, y a dicha fase de testeo, beta testing. Puede adems existir una versin anterior en el proceso de desarrollo llamada alpha, en la que el programa, aunque incompleto, dispone de funcionalidad bsica y puede ser testeado. Finalmente y antes de salir al mercado, es cada vez ms habitual que se realice una fase de RTM testing (Release To Market), dnde se comprueba cada funcionalidad del programa completo en entornos de produccin. Otra prctica es que el testeo se realice desde el mismo momento en que empieza el desarrollo y contine hasta que finaliza.
7.2.1 Bsicas.
Verificacin: Consiste en responder a la pregunta: Estamos construyendo el producto correctamente? Dada la especificacin que hemos tomado del usuario Estamos construyendo bien el cdigo? El resultado final del desarrollo software concuerda con la especificacin (requisitos) del sistema? Hay que intentar asegurar que el desarrollo final coincide con dicha especificacin Validacin: Estamos construyendo el producto correcto?
El resultado final del desarrollo software se ajusta a lo que el usuario quera (sus necesidades)? En la mayora de las ocasiones el producto desarrollado no casa con la ideas del cliente, normalmente porque a ste suele faltarle capacidad tcnica de expresin. Cmo llevar a cabo la verificacin y validacin? Mtodos Pruebas del software (Dinmico): consisten en ejecutar comprobando que distintos valores de entrada producen los resultados deseados. Mtodos de inspeccin del software (Esttico): se basan en la revisin de la documentacin, requisitos, incluso cdigo sin ejecutar nada. Esta tarea puede realizarse por un grupo de expertos Por ejemplo. Hay un tipo concreto de mtodos estticos llamados mtodos formales. stos se basan en realizar una especificacin llevada al extremo transformando el software a lenguaje matemtico, donde no quedan ambigedades y el cdigo queda bien especificado.
Otra forma de inspeccin del software es comprobando el cdigo mediante heursticas con algn programa que la aplica (P. ej.- Findbugs).
Pruebas del software
Tipos de prueba (categorizacin)
En la funcin qu conocemos: Pruebas de caja negra: no conocemos la implementacin del cdigo, slo la interfaz. Tan slo podemos probar dando distintos valores a las entradas y salidas.
Pruebas de caja blanca: conocemos el cdigo (la implementacin de ste) que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles caminos del cdigo.
Segn el grado de automatizacin:
Pruebas Manuales: son las que se hacen normalmente al programar o las que ejecuta una persona con la documentacin generada durante la codificacin (P. ej.- comprobar cmo se visualiza el contenido de una pgina Web en dos navegadores diferentes).
Pruebas automticas: se usa un determinado software para sistematizar las pruebas y obtener los resultados de las mismas (P. ej.- verificar un mtodo de ordenacin).
En funcin de que se prueba:

Pruebas unitarias: se aplican a un componente del software. Podemos considerar como componente (elemento indivisible) a una funcin, una clase, una librera, etc.
Pruebas de integracin: consiste en construir el sistema a partir de los distintos componentes y probarlo con todos integrados.
Pruebas funcionales: sobre el sistema funcionando se comprueba que cumple con la especificacin (normalmente a travs de los casos de uso).
Pruebas de rendimientos: tres primeros tipos de pruebas de los que ya se ha hablado comprueban la eficacia del sistema. Las pruebas de rendimiento se basan en comprobar que el sistema puede soportar el volumen de carga definido en la especificacin, es decir, hay que comprobar la eficiencia
Pruebas de aceptacin: son las nicas pruebas que son realizadas por los usuarios, todas las anteriores las lleva a cabo el equipo de desarrollo. Podemos distinguir entre dos pruebas:
Pruebas alfa: las realiza el usuario en presencia de personal de desarrollo del proyecto haciendo uso de una mquina preparada para tal fin.
Pruebas beta: las realiza el usuario despus de que el equipo de desarrollo les entregue una versin casi definitiva del producto.
7.2.1.1 Especificaciones funcionales de software

Una especificacin funcional describe cmo funcionar un producto completamente desde la perspectiva del usuario. No le importa cmo se implemente la cosa. Habla de funciones. Especifica pantallas, mens, dilogos, etctera. Cada vez que se desea construir un sistema no trivial, una especificacin del mismo debera ser dada. Por ejemplo, si lo que se desea construir es un puente entonces diremos que debe tener tantos metros de ancho, tantos de largo, que debe soportar un cierto peso, etc. En la Ingeniera de Software, el trmino es usado en diversos contextos con significados levemente diferentes. En general, podemos decir que una especificacin es una declaracin de un acuerdo entre quien brinda un servicio y el consumidor del mismo. As podemos hablar, por ejemplo de especificaciones de requerimiento cuando el acuerdo es entre el usuario final y el desarrollador del sistema; especificaciones de diseo entre el diseador o arquitecto del sistema y el programador que implementa el diseo. Una especificacin nos puede decir qu queremos que el sistema haga, en el caso de los modelos de Anlisis. Otras veces indican al implementarlo cmo debe hacerlo, como en el caso de las especificaciones de Diseo. Sin embargo, esta divisin a veces no es tan clara. Muchas veces la manera de especificar qu es lo que queremos es por medio de un ejemplo de cmo debera hacerse (lo que no implica necesariamente que deba hacerse de esa forma sino que debe comportarse como si se hiciese as).
7.2.1.2 REVISION E INSPECCION.
Las inspecciones de software surgen a partir de la necesidad de producir software de alta calidad. Algunos grupos de desarrollo creen que la calidad del software es algo en lo que deben preocuparse una vez que se ha generado el cdigo. Error! La garanta de la calidad del software es una actividad de proteccin que se aplica a lo largo de todo el proceso de ingeniera de software. La SQA (Software Quality Assurance) engloba:
Un enfoque de gestin de calidad Tecnologa de Ingeniera de Software efectiva (mtodos y herramientas) Revisiones tcnicas formales que se aplican durante el proceso del software Una estrategia de prueba multiescalada Un control de la documentacin del software y de los cambios realizados Un procedimiento que asegure un ajuste a los estndares de desarrollo de software Mecanismos de medicin y de generacin de informes

El control de la calidad es una serie de revisiones, y pruebas utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. La garanta de calidad o aseguramiento de la calidad consiste en la auditoria y las funciones de informacin de la gestin. El objetivo de la garanta de la calidad es proporcionar la gestin para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms profunda y segura de que la calidad del producto est cumpliendo sus objetivos. Es de esperar, que si los datos proporcionados mediante la garanta de la calidad identifican problemas, la gestin afronte los problemas y aplique los recursos necesarios para resolverlos. La garanta de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes: los ingenieros de software, que realizan trabajo tcnico, y un grupo SQA, que tiene la responsabilidad de la planificacin de garanta de calidad. En ste marco podemos ver a las inspecciones como una implementacin de las revisiones formales del software las cuales representan un filtro para el proceso de ingeniera de software, stas se aplican en varios momentos del desarrollo y sirven para detectar defectos que pueden as ser eliminados. Freeman y Weinberg [Fre90] argumentan de la siguiente forma la necesidad de revisiones: Una revisin es una forma de aprovechar la diversidad de un grupo de personas para: Sealar la necesidad de mejoras en el producto de una sola persona o de un equipo 2. Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.
1.
3. Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud y Completitud principalmente. Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniera del software. Cada una tiene su lugar. Una reunin informal durante el almuerzo o en un caf es una forma de revisin, si se discuten problemas tcnicos. Una presentacin formal de un diseo de software a una audiencia de clientes, ejecutivos y personal tcnico es una forma de revisin. Sin embargo en ste trabajo nos concentraremos en una revisin tcnica formal, que llamaremos Inspeccin de Software
Revisin sistemtica en ingeniera del software La revisin sistemtica es un mtodo de investigacin desarrollado para obtener, analizar, y evaluar toda la investigacin relevante para una pregunta de investigacin o un rea de inters particular [4]. En contraste con una revisin literaria tradicional, una revisin sistemtica sigue una secuencia estricta y bien definida de pasos metodolgicos, que garantizan el alto valor cientfico de los resultados obtenidos. La principal razn para llevar a cabo una revisin sistemtica es incrementar la probabilidad de detectar ms resultados reales en el rea de inters que los obtenidos con una revisin menos formal. Una revisin sistemtica requiere un esfuerzo considerablemente mayor en comparacin con una revisin tradicional, pero este es el precio a pagar por una revisin profunda y completa de un rea de inters determinada.
7.2.1.3 Entrada formal y criterios de salida
Entrada/Salida, desarrollo del software, dos de las tres actividades (entrada, procesamiento y salida) que caracterizan un ordenador o computadora. El trmino entrada/salida (I/O, de Input/Output) engloba las tareas complementarias de obtencin de datos que procesa el microprocesador y de entrega de los resultados a travs de un dispositivo, como la pantalla, la unidad de disco o la impresora. El teclado y el mouse o ratn son dispositivos de entrada que hacen llegar la informacin al ordenador. La pantalla y la impresora son dispositivos de salida con los cuales la computadora hace
llegar sus resultados al usuario. Una unidad de disco es tanto un dispositivo de entrada como de salida, ya que puede proporcionar informacin almacenada o almacenar datos despus de su procesamiento.
Dispositivo de entrada/salida, en informtica, componente de hardware utilizado tanto para proporcionar como para recibir informacin del ordenador o computadora. Un dispositivo de entrada/salida transfiere informacin en las dos direcciones posibles. Una unidad de disco es un ejemplo de dispositivo de entrada/salida. Algunos dispositivos son slo de entrada, por ejemplo un teclado, un mouse o ratn, un lpiz ptico y un joystick o palanca de juegos. Otros sirven slo para la salida de datos (impresoras y monitores). La mayora de los dispositivos requieren la instalacin de rutinas de software denominadas controladores, que permiten el intercambio de informacin entre la computadora y el dispositivo. Vase Controlador de dispositivo.
Para introducir datos se emplean dispositivos muy diversos. La mayora de las computadoras personales incluyen un teclado. El mouse, la bola de seguimiento o trackball y el joystick son otros dispositivos de entrada que permiten sealar, seleccionar y mover objetos en un monitor. Puede introducirse texto manuscrito deslizando por la pantalla, o por una tableta digitalizadora, un lpiz ptico, cuyos sensores convierten los movimientos del usuario en datos electrnicos. Las pantallas tctiles, en las que unos sensores de luz infrarroja localizan los dedos del usuario, se emplean en lugares en los que un teclado resultara poco adecuado. El reconocimiento de voz es muy empleado en algunas aplicaciones, pero estos dispositivos de entrada son todava imperfectos y slo responden a un pequeo vocabulario de instrucciones. Los dispositivos de salida ms habituales son las impresoras y los monitores en color. La salida de audio tambin es corriente, as como las complejas conexiones con sintetizadores que producen una amplia gama de sonidos musicales.
7.2.1.4 PRUEBAS FUNCIONALES.
Una prueba funcional es una prueba basada en la ejecucin, revisin y retroalimentacin de las funcionalidades previamente diseadas para el software. Las pruebas funcionales se hacen mediante el diseo de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informtico.
7.2.1.5 PRUEBAS MULTIPLATAFORMA.
Los intentos de crear virus multiplataforma no son -ni mucho menos- nuevos, pero hoy se comenta en Virus List la prueba de concepto de un virus capaz de infectar tanto ficheros ejecutables de Windows como binarios ejecutables de Linux. De hecho, su nombre lo dice todo: Virus.Linux.Bi.a/ Virus.Win32.Bi.a. El virus est escrito en ensamblador y es relativamente simple. Adems, slo infecta ficheros del directorio en uso. De momento el virus no tiene aplicacin prctica, pero demuestra que es posible crear virus multiplataforma. Es ms: una vez se dispone de pruebas de concepto como sta, la experiencia demuestra que no tarda mucho en aparecer un especmen que aprovecha la idea. Los virus para ambas plataformas continuarn suponiendo una curiosa excepcin ocasional, si bien los usuarios de ambos sistemas operativos, ante cualquier circunstancia e independientemente, debern seguir cada vez ms atentos a las nuevas amenazas.
7.2.1.6 EJECUCION AUTOMATIZADA DE LAS PRUEBAS.
Una herramienta automatizada de la accesibilidad es un pedazo del software que puede probar un Web page, o an de un Web site entero, para la accesibilidad. Free Articles. Las herramientas automatizadas de la accesibilidad son tiles porque pueden ahorrarte una cantidad de tiempo enorme. No desean comprobar las imgenes para saber si hay texto del alt en cada pgina en tu Web site? Funcionar el sitio a travs de un probador automatizado. Las herramientas de prueba automatizadas de la accesibilidad han sido alrededor durante mucho tiempo y han sido histricamente una manera til de comprobar los Web site para saber si hay accesibilidad. Las herramientas de prueba automatizadas de la accesibilidad utilizan generalmente las pautas de la accesibilidad de W3C, que ahora son sobre cinco aos. Como tal, un nmero de estas pautas son anticuadas y no aplican ms. De hecho, algunas de ellas ahora se piensan para obstaculizar accesibilidad ms bien que ayuda, as que es la mejor no hacer caso totalmente de estas pautas. Las herramientas automatizadas de la accesibilidad pueden comprobar para saber si hay un nmero de pautas, y pueden decirte cuando una pauta no se est adhiriendo. Sin embargo, cuando la herramienta demanda que se est satisfaciendo una pauta esto puede de hecho ser una verdad falsa. Las herramientas de prueba automatizadas de la accesibilidad pueden ser tiles mientras que pueden ahorrar una cantidad de tiempo grande en la ejecucin de algunas comprobaciones para muy bsicas accesibilidad. Sin embargo, deben ser utilizadas con la precaucin y no pueden ser utilizadas como gua independiente para la comprobacin de la accesibilidad.
7.2.1.7 PROGRAMAS BETA Cuando la palabra beta se utiliza para referirse a un software, se trata de un trmino corto para beta-test tambin llamada versin beta un periodo donde dicho software est tcnicamente acabado, lo cual significa que no se le aadirn de momento ms funciones, y presumiblemente ser lo suficientemente estable para trabajar con normalidad. En contraste, la versin alfa, lo cual ocurre antes de la versin beta, ms inestable y no est completa. Evaluacin de versiones beta, en informtica, el proceso formal de solicitar informacin y comentarios sobre los resultados del software todava en programacin. En una prueba beta, el software se enva a potenciales clientes seleccionados y usuarios finales influyentes, conocidos como emplazamientos beta (beta sites), probadores beta o betatesters, que prueban la funcionalidad y determinan si el programa todava contiene errores operativos (bugs). Por lo general, el proceso de evaluacin de las pruebas beta es una de las ltimas fases que el programador de software realiza antes de lanzar el producto al mercado. Habitualmente, los betatesters comunican los problemas operativos, los bugs y las sugerencias para realizar mejoras diversas, y es entonces cuando el programador realiza una depuracin ms profunda del programa, con la que proceder a evaluar otra prueba beta; as se trabajar coordinadamente hasta que se considere que el software tiene una calidad que permite su uso o su comercializacin. Este mtodo suele incluir tambin un borrador de la documentacin del producto, que se suministra junto con el software, y de la que el probador beta tambin emite informes acerca de su calidad y exactitud.
Cuando una versin beta llega a estar disponible para el pblico en general, a menudo es utilizada extensamente por los tecnolgicamente expertos o familiarizados con versiones anteriores, como si el producto estuviera acabado. Generalmente los desarrolladores de las versiones betas del software gratuito o de cdigo abierto los lanzan al pblico en general, mientras que las versiones betas propietarias van a un grupo relativamente pequeo de probadores. Hay betas que son realmente software por testear, y otros que, simplemente, son etiquetados como beta por los programadores por miedo a que puedan contener algn error. La beta es un comodn, haces algo si arriesgarte a que te critiquen por
algn bug o problema que cause tu software. La gente que no es "asidua" a la informtica evita las betas, pero los que conocemos un poco este mundo sabemos que da una extrema libertad al creador. Si vas a probar un software beta en tu PC, lo aconsejable sera primero enterarse por Internet de los posibles problemas que pueden causar en nuestro equipo. No suele ser habitual, pero ciertos programas de este estilo pueden causar daos severos en nuestro ordenador, como borrar informacin y hacer que se quede colgado. Por ello, no es mala idea hacer un backup de todo lo importante que tengamos en nuestro equipo antes de instalarnos una versin beta, siempre que sepamos de antemano que no es daino.
7.2.2 FUNDAMENTALES
El software ser fundamental para los nuevos servicios que traer la telefona mvil y Microsoft est trabajando para garantizar la interoperatibilidad de los sistemas. En un encuentro informativo, Solana afirm que la plataforma Windows Mobile ser el eje sobre el que gire toda la estrategia de movilidad de Microsoft para este ao y que es una de las reas fundamentales para esta multinacional. Se trata de facilitar el acceso universal a la informacin y la creacin de nuevos servicios, aplicaciones y dispositivos mviles. El software es el que har inteligente al dispositivo mvil que tendr que poder utilizarse tanto cuando est en disposicin de ser utilizado para hablar o cuando est apagado como puede ser en un avin.
7.2.2.1 ESCENARIO DE USUARIOS. En estos escenarios, el administrador desea controlar las aplicaciones que un usuario puede instalar y ejecutar. Al utilizar una directiva de restriccin de software, los administradores controlan qu aplicaciones pueden instalar los usuarios con sus niveles de permiso habituales. El Servicio de informacin de aplicaciones (AIS, Application Information Service) es un nuevo servicio de Microsoft Windows Vista que implementa Proteccin de cuentas de usuario (UAP, User Account Protection). Al requerir que los usuarios ejecuten el programa en modo de usuario protegido y al limitar el acceso de administrador slo a procesos autorizados, UAP ayuda a reducir el impacto del software malintencionado, los kits de raz, el cdigo daino y los virus. Tambin permite a las organizaciones acercarse a un escritorio administrado para detener la instalacin de aplicaciones no autorizadas por parte de usuarios y cambios involuntarios en la configuracin del sistema. Usuario avanzado, en informtica, persona experta en computadoras, particularmente en la gestin de aplicaciones, ms que en programacin o en el mantenimiento de hardware. Un usuario avanzado es alguien que dispone de slidos conocimientos informticos y puede trabajar con las funciones ms complejas de las aplicaciones. A menudo, estn especialmente familiarizados con un tipo especfico de aplicacin, como las hojas de clculo o los procesadores de textos, y pueden explotar al mximo sus capacidades.
REPASO DE LOS ESCENARIOS DE PRUEBA: Para probar una directiva de restriccin de software y la interaccin con AIS, se requiere que un usuario del dominio inicie la sesin en un equipo cliente de Windows Vista con UAP habilitado y que intente instalar, ejecutar y desinstalar una aplicacin permitida y una no permitida, segn lo defina la directiva del dominio. Escenario 1: Solicite al usuario del dominio que intente instalar una aplicacin permitida. El usuario debera poder instalar la aplicacin sin que se le soliciten credenciales de admin1. Para instalar una aplicacin permitida:
Escenario 2: Intente instalar una aplicacin que el administrador del dominio no haya permitido instalar explcitamente mediante una directiva. El usuario no debera poder instalar la aplicacin. Escenario 3: Intente ejecutar una aplicacin que el administrador del dominio haya permitido que los usuarios ejecuten. El usuario debera poder ejecutar la aplicacin. Para ejecutar una aplicacin permitida Escenario 4: Intente ejecutar una aplicacin que el administrador de dominio no haya permitido que los usuarios ejecuten. El usuario no debera poder ejecutar la aplicacin. Para intentar ejecutar una aplicacin no permitida: Escenario 5: Intente desinstalar una aplicacin que el administrador del dominio haya permitido que los usuarios puedan desinstalar. Nota Esta prueba examina la interaccin del Servicio de informacin de aplicaciones y que el objeto de la directiva del dominio permite a los usuarios quitar aplicaciones sin la necesidad de utilizar credenciales administrativas. En este caso, se aplica configuracin de directivas del dominio para permitir al usuario instalar, actualizar y desinstalar aplicaciones.
7.2.2.2
Pruebas de utilidad
Utilidad (informtica), programa diseado para realizar una funcin de mantenimiento del ordenador o computadora, de una aplicacin o de un entorno de desarrollo. Son ejemplos de utilidades los programas para recuperar datos perdidos o borrados accidentalmente en el disco duro, los que permiten comparar el contenido de dos documentos o los depuradores de cdigo. El trmino utilidad se refiere normalmente al software que resuelve problemas limitados o problemas relacionados con la administracin del sistema de la computadora.
Caractersticas La utilidad tiene seis capacidades bsicas. 1. Prueba la funcionalidad de los componentes principales en los sistemas compatibles 2. Tecnologa del procesador Intel Centrino determinar la funcionalidad en base al estado de los componentes principales 3. Muestra un resumen de los resultados de la prueba 4. Genera un informe de resultados si los componentes fallan 5. Brinda una gua en la resolucin de errores (en el sitio web) 6. Proporciona actualizaciones de la utilidad (en el sitio web) 1. Prueba la funcionalidad de los componentes principales en los sistemas compatibles La utilidad prueba el sistema de destino para determinar la presencia y funcionalidad de los componentes principales requeridos por Centrino tecnologa del procesador. Los componentes principales son el procesador, el chipset y el adaptador inalmbrico. En cada uno de los tres componentes, la utilidad comprueba que el componente compatible est presente y que funciona adecuadamente. Si no se encuentra un componente compatible en el sistema o si se encuentra uno pero ste no funciona, falla la prueba del componente. 2. Determine si Intel Centrino funciona a plenitud tecnologa del procesador En base a los resultados de las pruebas de los componentes principales, la utilidad determina si tecnologa del procesador Intel Centrino funciona a plenitud en el sistema de destino. Solamente cuando todas las tres pruebas de los componentes principales devuelven resultados satisfactorios, la utilidad determina que Intel Centrino funciona a plenitud tecnologa del procesador en el sistema de destino. Si falla alguna de las pruebas de los tres componentes principales, la utilidad determina que se Intel Centrino tecnologa del procesador no funciona a plenitud. 3. Muestra un resumen de los resultados de las pruebas A medida que las pruebas se completan en cada uno de los tres componentes, la
utilidad muestra los resultados de las pruebas en la pantalla de resultados. Al completar todas las pruebas, la utilidad indica si ha determinado que Centrino tecnologa del procesador funciona a plenitud, en la pantalla de resultados. 4. Genera un informe de resultados si los componentes fallan En caso de fallos en las pruebas de los componentes principales, la utilidad crea un informe de resultados. Tenga en cuenta: el informe de resultados solamente se crea si falla al menos una de las pruebas de los componentes principales falla. Puede utilizar el informe para comunicar los resultados de las pruebas al proveedor. 5. Brinda una gua en la resolucin de errores En caso de errores en las pruebas de los componentes principales, se recomienda a los clientes que se comuniquen con el proveedor o fabricante, a fin de realizar pruebas, diagnsticos y resoluciones ms detallados. 6. Proporciona actualizaciones de la utilidad Debido a la introduccin constante de sistemas nuevos, la utilidad debe actualizarse con frecuencia.
7.2.2.3 Requerimientos para la planificacin de la prueba.
Las pruebas del sistema Si bien en la prctica los trminos se manejan en forma intercambiable, tcnicamente debemos distinguir entre las pruebas del software completo (pruebas de verificacin de requerimientos) y las pruebas del sistema que incorpora el software (pruebas del sistema o pruebas de validacin del sistema).
En el contexto de este curso atenderemos fundamentalmente las pruebas de verificacin. El objetivo de las pruebas de verificacin es buscar discrepancias entre los requerimientos y la ejecucin del software. Recuerde, de Sistemas de Programas, que probar es la actividad dedicada a encontrar posibles defectos en un producto, no es determinar que un producto funcione. [Por qu? Repasar barrera psicolgica: el tester como mdico diagnosticante]. El proceso de verificacin de los requerimientos comienza con el anlisis de esos requerimientos y una inspeccin en la cual se busca evaluar la consistencia, completitud y factibilidad de los requerimientos, tanto individualmente como juntos. Adicionalmente los requerimientos deben ser revisados y validados por los distintos actores involucrados con el sistema (stakeholders), accin que debe aclarar los compromisos al respecto, tanto en el sentido de trade-offs (prioridades y balance) entre requerimientos como en el sentido de commitments (compromisos que asumen los actores). Para evitar sorpresas de variada ndole a la hora de entregar el software, es conveniente especificar claramente qu vamos a hacer para determinar que el sistema satisface sus requerimientos. Por ejemplo, no basta con decir que un sistema ser amigable o fcil de usar, cmo se medir o verificar que el software es amigable? Estas especificaciones son cruciales a la hora de disear las pruebas de verificacin. Note que el diseo de estas pruebas requiere los siguientes pasos: 1. Revisar la verificabilidad del requerimiento; 2. Especificar el criterio de verificacin; 3. Hacer visible las propiedades o elementos del software necesarios para verificar el cumplimiento del requerimiento; 4. Hacer controlable los elementos del software necesarios para llevar a cabo las pruebas; 5. Elaborar el plan de pruebas; 6. Ejecutar el plan de pruebas y reportar sus resultados.
Verificabilidad como requerimiento? Es un tipo de requerimiento de un sistema. De acuerdo con el grado de verificabilidad que se desea obtener puede incrementarse o disminuirse la cantidad de software de soporte necesario para llevar a cabo las pruebas (p. ej. arneses de prueba, orculos, manejadores). En mi opinin, la verificabilidad en abstracto no existe, siempre es respecto a uno o ms requerimientos. Un software es verificable respecto a un requerimiento en la medida que:
1. Las propiedades del software relevantes al requerimiento sean visibles al
ejecutar ese software (observabilidad); 2. Puede controlarse la ejecucin del software para explorar el dominio del requerimiento (controlabilidad). Cundo comenzar el proceso de pruebas de validacin? La respuesta ms moderna es tan pronto como sea posible. [Por qu? Porque el anlisis de la verificabilidad de los requerimientos y la elaboracin de los casos de prueba son buenas formas de revisar los requerimientos y de detectar, de manera temprana, problemas con ellos.
7.2.2.4 Generacin automatizada de la prueba.

Medicin y Dispositivos de E/S Fundamentalmente, existen dos tipos de arquitecturas de medicin hoy da tradicional y virtual. La Figura 4 ilustra las similitudes de estas dos arquitecturas. Ambas tienen hardware de medicin, un chasis, fuente de potencia, un procesador, un SO, y una interfase para el usuario. La diferencia ms obvia desde el punto de vista del hardware es cmo estn empacados los componentes. Un instrumento individual o tradicional, pone todos los componentes en una caja para cada instrumento discreto. La funcionalidad de medicin, anlisis, desplegados y control de instrumentos se define por el proveedor. En contraste, los instrumentos virtuales modulares definidos por software incorporan hardware de medicin general que ayuda a usuarios a ir ms
all de las capacidades estndar y definir sus propias mediciones e interfases de usuario en el software. Bus de Cmputo y Medicin En el centro de cada sistema de prueba automatizado hoy da esta una computadora en forma de escritorio, estacin de trabajo, laptop, o computadoras incluidas como se utiliza en PXI y VXI. Un aspecto importante de la plataforma de cmputo utilizada, es la habilidad para conectarse (y comunicarse) con una amplia variedad de instrumentos en un sistema de prueba. Existen varios buses de instrumentacin diferentes disponibles para instrumentos individuales y modulares incluyendo GPIB, USB, LAN, PCI, y PCI Express. Estos buses tienen diferentes fortalezas haciendo una ms aptas para ciertas aplicaciones que otros. Por ejemplo, el GPIB tiene la adopcin ms amplia para control de instrumentos y una amplia disponibilidad de instrumentacin; el USB proporciona una amplia disponibilidad, fcil conectividad, y alto procesamiento; LAN resulta mejor para sistemas distribuidos; y el PCI Express proporciona el mayor desempeo. Servicios de Medicin y Control Los servicios de medicin y control juegan un papel importante al proporcionar conectividad con varios activos del hardware en el sistema, configuracin del sistema, y herramientas de diagnstico. Por ejemplo, el Measurement & Automation Explorer de NI (MAX) detecta automticamente los activos del hardware incluyendo hardware de adquisicin de datos y condicionamiento de seales; instrumentos controlados por GPIB, USB, y LAN; sistemas PXI; dispositivos VXI; e instrumentacin modular para que desarrolladores puedan configurarlos en un solo lugar. Las pruebas de diagnstico integradas aseguran que el dispositivo funcione apropiadamente, y las capas de prueba proporcionan una forma rpida para revisar la funcionalidad del hardware antes de que los desarrolladores inicien la programacin de instrumentos.
Software de Desarrollo de Aplicacin
El entorno de desarrollo de aplicacin (ADE), como LabVIEW y LabWindows/CVI de National Instruments, juegan un papel crtico en las arquitecturas del sistema de prueba. Con estas herramientas, los desarrolladores del sistema de prueba pueden comunicarse a una variedad de instrumentos, integrar mediciones, desplegar informacin, conectarse con otras aplicaciones, y mucho ms. Idealmente, el (los) ADE(s) utilizados para desarrollar aplicaciones de prueba y medicin proporcionan facilidad de uso, compilacin de desarrollos, integracin de un conjunto diverso de E/S, y flexibilidad de programacin para cubrir requerimientos para un amplio rango de aplicaciones. La facilidad de uso va ms all de qu tan rpido se configura y ejecuta. Con la facilidad de uso de los ADEs, desarrolladores pueden fcilmente integrar rutinas de procesamiento con mltiples dispositivos de medicin, crear interfases para el usuario sofisticadas, desplegar y mantener aplicaciones, y modificar la aplicacin a medida que evoluciona el diseo de productos y se expanden las necesidades del sistema. Administracin de Software para el Sistema de Prueba Un sistema de prueba automatizado requiere de la implementacin de varias tareas y funciones de medicin algunas especficas al dispositivo bajo prueba (DUT) y otras repetidas para cada dispositivo probado. Para minimizar los costos de mantenimientos y asegurar la longevidad del sistema de prueba, es importante implementar una estrategia de prueba que separe las tareas de nivel DUT de las tareas a nivel sistema para que ingenieros puedan rpidamente usar nuevamente, mantener y cambiar programar de prueba (o mdulos) creados a travs del ciclo de desarrollo para cubrir requerimientos de prueba especficos.
7.2.3 Incrementales
7.2.3.1 Cobertura de cdigos.
La efectividad de las pruebas se puede medir lnea por lnea o incluso bloque por bloque. Para ello, las ejecuciones de prueba se configuran de modo que generen datos de cobertura de cdigo. Los datos resultantes se muestran en la ventana Resultados de la cobertura de cdigo y en los archivos de cdigo fuente. Se recopilan datos de cobertura de cdigo cuando se han instrumentado artefactos, normalmente archivos binarios, y se cargan en memoria durante una ejecucin de prueba. El procedimiento Obtener datos de cobertura de cdigo describe cmo seleccionar un archivo para instrumentacin. Obtener datos de cobertura de cdigo Para obtener datos de cobertura de cdigo 1. Cree pruebas para el cdigo. Pueden ser pruebas unitarias o de otro tipo, que utilicen cdigo para el que se dispone de smbolos y para el que se hayan seleccionado los binarios apropiados para instrumentar. Para obtener informacin acerca de cmo crear pruebas unitarias, vea Cmo: Generar una prueba unitaria. 2. Abra la configuracin de la ejecucin de prueba que se va a utilizar para las pruebas unitarias. Para obtener ms informacin, vea Cmo: Especificar la configuracin de una ejecucin de prueba. 3. Haga clic en Cobertura de cdigo. 4. En Seleccionar artefactos para instrumento, seleccione el archivo DLL, el archivo ejecutable o el directorio de su solucin. Por ejemplo, si su solucin se denomina ClassLibrary1, active la casilla de verificacin correspondiente al ensamblado denominado ClassLibrary1.dll cuya ruta de acceso es <Directorio de la solucin>\ClassLibrary1\bin\Debug. 5. Haga clic en Aplicar y, a continuacin, haga clic en Cerrar.
6. Ejecute una o ms pruebas. Para obtener seleccionadas. ms informacin, vea Cmo: Ejecutar las pruebas
Mientras se ejecutan las pruebas, se recopilan datos de cobertura de cdigo. Para obtener informacin acerca de la visualizacin de esta informacin, vea Ver los datos de cobertura de cdigo. No pueden recopilarse datos de cobertura de cdigo para una aplicacin que se ejecuta en un proceso de 64 bits. Por lo tanto, cuando solicite datos de cobertura de cdigo mientas prueba una aplicacin de este tipo, el motor de pruebas establecer el indicador "32BIT" en el encabezado del archivo ejecutable potable (PE) del ensamblado que se va a instrumentar. Una vez completada la ejecucin de prueba, el ensamblado volver a su estado original. Para cambiar la presentacin de los datos de cobertura de cdigo 1. Haga clic en Herramientas y, a continuacin, en Opciones. Aparecer el cuadro de dilogo Opciones. 2. Expanda Entorno. 3. Haga clic en Fuentes y colores. 4. En Mostrar valores para, seleccione Editor de texto. 5. En Mostrar elementos, seleccione el rea de cobertura de cdigo cuyo color de presentacin desea cambiar. Las opciones son rea de cobertura no modificada, rea de cobertura modificada parcialmente y rea de cobertura modificada. 6. Cambie la configuracin para esta rea de cobertura de cdigo. Puede cambiar los colores de primer plano y de fondo y la fuente, el tamao de fuente y el grosor del texto. 7. (Opcional) Cambie la configuracin para otras reas de cobertura de cdigo. 8. Cuando termine, haga clic en Aceptar.
7.2.3.2 generadores del ambiente automatizado. Al disear sistemas de prueba automatizadas, resulta clave la maximizacin de exactitud. Determinar cmo maximizar la exactitud, puede resultar difcil. La mayora de los ingenieros de prueba tornan su mirada a las hojas de datos para los instrumentos que estn evaluando con la esperanza de que estos documentos proporcionen todas las respuestas. Sin embargo, otros factores son igualmente importantes en la maximizacin de la exactitud de sus sistemas de prueba automatizados. Este documento le proporciona cinco estrategias puede usted puede seguir para maximizar la exactitud de sus sistemas de prueba automatizados. Las cinco estrategias son las siguientes: Comprender las Especificaciones del Instrumento Al evaluar la exactitud de un instrumento, la hoja de datos resulta un recurso valioso. Sin embargo, resulta importante comprender que los diferentes vendedores de instrumentos con frecuencia especifican la exactitud de medida utilizando ya sea diferente terminologa o terminologa similar con diferentes significados. Por tanto, es importante tener en claro todos los parmetros involucrados en definir las caractersticas de un instrumento. Con frecuencia, los trminos de resolucin, precisin, y exactitud son indistintamente utilizados, pero en realidad indican entidades muy diferentes, Aunque el sentido comn indica que un multmetro digital (DMM) de 6 dgitos debe tener exactamente un nivel de 6 dgitos, lo cual no siempre es el caso. El nmero de dgitos pueden simplemente relacionarse con el nmero de figuras que el medidor puede desplegar y no con el mnimo cambio distinguible en la entrada. Si usted requiere verificar que la sensitividad del instrumento y resolucin efectiva son suficientes para garantizar que el instrumento le otorgar la resolucin de medida que requiere. Considerar Requerimientos de Calibracin A pesar de la exactitud de los instrumentos que usted selecciona para sus sistemas de prueba automatizados, es importante darse cuenta que las exactitudes de los componentes electrnicos utilizados en todos los instrumentos cambian a travs del tiempo. Los efectos del tiempo en el servicio as como condiciones ambientales, se incorporan a este cambio. A medida que pasa el tiempo, los cambios en los valores del componente causan mayor incertidumbre
en sus medidas. Para resolver este conflicto, sus instrumentos deben calibrarse a intervalos regulares.
La calibracin externa es una comparacin del desempeo de instrumentos a un estndar de exactitud conocida. El resultado de una calibracin externa puede ser la documentacin que muestra la desviacin de una medida de un estndar conocido, pero con mayor frecuencia tambin incluye el ajustar la capacidad de medida para asegurar que su exactitud en medida est dentro de los lmites proporcionados por el vendedor. Para calibrar un instrumento de forma externa, puede regresarlo al vendedor, o puede enviarlo a un laboratorio de calibracin o de metrologa. Adicionalmente, puede usted tener capacidades de calibracin externa en sus instalaciones. Sin importar cmo va a calibrar sus instrumentos de manera externa, resulta importante reconocer que los intervalos de calibracin externa para un tipo de instrumento en particular no es siempre el mismo para los diferentes vendedores. Un vendedor puede tener un intervalo de calibracin externa de un ao para un generador de funciones, mientras que otro vendedor puede ofrecer un intervalo de calibracin externa de dos aos, para un generador de funciones con mejores o iguales especificaciones. Aunada a la calibracin externa, los instrumentos para algunos vendedores incluyen la funcin de calibracin automtica. Los instrumentos que ofrecen calibracin automtica incluyen recursos de hardware como las referencias de voltaje de precisin para que pueda usted rpidamente calibrar el instrumento sin removerlo del sistema de prueba o conectarlo al hardware de calibracin externa. La calibracin automtica no representa reemplazar la calibracin externa, pero si proporciona un mtodo para mejorar la exactitud de medida del instrumento entre intervalos de calibracin externos. Monitoree el Sistema Operativo No todos los instrumentos tienen las mismas especificaciones ambientales. La temperatura de operacin y almacenamiento y especificaciones de humedad relativa pueden variar segn el vendedor. Sus sistemas de prueba automatizadas pueden encontrarse en un ambiente de oficina donde la temperatura y humedad
estn altamente controladas, pero puede haber una fbrica u otra instalacin industrial. Mnimo, deben considerarse las especificaciones ambientales para sus instrumentos y comprender cmo stas, pueden afectar la exactitud en las medidas. Utilice la Configuracin Apropiada Conectar su sistema de prueba automatizado al dispositivo bajo prueba (DUT) puede ser tan simple como conectar cables entre instrumentos hacia una caja de escape o terminales de refuerzo y conectarlas al DUT para sistemas con menor de 50 puntos de prueba o bien, solo algunos instrumentos. Para grandes sistemas con cientos de puntos de prueba, mltiples instrumentos, requerimientos del sistema reconfigurables, y/o conexiones/desconexiones frecuentes, usualmente se requiere de un acercamiento como lo es un sistema de interconexin de masas.
7.2.3.3 diagrama del estado de la prueba. Los diagramas de estado describen grficamente los eventos y los estados de los objetos. Los diagramas de estado son tiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso. Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condicin de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transicin es una relacin entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente. En UML, los estados se representan mediante valos. Las transiciones se representan mediante flechas con el nombre del evento respectivo. Se acostumbra poner un estado inicial (crculo negro).
Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren, sus transiciones, y los estados que median entre estos eventos. En particular, es til hacer diagramas de estado para describir la secuencia permitida de eventos en los casos de uso. Por ejemplo, en el caso de uso comprar Productos no est permitido efectuar pago Tarjeta mientras no haya ocurrido el evento terminar Venta. Un diagrama de estado que describe los eventos globales del sistema y su secuencia en un caso de uso es un diagrama de estado para casos de uso.
7.2.3.4 SIMULACION DE FALLA EN LA MEMORIA Un simulador de principios bsicos de una central consiste en un conjunto de programas que resuelven numricamente y en tiempo real las ecuaciones que gobiernan el comportamiento dinmico de la planta simulada. Este tipo de herramientas es utilizado, principalmente en la primera fase del entrenamiento del personal de operacin de la central para facilitar a los mismos una representacin mental de los fenmenos fsicos que gobiernan la planta, adems de ser utilizados como una herramienta de aprendizaje de las tcnicas de control. Se usan igualmente para entrenamiento de estudiantes o profesionales, e incluso pueden ser utilizados por operadores ya experimentados para mejorar su rendimiento frente a situaciones anormales de operacin o de accidentes que eventualmente pudieren ocurrir. La simulacin se basa en un modelo construido segn los principios bsicos de la arquitectura de estos sistemas. El simulador, denominado
SMPCache, posee una interfaz grfica completa y funciona en un entorno PC bajo Windows 98 ( 95). Al principio, el simulador fue concebido como una herramienta para la enseanza de las memorias cachs en multiprocesadores. Sin embargo, la potencialidad del sistema desarrollado ha probado su utilidad para el anlisis de programas y estrategias de diseo de sistemas de memoria en multiprocesadores. As, el simulador puede ser utilizado para comprender el diseo de organizaciones que ejecuten de forma ptima un determinado tipo de programas paralelos o para mejorar el modo de operar de una arquitectura paralela concreta. Interfaz grfica del simulador. El simulador permite establecer la configuracin de los parmetros que definen la arquitectura del sistema, ofrecindonos la respuesta del mismo al someterlo a los accesos de memoria generados por los programas. Caractersticas del simulador Es una herramienta software para la evaluacin de sistemas jerrquicos de memorias cachs en smps con memoria compartida por bus, que opera. Sobre una plataforma pc con sistema operativo windows 98 ( 95), y ha sido escrito utilizando un lenguaje visual. smpcache ofrece una interfaz grfica. Tpica de windows, disponiendo adems de una ayuda contextual muy completa.
7.2.3.5 PRUEBAS ESTATICAS Cmo incorporar revisiones e inspecciones peridicas Tiempo y recursos requeridos para la especificacin y diseo del test Testing de especificaciones y diseo: mtodos nonexecution- based. Estrategias de prueba de integracin: Mtricas y anlisis de resultados

Revisiones de Requerimientos Inspecciones de Cdigo Revisiones de Diseo Prueba de Empaquetamiento
VERIFICACIN VS VALIDACIN
Verificacin Pruebas estticas (sin ejecucin) Revisiones Validacin Pruebas dinmicas (con ejecucin) Pruebas
Objetivo: obtener un sistema de calidad Identificar defectos, errores y problemas Clasificacin de problemas
Revisiones Formales Informales
Validacin (Pruebas)
Objetivo: confirmar la calidad del sistema. Pruebas de unidad Pruebas de integracin Pruebas del sistema Pruebas de aceptacin Modos Caja blanca Caja negra
Medida de la calidad Mtodos cuantitativos (mtricas) Mtodos cualitativos Aplicadas a: Proceso de ingeniera Producto (software)
7.2.3.6 METODOS SEMI-FORMALES.
Los denominados mtodos semiformales representan una aproximacin muy interesante para la correcta comprensin de los mtodos formales por que representan transiciones suaves hacia los mtodos formales. Mtodos Generalitas. Dentro de los mtodos de desarrollo de software generalitas destaca. Sus principales aportaciones son:
A) El concepto de sistema, modelo y vista y, sobre todo, B) La clarividencia a la hora de distinguir entre modelos del mundo real, modelos de software y la relacin entre ambos, C) La capacidad de sopesar entre correccin y utilidad y
D) La integracin entre notaciones formales como Z y semi-formales como los. Mtodos orientados al desarrollo de sistemas reactivos. Dentro de los mtodos orientados al desarrollo de sistemas reactivos destaca. Aunque no se puede considerar como un mtodo orientado a objetos de plena naturaleza, representa una excelente base para comprender y desarrollar este tipo de sistemas.
Sus principales aportaciones son:
a) Integracin de lenguajes de modelado tales como diagramas de actividad, modulares, lenguaje natural,
b) Concepcin de sistema descrito a base de vistas y
c) base transformacional en sus producciones.
Mtodos orientados al desarrollo de componentes. Dentro de los mtodos orientados a desarrollo de componentes destaca. Sus principales aportaciones son: a) Modelado mediante integracin de UML y OCL (lgica de primer Orden orientada a objetos),
b) Integracin del uso de patrones de diseo en el mtodo y
C) construccin de componentes desde especificaciones con distintos grados de abstraccin.

7.2.3.7 REGISTRO DE LA PRUEBA PARA EL CODIGO
Es una prctica de programacin que involucra otras dos prcticas: Escribir las pruebas primero (Test First Development) y Refactorizacin (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en ingls). Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el cdigo que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el cdigo escrito. El propsito del desarrollo guiado por pruebas es lograr un cdigo limpio que funcione. La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizar que los requerimientos se hayan implementado correctamente. El principal objetivo de este cdigo es proponer unos principios de aplicacin universal a lo que se conoce como "pruebas de usuario".
Estas pruebas son una herramienta esencial para la investigacin de la interaccin persona ordenador, y tambin dentro del campo que ha venido a llamarse "usabilidad". Siempre que dichas pruebas se realicen con personas, normalmente, pero no necesariamente, usuarios ajenos al desarrollo de productos de tecnologa, debemos cumplir con unas normas que van ms all de las tradicionales de cortesa, puesto que estamos pidiendo a los usuarios tareas que les requieren cierto esfuerzo, y, adems de querer recoger con la mxima validez sus opiniones y emociones, es un objetivo esencial que los participantes tengan la mejor experiencia posible de las pruebas para que en el futuro deseen volver a participar en las mismas.
7.2.3.8 BENCHMARK
El benchmark es una tcnica utilizada para medir el rendimiento de un sistema o componente de un sistema, frecuentemente en comparacin con el cual se refiere especficamente a la accin de ejecutar un benchmark. La palabra benchmark es un anglicismo traducible al castellano como comparativa. Si bien tambin puede encontrarse esta palabra haciendo referencia al significado original en la lengua, es en el campo informtico donde su uso est ms ampliamente extendido. Ms formalmente puede entenderse que un benchmark es el resultado de la ejecucin de un programa informtico. O un conjunto de programas en una mquina, con el objetivo de estimar el rendimiento de un elemento concreto o la totalidad de la misma, y poder comparar los resultados con mquinas similares. En trminos de ordenadores, un benchmark podra ser realizado en cualquiera de sus componentes, ya sea CPU, RAM, tarjeta grfica, etc. Tambin puede ser dirigido especficamente a una funcin dentro de un componente, por ejemplo, la unidad de coma flotante de la CPU; o incluso a otros programas. Tambin puede realizarse un "benchmark de software", es decir comparar el rendimiento de un software contra otro o de parte del mismo, por ejemplo, comparar distintas consultas a una base de datos para saber cul es la ms rpida o directamente partes de cdigo. El Benchmark es tambin un proceso continuo de medir productos, servicios y prcticas contra competidores ms duros o aquellas compaas reconocidas como lderes en la industria. Cualidades benchmark Los benchmark tienen las siguientes funcionalidades:

Comprobar si las especificaciones de los componentes estn dentro del margen propio del mismo Maximizar el rendimiento con un presupuesto dado Minimizar costes manteniendo un nivel mnimo de rendimiento Obtener la mejor relacin costo/beneficio (con un presupuesto o unas exigencias dadas) ayuda a lograr una posicin ms competitiva
Tipos de benchmarks Dado el rendimiento objetivo, existen diferentes tipos de benchmark: Sintticos & Aplicaciones Sintticos: estn especialmente diseadas para medir el rendimiento de un componente individual de un ordenador, normalmente llevando el componente escogido a su mxima capacidad. Aplicaciones: herramientas basadas en aplicaciones reales, simulan una carga de trabajo para medir el comportamiento global del equipo.
Bajo nivel & Alto nivel Test de Bajo nivel: Miden directamente el rendimiento de los componentes Ejemplo: el reloj de la CPU, los tiempos de la DRAM y de la cach SRAM, tiempo de acceso medio al disco duro, latencia, tiempo de cambio de pista, etc. Test de Alto nivel:
Estn ms enfocados a medir el rendimiento de la combinacin componente/controlador/SO de un aspecto especfico del sistema, como por ejemplo el rendimiento de E/S con ficheros, o el rendimiento de una determinada combinacin de componentes/controlador/SO/aplicacin. Ejemplo: Velocidad de compresin zip.
7.2.3.9 GENERACION DE ERRORES (BUGS)

Definiciones de Bugs en la web: El trmino Bugs puede referirse a: En informtica, a un Error de software. Bugs,
El vocabulario informtico dedicado a los problemas y errores destaca esta palabra, con larga tradicin. Un bugs. Es un mal funcionamiento de un elemento de software: que un programa haga cosas no queridas, o que no haga las cosas que debera. Errores en Generacin Tras la generacin del modificado nos aparecer la siguiente ventana donde se detallarn los diferentes errores que se han encontrado en la generacin del mismo. Estos errores se clasifican en "Advertencias" o "Errores" dependiendo de la influencia que tenga sobre la definicin del vial. En el primero de los casos el vial se ha generado y en el segundo ha sido imposible la composicin del mismo en el Pk especificado. A continuacin se muestra la ventana que nos aparece tras la generacin del mismo. En el listado aparece el informe de errores y en la parte inferior las diferentes formas de clasificarlos. Errores: Muestra en el listado solamente los errores encontrados en la generacin. Advertencias: En este caso slo muestra las advertencias. Resumen: Muestra el listado agrupado por que tienen la misma incidencia. Detallado: Lista los errores encontrados en cada uno de los del segmento. Si activamos el botn Revisar (slo en el caso de que est activada la opcin Detallado), se activar el comando correspondiente al error encontrado, existiendo la posibilidad de realizar las modificaciones oportunas. Despus si accionamos el botn Regenerar calcular el nuevo segmento. Seguidamente se muestra un listado de los diferentes errores posibles que nos podemos encontrar as como la categora de los mismos.
Unidad VIII Derechos de autor en Mxico (software)

Objetivo: El alumno conocer y aprender cmo proteger y registrar un programa de cmputo En Mxico a travs la Ley Federal del Derecho de Autor. Contenido: 8.1 Ley Federal del Derecho de Autor (LFDA) en Mxico 8.1.1 Definicin 8.1.2 Artculos para la proteccin jurdica del software 8.2.3 Derechos que se confieren a travs de la LFDA 8.1.3.1 Derechos morales 8.1.3.2 Derechos patrimoniales 8.2. Instituto Nacional del Derecho de Autor (INDAUTOR) 8.2.1 Definicin 8.2.2 Ubicacin del INDAUTOR 8.3 Direccin General de Asuntos Jurdicos de la UNAM (DGAJ) 8.3.1 Definicin 8.3.2 Relacin con el INDAUTOR 8.3.3 Ubicacin de la DGAJ 8.4 Registro del software 8.4.1 Procedimiento y requerimientos para registrar software en el INDAUTOR. 8.4.2 Procedimiento y requerimientos para registrar software en la DGAJ. 8.4.3 Ventajas y desventajas al registrar software 8.5 Violacin a los Derechos de Autor 8.6 Leyes que brindan proteccin jurdica al software en caso de violacin. 8.7 Sociedades de Gestin Colectiva 8.7.1 Qu es una Sociedad de Gestin Colectiva? 8.7.2 Procedimiento y requerimientos para registrar una Sociedad de Gestin Colectiva. 8.7.3 Obligaciones y privilegios al formar parte de una Sociedad de Gestin Colectiva.
8.1 Ley federal del derecho del autor (lfda) en Mxico.

8.1.1 Definicin. El derecho de autor es un conjunto de normas y principios que regulan los derechos morales y patrimoniales que la ley concede a los autores (los derechos de autor), por el solo hecho de la creacin de una obra literaria, artstica o cientfica, tanto publicada o que todava no se haya publicado. Tiene por objeto la salvaguarda y promocin del acervo cultural de la nacin; proteccin de los derechos de los autores, de los artistas intrpretes o ejecutantes, as como de los editores, de los productores y de los organismos de radiodifusin, en relacin con sus obras literarias o artsticas en todas sus manifestaciones, sus interpretaciones o ejecuciones, sus ediciones, sus fonogramas o videogramas, sus emisiones, as como de los otros derechos de propiedad intelectual.
8.1.2Articulos para la proteccin jurdica del software.

(REGLAMENTARIA DE LA FRACCIN XI DEL ARTCULO 13 DE LA LEY FEDERAL DE DERECHOS DE AUTOR). CAPTULO I: DISPOSICIONES GENERALES. Artculo 1.- Para efectos de la presente ley, se entiende por programa de computacin la expresin original en cualquier forma, lenguaje o cdigo, de un conjunto de instrucciones que, con una secuencia, estructura y organizacin determinada, tiene como propsito que una computadora o dispositivo realice una tarea o funcin especfica. Tendrn igual significado y connotacin, para los efectos de sistematizacin del presente ordenamiento jurdico, los siguientes trminos: a) "programa de cmputo", b) "programa de computacin", c) "programa para computadora", o d) "software".
Artculo 2.- La proteccin a los derechos de autor de programas de computacin queda sujeta a lo previsto en la presente ley. A falta de disposicin expresa, se estar a las prevenciones de la Ley Federal de Derechos de Autor. Artculo 3.- La proteccin a que se refiere esta ley, se extiende tanto a los programas operativos como a los programas aplicativos, ya sea en forma de cdigo fuente o de cdigo objeto. Se exceptan aquellos programas de cmputo que tengan por objeto causar efectos nocivos a otros programas o equipos. Artculo 4.- Para efectos de la presente ley, un programa de computadora ser considerado similar a otro cuando cumpla las condiciones siguientes: I. Ser funcionalmente equivalente, considerando que debe: a) Ser original y desarrollado de manera independiente. b) Tener, fundamentalmente, las mismas caractersticas de desempeo, considerando el tipo de aplicacin a que est destinado. c) Operar en equipo similar y en un ambiente de procesamiento similar. II. Ejecutar substancialmente las mismas funciones, considerando el tipo de aplicacin al que est destinado y las caractersticas del mercado nacional. III. Presentar analogas en cuanto a los parmetros relevantes, incluyendo los numricamente mensurables, los requisitos de memoria, tiempo de procesamiento y capacidad de transaccin entre usuarios y sistemas. Artculo 5.- Por lanzamiento se entender el momento en que el autor programa lo utiliza o pone a disposicin de otro. del
Queda asegurada la tutela de los derechos relativos a los programas para computadora por un plazo de 25 (veinticinco) aos, contados a partir de su lanzamiento en cualquier pas. Los derechos atribuidos por la presente Ley a los extranjeros con domicilio en el exterior, quedan asegurados siempre que el pas de origen del programa mantenga reciprocidad con Mxico, y conceda derechos equivalentes en extensin y duracin a los establecidos en el prrafo anterior del presente artculo.
Artculo 6.- Salvo pacto en contrario, los derechos patrimoniales relativos al programa para computadora, desarrollado y elaborado durante la vigencia del contrato o del vnculo estatutario, expresamente destinado a la investigacin y desarrollo, o donde est prevista la actividad del empleado, funcionario o prestador de servicios, o que pertenezca a la propia naturaleza de los encargos contratados, pertenecern exclusivamente al empleador o contratante de servicios. Salvo clusula en contrario, la compensacin del trabajo o servicio prestado se limitar a la remuneracin o salario convenido. Los derechos concernientes al programa para computadora creado sin relacin al contrato de trabajo, vnculo estatutario o prestacin de servicios, y sin utilizar recursos, informaciones tecnolgicas, materiales, instalaciones o equipos del empleador o contratante de servicios, pertenecern con exclusividad al creador de dicho software. Artculo 7.- Cuando se estipule en contrato firmado entre las partes, los derechos sobre las modificaciones tecnolgicas y derivaciones, pertenecern a la persona autorizada que las haga, y que los ejercer autnomamente. Artculo 8.- El plazo de la cesin de derechos en materia de informtica no est sujeto a limitacin alguna; excepto en los casos en que no exista estipulacin expresa, y siendo as toda transmisin de derechos patrimoniales se considerar por el trmino de 5 aos, pudiendo pactarse por ms de 15 aos cuando la magnitud de la inversin as lo justifique. Artculo 9.- No constituirn ofensa al derecho de autor de un programa de cmputo: I. La reproduccin de una copia legtimamente adquirida, siempre que sea indispensable para la utilizacin adecuada del programa. II. La citacin parcial para fines didcticos, siempre que se identifiquen el autor y el programa referido. III. La semejanza entre un programa y otro ya existente, siempre que la misma est causada por las caractersticas funcionales de su aplicacin, por la observacin de los preceptos legales, reglamentarios o de normas tcnicas o de la limitacin de la forma alternativa para su expresin.
IV. La integracin de un programa, con todas sus caractersticas esenciales, a un sistema aplicativo u operacional, tcnicamente indispensable para las necesidades del usuario siempre que sea para uso exclusivo de quien lo promovi.
Captulo II: DE LA INSCRIPCIN DEL PROGRAMA DE CMPUTO
Artculo 10.- Los programas de cmputo sern inscritos en el Registro Nacional de Programas de Cmputo, creado al efecto. Para llevar a cabo la comercializacin de un programa de computacin, ser necesaria la inscripcin del programa o conjunto de programas bajo las siguientes categoras de clasificacin, las cuales debern ser proporcionadas por el interesado junto con el pedido de inscripcin y aprobadas por el Registro:
I. Por su procedencia: a) Nacionales: a aquellos creados y producidos en nuestro pas. b) Internacionales: los creados y producidos en cualquier otro pas del extranjero. c) Mixto: aquellos creados en asociacin de nacionales e internacionales. II. Por sus componentes: a) De comando. b) Ejecutables. c) De complemento para aplicaciones. d) De control de perifricos o drives. e) De sistema. f) De datos. III. Por su estado de desarrollo:
a) Core code o cdigo base. b) Demoware o programa de demostracin. c) Versiones beta o programas de prueba. d) Software V 1.0.0. o programa comercializable. IV. Por su destino: a) De investigacin y cientfico. b) Industrial. c) Gubernamental. d) Entretenimiento. e) Empresarial. f) Uso domstico.
Los dems programas de cmputo que, por analoga, puedan considerarse innovadores dentro de su medio, se incluirn dentro de las clasificaciones que les sean ms afines a su naturaleza. Los procedimientos operacionales sern regulados por el Reglamento del Registro Nacional de Programas de Cmputo.
Artculo 11.- La aprobacin de los actos y contratos referidos en la presente Ley por parte de la Direccin General del Derecho de Autor y la inscripcin del programa de cmputo, son condiciones previas y esenciales para: I. La validez y eficacia de cualquier tipo de negocio jurdico relacionado con software. II. La produccin de efectos fiscales, as como la legitimacin de pagos, crditos o remesas correspondientes, cuando sea el caso, sin perjuicio de otros requisitos y condiciones establecidas por ley.
Artculo 12.- La inscripcin de programas de computadora quedar sin efecto, en cualquier momento: I. Por sentencia judicial tramitada en juzgado. II. Por acto administrativo, cuando quede comprobado que las informaciones presentadas por el interesado para presentar su pedido de registro no fueran verdicas.
Artculo 13.- Las acciones de nulidad del registro podrn ser intentadas por cualquier interesado, ya sea particular o cualquier dependencia gubernamental.
Artculo 14.- Para solicitar un pedido de registro de programa de cmputo, el autor deber presentar las siguientes informaciones: I. Ttulo del programa para computadora. II. Nombre civil, fecha de nacimiento, nacionalidad y domicilio del autor. III. Fecha de terminacin del programa para computadora. IV. Indicacin de la fecha y lugar del lanzamiento del programa. V. En el caso de un software resultante de modificaciones tecnolgicas y derivaciones, indicacin del programa que modifica o del que deriva, acompaando en este caso, el documento de autorizacin. VI. Indicacin de que el programa fue desarrollado por un particular, empleado, funcionario o prestador de servicios. VII. Indicacin de los lenguajes de programacin utilizados en el desarrollo del programa de cmputo. Adems, en cualquier caso de solicitud de registro de programa para computadora, el requiriente deber presentar los elementos esenciales para
caracterizar la creacin independiente e identificar el programa, de manera que permita la lectura directamente por el hombre.
Artculo 15.- No estarn sujetos a inscripcin, aquellos programas de cmputo: I. Importados por el usuario final para su uso exclusivo, en la forma de copia nica. II. Importados por el usuario final para su uso exclusivo, en asociacin a mquinas, equipos y dispositivos basados en tcnica digital. III. Residentes e integrados en mquinas, equipos y dispositivos basados en tcnica digital, siempre que esos programas no sean comercializados de manera separada de los productos que los contengan.
Artculo 16.- Los programas de cmputo podrn ser inscritos de manera colectiva cuando constituyan un conjunto de programas destinados a una aplicacin especfica, recibiendo en este caso, un nico nmero de orden en el Registro Pblico del Derecho de Autor.
Artculo 17.- La versin de un programa ya registrado deber ser tambin inscrita cuando presente caractersticas funcionales y condiciones de comercializacin diferentes de la versin anterior.
Artculo 18.- La Direccin General del Derecho de Autor permitir el acceso a las informaciones de inters pblico que consten en el Registro de programas para computadora; siendo dichas informaciones las que a continuacin se enumeran:
a) Nombre del programa de cmputo. b) Descripcin funcional de dicho programa. c) Nombre y domicilio del titular de la comercializacin en el pas.
d) Clasificaciones dentro de las que podra encuadrarse. e) Categora, nmero de orden de registro y su validez. f) Ambiente de procesamiento g) Plazo de validez tcnica establecido por el titular de los derechos de comercializacin en el pas.
Artculo 19.- Cuando la transferencia de tecnologa haya sido resuelta de comn acuerdo entre las partes, se har necesario registrar los respectivos actos y contratos en el Instituto Mexicano de Propiedad Industrial (IMPI).
En los casos de programas de cmputo destinados a la aplicacin en reas de relevante inters estratgico o econmico, la Direccin General del Derecho de Autor podr condicionar el registro de los actos o contratos a la transferencia de la tecnologa correspondiente.
Artculo 20.- Con el objeto de la creacin y posterior financiamiento del Fondo Nacional de Informtica (FNI), el 8% (ocho por ciento) de las erogaciones por costo de inscripcin de programas de cmputo en el Registro Pblico del Derecho de Autor sern destinadas a dicho Fondo.
8.1.3 Derechos que se confieren a travs de la lfda. 8.1.3.1 Derechos morales.

Articulo 18 El autor es el nico, primigenio y perpetuo titular de los derechos morales sobre las obras de su creacin. Articulo 19 El derecho moral se considera unido al autor y es inalienable, imprescriptible, irrenunciable e inembargable. Articulo 20 Corresponde el ejercicio del derecho moral, al propio creador de la obra y a sus herederos. en ausencia de estos, o bien en caso de obras del dominio publico, annimas o de las protegidas por el titulo vii de la presente ley, el estado los ejercera conforme al articulo siguiente, siempre y cuando se trate de obras de interes para el patrimonio cultural nacional. Articulo 21 Los titulares de los derechos morales podran en todo tiempo: i. determinar si su obra ha de ser divulgada y en que forma, o la de mantenerla inedita; ii. exigir el reconocimiento de su calidad de autor respecto de la obra por el creada y la de disponer que su divulgacion se efectue como obra anonima o seudonima; iii. exigir respeto a la obra, oponiendose a cualquier deformacion, mutilacion u otra modificacion de ella, asi como a toda accion o atentado a la misma que cause demerito de ella o perjuicio a la reputacion de su autor; iv. modificar su obra; v. retirar su obra del comercio, y
vi. oponerse a que se le atribuya al autor una obra que no es de su creacion. cualquier persona a quien se pretenda atribuir una obra que no sea de su creacion podra ejercer la facultad a que se refiere esta fraccion. los herederos solo podran ejercer las facultades establecidas en las fracciones i, ii, iii y vi del presente articulo y el estado, en su caso, solo podra hacerlo respecto de las establecidas en las fracciones iii y vi del presente articulo. articulo 22 salvo pacto en contrario entre los coautores, el director o realizador de la obra, tiene el ejercicio de los derechos morales sobre la obra audiovisual en su conjunto, sin perjuicio de los que correspondan a los demas coautores en relacion con sus respectivas contribuciones, ni de los que puede ejercer el productor de conformidad con la presente ley y de lo establecido por su articulo 99. articulo 23 salvo pacto en contrario, se entiende que los autores que aporten obras para su utilizacion en anuncios publicitarios o de propaganda, han autorizado la omision del credito autoral durante la utilizacion o explotacion de las mismas, sin que esto implique renuncia a los derechos morales.
8.1.3.2 Derechos patrimoniales.

articulo 24 en virtud del derecho patrimonial, corresponde al autor el derecho de explotar de manera exclusiva sus obras, o de autorizar a otros su explotacion, en cualquier forma, dentro de los limites que establece la presente ley y sin menoscabo de la titularidad de los derechos morales a que se refiere el artculo 21 de la misma. articulo 25 es titular del derecho patrimonial el autor, heredero o el adquirente por cualquier titulo. articulo 26
el autor es el titular originario del derecho patrimonial y sus herederos o causahabientes por cualquier titulo seran considerados titulares derivados. articulo 27 los titulares de los derechos patrimoniales podran autorizar o prohibir: i. la reproduccin, publicacin, edicin o fijacin material de una obra en copias o ejemplares, efectuada por cualquier medio ya sea impreso, fonogrfico, grafico, plstico, audiovisual, electrnico u otro similar; ii. la comunicacin publica de su obra a travs de cualquiera de las siguientes maneras: a) la representacin, recitacin y ejecucin publica en el caso de las obras literarias y artsticas; b) la exhibicin publica por cualquier medio o procedimiento, en el caso de obras literarias y artsticas, y c) el acceso pblico por medio de la telecomunicacin; iii. la transmisin publica o radiodifusin de sus obras, en cualquier modalidad, incluyendo la transmisin o retransmisin de las obras por: a) cable; b) fibra ptica; c) microondas; d) va satlite, o e) cualquier otro medio anlogo; iv. la distribucin de la obra, incluyendo la venta u otras formas de transmisin de la propiedad de los soportes materiales que la contengan, as como cualquier forma de transmisin de uso o explotacin. Cuando la distribucin se lleve a cabo mediante venta, este derecho de oposicin se entender agotado efectuada la primera venta, salvo en el caso expresamente contemplado en el artculo 104 de esta ley;
v. la importacin al territorio nacional de copias de la obra hechas sin su autorizacin; vi. la divulgacin de obras derivadas, en cualquiera de sus modalidades, tales como la traduccin, adaptacin, parfrasis, arreglos y transformaciones, y vii. cualquier utilizacin pblica de la obra salvo en los casos expresamente establecidos en esta ley. Articulo 28 las facultades a las que se refiere el artculo anterior, son independientes entre si y cada una de las modalidades de explotacin tambin lo son. Articulo 29 Los derechos patrimoniales estarn vigentes durante: i. la vida del autor y, a partir de su muerte, setenta y cinco aos ms. Cuando la obra le pertenezca a varios coautores los setenta y cinco aos se contaran a partir de la muerte del ltimo, y ii. setenta y cinco aos despues de divulgadas: a) las obras pstumas, siempre y cuando la divulgacin se realice dentro del periodo de proteccin a que se refiere la fraccin i, y b) las obras hechas al servicio oficial de la federacin, las entidades federativas o los municipios. Si el titular del derecho patrimonial distinto del autor muere sin herederos la facultad de explotar o autorizar la explotacin de la obra corresponder al autor y, a falta de este, corresponder al estado por conducto del instituto, quien respetara los derechos adquiridos por terceros con anterioridad. Pasados los trminos previstos en las fracciones de este articulo, la obra pasara al dominio pblico.
8.2 Instituto nacional del derecho de autor (indautor).

8.2.1 Definicin.
La autoridad administrativa encargada del derecho de autor en Mxico es el Instituto Nacional del Derecho de Autor (INDAUTOR), un rgano desconcentrado de la Secretara de Educacin Pblica (SEP) con funciones y facultades. El INDAUTOR qued establecido a travs del decreto publicado en el Diario Oficial de la Federacin del 24 de diciembre de 1996. Su ley, la Federal del Derecho de Autor, entr en vigor el 24 de marzo de 1997. En su artculo 1 se seala que Se tiene por objeto la salvaguarda y promocin del acervo cultural de la Nacin; la proteccin de los derechos de los autores, de los artistas intrpretes o ejecutantes, as como de los editores, los productores y los organismos de radiodifusin, en relacin con sus obras literarias o artsticas en todas sus manifestaciones, sus interpretaciones o ejecuciones, sus ediciones, sus fonogramas o videogramas, sus emisiones, as como de los otros derechos de propiedad intelectual. En su artculo 2 se establece que sus disposiciones son de orden pblico, inters social y observancia general en todo el territorio nacional. Se agrega que su aplicacin administrativa corresponde al Ejecutivo Federal por conducto del Instituto Nacional del Derecho de Autor y, en los casos previstos por esta Ley, al Instituto Mexicano de la Propiedad Industrial (IMPI). Dentro de los servicios que ofrece el Instituto Nacional del Derecho de Autor se encuentran registros como el ISBN (International Standard Book Number); ISSN (International Standard Serial Number), y la reserva de derechos al uso exclusivo del ttulo.
8.2.2 Ubicacin del indautor.

El Instituto Nacional del Derecho de Autor se encuentra localizado en la calle de Dinamarca No. 84, Colonia Jurez, Delegacin Cuauhtmoc, Cdigo Postal 06600.
8.3 Direccin general de asuntos juridicos de la unam. 8.3.1 Definicin.

La Direccin General de Asuntos Jurdicos provee asesora y consultora jurdica en general, as como la defensa de los intereses jurdicos y patrimoniales de la Secretara de Salud y del Sector coordinado por sta, a su peticin. Es el que se encarga de proporcionar servicios jurdicos de calidad. Orientados a la satisfaccin del usuario, a travs de un control permanente de sus procesos y de su mejora continua.
8.4 Registro del software.

El Registro efectuado tiene un carcter meramente declarativo y no constitutivo, esto significa que se obtienen los derechos de autor por el solo hecho de serlo y la finalidad del Registro es a meros efectos probatorios, en un potencial procedimiento judicial, corriendo la carga de la prueba sobre quien no tiene ningn derecho inscrito. La propiedad Intelectual atribuye al autor la plena disposicin y el derecho exclusivo a la explotacin de la obra. Se considera obra colectiva la creada por la iniciativa y bajo la coordinacin de una persona natural o jurdica que la edita y la publica bajo su nombre y est constituida por la reunin de aportaciones de diferentes autores cuya contribucin personal se funde en una creacin nica y autnoma, para la cual haya sido concebida sin que sea posible atribuir separadamente a cualquiera de ellos un derecho sobre el conjunto de la obra realizada. Salvo pacto en contrario, los derechos sobre la obra colectiva correspondern a la persona que la edite y divulgue bajo su nombre. Son objeto de propiedad intelectual todas las creaciones originales literarias, artsticas o cientficas expresadas por cualquier medio o soporte, tangible o intangible, actualmente conocido o que se invente en el futuro.
Corresponde al autor el ejercicio exclusivo de los derechos de explotacin de su obra en cualquier forma y, en especial, los derechos de reproduccin, distribucin, comunicacin pblica y transformacin, que no podrn ser realizadas sin su autorizacin, salvo en los casos previstos en la presente ley. Los derechos de explotacin de la obra durarn toda la vida del autor y setenta aos despus de su muerte o declaracin de fallecimiento. La extincin de los derechos de explotacin de las obras determinar su paso a dominio pblico. Las obras de dominio pblico podrn ser utilizadas por cualquiera, siempre que se respete la autora y la integridad de la obra. Los derechos de explotacin de la obra pueden transmitirse por actos "inter vivos", quedando limitada la cesin al derecho o derechos cedidos, a las modalidades de explotacin expresamente previstas y al tiempo y mbito territorial que se determinen. Toda cesin deber formalizarse por escrito. El titular de los derechos reconocidos en la Ley de Propiedad Intelectual podr instar el cese de la actividad ilcita del infractor y exigir la indemnizacin de los materiales y morales causados. El perjudicado podr optar como indemnizacin entre el beneficio que hubiere obtenido presumiblemente, de no mediar la utilizacin ilcita, o la remuneracin que hubiera percibido de haber autorizado la explotacin. En caso de dao moral proceder su indemnizacin, aun no probada la existencia de perjuicio econmico. Para su valoracin se atender a las circunstancias de la infraccin, gravedad de la lesin y grado de difusin ilcita de la obra.
8.4.1 Procedimientos y requerimientos para registrar software en el INDAUTOR.

Para registrar el software ante el INDAUTOR se deben de seguir los siguientes requerimientos. 1. registro ante en Instituto Nacional De Derecho Del Autorde los 20 sistemas de software mas relevantes.
Anlisis de los estados jurdicos del software. Anlisis de la documentacin tcnica de los software, necesarias para su registro ante el INDAUTOR. Anlisis de la documentacin de soporte de a propiedad o titularidad de los derechos de autor correspondientes. Obtencin de la documentacin jurdica, tcnica y de soporte, as como la informacin digital necesaria para su registro ante en INDAUTOR. Llenado de formularios oficiales para el registro. Gestin de registros del software.
2. Revisin y elaboracin de contratos relacionados con la propiedad y los derechos de uso. Contratos de desarrollo de software. Contratos de transmisin de derechos. Contratos de no confidencialidad y no divulgacin. Proceda a llenar los campos. Con estos datos prepararemos el formulario para solicitar el registro de obras de software y bases de datos y se lo remitiremos para su firma. Cualquier sobre los datos requeridos contctese con nosotros.
Nombre/s Completos del Autor Apellido/s Completos del Autor Documento Identidad de No: No: --
C.U.I.T./C.U.I.L./C.D.I/ Extranjero
Extranjero no residente en Argentina dejar en
blanco E-Mail Domicilio-Localidad Cdigo Postal Pas Telfono (incluir cdigo de pas y/o rea) Empresa o Persona Jurdica Titular de los Derechos (si este fuera el caso *) * Si en la obra no se quiere hacer figurar al autor o bien fue realizada por encargo, se pone annima y se declara slo al titular de derechos. La declaracin lleva la firma del autor si lo hubiere y del titular de derechos. Si el autor es annimo slo firma el representante de la persona jurdica titular de derechos. Ttulo de la obra Indicar si es obra original o adaptada Tipo de Software (Comercial o Enlatado, Software a medida) Sistema Operativo Plataforma Idioma/s
Breve descripcin de la obra (ej. (es un sistema de administracin de servicios domiciliarios aplicado a la gestin comercial de entidades cooperativas) Aplicaciones cubre (para sirve) Cantidad Ejemplares que comercializaran Precio de venta Esta informacin se suministra a fin del clculo de la Tasa Legal correspondiente. El precio de venta multiplicado de los ejemplares por la cantidad de ejemplares editados nos da un resultado (x) el que a fin de calcular la Tasa Legal debe ser multiplicado por 2 y dividido por 1000 La Tasa Legal mnima es $ 4.50 Usted deber remitirnos el material a los fines de su depsito tales como cdigo fuente, objeto y aplicativo lo cual se debe adjuntar en un soporte magntico u ptico. que que de se
8.4.2 Ventajas y desventajas de registrar software.

La proteccin de los derechos de autor se ha elegido como medio de proteccin porque un programa de ordenador "a priori" se parece ms a una creacin de la mente que a una invencin tcnica. La ventaja principal de los derechos de autor reside en su flexibilidad; no hay ninguna necesidad de registrar ni de realizar
ninguna formalidad porque los derechos de autor protegen un programa informtico desde que se crea. Los derechos de autor tienen la ventaja de que permiten a las pequeas empresas y a las personas individuales proteger sus propias creaciones cuando no tienen los medios o no quieren implicarse en un proceso largo y costoso para obtener una patente. Sin embargo, la proteccin de los derechos de autor es imperfecta. Los derechos de autor se pueden pasar por alto fcilmente mediante el mtodo conocido como "blind room". En realidad, un programa de ordenador que muestre grandes similitudes con el de un competidor no se considerar plagio si el autor puede demostrar que su creacin es independiente. La doctrina jurdica acepta de manera generalizada que el mtodo "blind room" permite a los programadores obtener una creacin independiente. La aplicacin de dicha tcnica requiere dos equipos de investigadores. El primero examina y analiza los productos del competidor, igual que ocurre con la "ingenieria inversa" (reverse engineering), y despus transmite los resultados a un segundo equipo que desarrolla un nuevo producto basado en los resultados del primer equipo. Sin embargo, en el derecho de patentes, donde no es necesario copiar para transgredir el derecho de exclusiva, la nocin de "creacin independiente" desaparece..
8.5 Violacin a los derechos de autor. Se viola los derechos del autor en los siguientes casos:
La copia del programa base u operativo, sin su autorizacin. La copia del programa aplicativo, sin su autorizacin. La modificacin o alteracin del programa. Los daos causados a su programa por otro software. El uso del programa, sin su autorizacin.
8.6 Leyes que brindan proteccin jurdica al software en caso de violacin.

Formando parte del Ttulo IV, el captulo IV de la Ley Federal de Derechos de Autor, tras la reforma publicada el 19 de mayo de 1997 en el Diario Oficial de la Federacin, lleva como ttulo el de "DE LOS PROGRAMAS DE COMPUTACIN Y LAS BASES DE DATOS" y se encuentra constituida por 14 artculos. Dentro de esta Ley a la que hemos estado haciendo mencin, en los artculos comprendidos del numeral 101 al 106 se encuentran exclusivamente regulados los programas de computacin, mientras que en los numerales 111, 112, 113 y 114 se estipulan normas no slo de aplicacin a los programas de computo, sino tambin a las bases de datos.
Recientemente, con fecha 14 de octubre de 1998, el Congreso de la Nacin sancion la ley 25.036 (B.O. 11/11/98) que modifica y amplia la Ley de Propiedad Intelectual (11.723). La importancia de esta norma radica en que incorpora a los programas de computacin y a las compilaciones de datos dentro de las obras tuteladas por la Ley de Propiedad Intelectual, brindando proteccin a los derechos intelectuales de los creadores de software bajo el rgimen del Derecho de Autor. Esta ley, a la que se ha dado en llamar "Ley del Software", vino a llenar un importante vaco legislativo. As, al incluir a los programas de computacin dentro de los derechos de autor brinda proteccin desde la perspectiva civil, posibilitando al titular del derecho de propiedad intelectual accionar por daos y perjuicios contra aquel que utilice o reproduzca el programa sin su autorizacin y, adems, tipifica el delito de reproduccin ilegal de programas de computacin, al incluir la conducta dentro del tipo previsto por el art. 172 del Cdigo Penal.
8.7 Sociedades de Gestin colectiva. 8.7.1 Que es una SGC.

Una sociedad de gestin colectiva es una persona moral que se constituye sin nimo de lucro, con la finalidad de ayuda mutua entre sus socios y para apoyar actividades de promocin de sus repertorios. Las sociedades de gestin colectiva podrn constituirse por rama o categora de creacin de obras o por modalidad de explotacin, cuando concurran en su titularidad varias categoras de creacin de obras, y siempre que la naturaleza de los derechos encomendados a su gestin as lo justifique.
8.7.2 Procedimientos y requerimientos sociedad de gestin colectiva.
para
registrar
una
De acuerdo a los estatutos, los trmites son los siguientes: ARTCULO 10.- Los aspirantes debern presentar solicitud por escrito con todos sus datos generales, anexando currculum vitae de fecha reciente, as como datos precisos de su obra escrita, la cual haya sido registrada para los efectos legales del Derecho de Autor en nuestra Sociedad. La referida solicitud en los trminos expresados ser sometida para su estudio y posterior dictamen al Consejo Directivo. En la solicitud el escritor manifestar su compromiso expreso de acatar las disposiciones contenidas en los presentes estatutos y en la Ley Federal del Derecho de Autor y su reglamento. ARTCULO 11.- Ser ineludible para ingresar a la Sociedad, que el escritor o su causahabiente en su caso, confiera a la Sociedad mandato ante notario pblico en el que otorgue poder para pleitos y cobranzas y actos de administracin, a fin de que la Sociedad entregue y recaude las percepciones pecuniarias o regalas que
por derechos de autor le corresponda as como representarlo en la defensa de sus intereses generados en su calidad de autor escritor, ante cualquier autoridad administrativa o judicial o ante terceros usuarios en los trminos del artculo 2554, del cdigo civil, a fin de que la Sociedad quede legitimada para actuar de conformidad con lo dispuesto en el artculo 200 y dems relativos a la Ley Federal de Derecho de Autor. Sin este requisito no se dar curso a la solicitud de ingreso a la Sociedad.

Antologia DSS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Antologia DSS

Uploaded by

Copyright:

Available Formats

INSTITUTO TECNOLOGICO SUPERIOR DE CENTLA LICENCIATURA EN INFORMTICA ANTOLOGA DE DESARROLLO DE SOFTWARE SEGURO

1.5 1.6 1.7

DESARROLLO DE SOFTWARE SEGURO

Casos reales de fallas en el software.

El futuro del software

Fuentes para la informacin de vulnerabilidades

DESARROLLO DE SOFTWARE SEGURO

A continuacin se describen cada una de las tcnicas:

mencionados en este apartado, hacen referencia a las medidas de seguridad en redes.

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

Tendencias Tcnicas Que Afectan la Seguridad del Software

breaking Patch (romper y actualizar )

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

Metas de la seguridad enfocados al software.

1.7.1 Prevencin (antes):

1.7.2 Auditable y trazable.

Sincronizacin Control y aseguramiento de registros de monitoreo Confiabilidad de la generacin de registros de monitoreo

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

Como protegerse contra este peligro

DESARROLLO DE SOFTWARE SEGURO

Metas de proyecto de software

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

Unidad II Administracin de los riesgos en la seguridad del software

DESARROLLO DE SOFTWARE SEGURO

2.1 Descripcin de la administracin de los riesgos en la Seguridad del Software

Administracin de los riesgos en la Seguridad del Software

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

2.2 Administracin de los riesgos en la seguridad del Software en la prctica.

DESARROLLO DE SOFTWARE SEGURO

2.2.1 Pruebas de caja negra

DESARROLLO DE SOFTWARE SEGURO

2.2.2 Equipo Rojo

2.3 Criterios comunes.

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

Unidad III Cdigo abierto o cerrado

DESARROLLO DE SOFTWARE SEGURO

3.1 seguridad por oscuridad.

3.2 Ingeniera inversa

DESARROLLO DE SOFTWARE SEGURO

3.3 Cdigo fuente abierto.

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

DESARROLLO DE SOFTWARE SEGURO

Unidad IV Principios guas del software seguro

DESARROLLO DE SOFTWARE SEGURO

4.1 Principio 1 reducir las lneas dbiles

4.2 Principio 2 Defensa por pasos o capas

4.3 Principio 3 Seguramente fallara.

4.4 Principio 4 menos privilegios

DESARROLLO DE SOFTWARE SEGURO

4.5 Principio 5 segmentacin

4.6 Principio 6 mantenerlo simple

4.7 Principio 7 promover la privacia

4.8 Principio 8 Ocultar secretos es difcil

DESARROLLO DE SOFTWARE SEGURO

4.9 Principio 9 Transparentar el cdigo

Principio 10 Usar recursos comunes