Descargar

Sistema informático para la protección de la propiedad intelectual de los desarrollares de software (página 2)


Partes: 1, 2, 3

1.1.2 FORMULACIÓN DEL PROBLEMA A NIVEL ESPECÍFICO

Es decir, básicamente existe una "laguna" del derecho, que no protege a la sociedad sobre delitos como:

¿ Existe una apropiación indebida de un sistema, por parte de un empleado que había trabajado en una empresa con el fin de utilizarlo en beneficio propio ?

¿ Es verdad que existe el uso fraudulento del conocimiento que se tenía sobre un sistema o de una base de datos para modificar importes de cuentas corrientes o montos de pólizas de seguros ?.

¿ En la actualidad se podría inventar transacciones para generar una indebida erogación de dinero, a favor de un empleado de la compañía o de un tercero ?

¿ Modificar una base de datos, borrando registros relacionados con la situación tributaria de un contribuyente o cambiando importes de dinero a favor de una cuenta específica, beneficiando a personas o empresas ?

¿ Existe acceso no autorizado y utilización indebida, por parte de un empleado, de la información relacionada con una empresa o compañía ?.

¿ Se podría dar una destrucción de información en forma intencional?.

1.2. FORMULACION DE OBJETIVOS

1.2.1 OBJETIVO GENERAL

Evaluar como el sistema informático protegerá la propiedad intelectual de los desarrolladores de software.

  1. OBJETIVOS ESPECIFICOS
  1. Representar (a través de las técnicas de Ingeniería de Software) los criterios y metodología de trabajo que deben emplearse para resolver el problema en cuestión.
  2. Construir el modelo del Software.
  3. Instalar el Sistema, evaluando su comportamiento y adaptabilidad al problema.
  4. Refinar el Sistema, a través de su puesta en marcha e interacción con los problemas de aplicación.

5. Verificar, entre otras cosas, la adecuada Integración del Software diseñado con las interfaces: Usuario, Software de Base y el entorno Hardware.

1.3 EVALUACION DEL PROBLEMA

La investigación realizada es altamente relevante en el marco que se orienta a desarrollar la parte operativa del software, y el enfoque técnico nos permitirá la eficiencia de la propiedad intelectual. Sostengo además que es un tema idóneo para el temple del investigador.

1.4 IMPORTANCIA Y JUSTIFICACION DEL PROBLEMA

La investigación realizada se justifica, por las siguientes razones:

  1. Necesidad de conocer la implementación y evaluación del Diseño lógico y físico del sistema obtenido.
  2. Necesidad de realizar las condiciones que se deben seguir para poder realizar un adecuado mantenimiento de las bases de datos generadas por el sistema en cuestión.
  3. Necesidad de poder realizar adecuada Integración del Software diseñado con las interfaces: Usuario, Software de Base y el entorno Hardware.
  4. Necesidad de contribuir con la solución de las problemáticas de la administración.

1.5 LIMITACIONES DE LA INVESTIGACION

Aunque el desarrollo de la investigación tenga limitaciones, la superación de la misma consistirá en maximizar el desempeño procedimental, estas limitaciones son las siguientes:

  1. Restringido techo presupuestario

    CAPÍTULO II

    FUNDAMENTO TEÓRICO CONCEPTUAL

    1. Es muy común en todos los mercados informáticos, y en particular en el peruano, la utilización de software sin su correspondiente licencia. Hasta hace aproximadamente dos años, existían pleitos en los siguientes fueron :

      • Civil: relacionados con la explotación comercial del derecho adquirido sobre un software, conculcando el derecho civil que el individuo o una empresa tenía sobre los sistemas.

      • Penal: relacionados con el uso indebido del software para cometer fraudes, hurtos, apoderamiento indebido de los sistemas, estafas a las empresas, entre otros.

      Hoy día, empresas de gran renombre en el mercado mundial promueven acciones legales contra la piratería organizada. Dicho accionar incluye varias firmas del mercado local e individuos particulares, quienes comercializan en forma indiscriminada y sin control, pero con fines de lucro, todo tipo de software (sistemas operativos, juegos, software de aplicación, etc.).

      La gran cantidad de pleitos presentados ante la Justicia ha generado que importantes estudios jurídicos se dediquen a patrocinar las acciones legales, encontrando un adecuado eco en las Instituciones Judiciales pertinentes. Para ello, se realizan acciones penales y civiles (generalmente sincronizadas), que motivan la realización de distintas pericias para poder corroborar el delito en cuestión. Entonces es necesario que tanto la Justicia como las partes (es decir, quien inicia la demanda y el demandado) deban disponer de especialistas técnicos en informática, con experiencia y conocimiento suficiente para poder intervenir en éstos temas y así aplicar procedimientos científicos que permitan esclarecer los pleitos.

      La idea de esta tesis es desarrollar un sistema para poder resolver la elección de un perito informático que satisfaga la expectativa legal de un juez en un pleito de estas características.

    2. MARCO HISTÓRICO

      Se pretende resolver mediante el desarrollo de un sistema que permite la sugerencia de un perito informático con especialización en problemas de propiedad intelectual del software. Dicha sugerencia deberá recaer sobre un perito que reúna los conocimientos, experiencia y cualidades necesarias para cumplir con el mencionado rol.

      A continuación se define el concepto de cliente del software a desarrollar aplicado en el entorno del Proyecto. El cliente es: un juez o Tribunal de Justicia, un abogado o estudio de abogados, una empresa u organización dedicada a la venta de software, o una empresa u organización que debe enfrentar un pleito judicial alcanzado por una pericia informática.

      El cliente requiere que un perito informático debe tener tanto conocimientos (técnicos – legales), como experiencia suficiente en el tema para poder colaborar adecuadamente con el Juez en la solución de la cuestión.

    3. ANTECEDENTES DEL ESTUDIO
    4. MARCO TEÓRICO
  2. Restringido material bibliográfico.

2.3.1 GESTIÓN DE CONFIGURACIÓN

Es de fundamental importancia controlar los cambios que se producen en los sistemas, pues en este tipo de sistemas, como en todo tipo de software, es normal que aparezcan cambios a lo largo de su "vida". Esto es porque a medida que pasa el tiempo se conoce más y tiene más claro su objetivo. También se conoce sobre cómo resolver las nuevas situaciones.

Se aplicará durante el desarrollo del presente sistema una serie de conceptos asociados a la configuración del mismo, basados en:

  • Líneas base: puntos de control, sobre los que se realiza la revisión o control del software.
  • Generación de reportes de estado
  • Auditoría de la configuración

La gestión de configuración es una tarea que permite adaptar el sistema frente a cambios rápidos, con un objetivo práctico.

Figura 1

Gestión de configuración

Fuente: Kevin D. Ashley, Artificial Intelligence and Law.

2.3.2 IDENTIFICACIÓN DE LA CONFIGURACIÓN – LINEAS DE BASE

Teniendo en cuenta las características del proyecto en desarrollo y las de quien desarrolla la presente tesis, se decidió definir tres grandes líneas bases para la gestión de configuración:

Línea base de Diseño y Construcción

  • Identificación de la tarea
  • Diseño del software
  • Transferencia tecnológica

Línea base de Producto

  • Pruebas de software

Línea base operativa

  • Mantenimiento Perfectivo
  1. NOMENCLATURAS

Comprenderán los siguientes elementos:

SISPI: significa Sistema para sugerir la Selección de un Perito Informático

Característica: alfabético – cinco (5) dígitos

Elementos:

DO= Documento: asociado si corresponde a un documento

PR= Programa: asociado a si corresponde a un programa de software

Característica: alfabético – dos (2) dígitos

Identificación numérica, correlativa del informe – situación. Permite l levar un orden secuencial de los distintos informes emitidos

Característica: numérico – dos (2) dígitos

Identificación de la versión del informe – proyecto

Característica: alfanumérico – dos (3) dígitos

Ejemplo :

Tabla 1

Nomenclaturas

PROYECTO

ELEMENTOS

 

OPREACION

TIPO

(Documento / Programa)

Identificación numérica

(secuencial)

Versión

(informe /programa)

SISPI

DO

01

V11

SISPI

PR

01

V11

Fuente: Kevin D. Ashley, Artificial Intelligence and Law.

2.3.3 CONTROL DE CAMBIOS EN LA CONFIGURACIÓN

Se especifica un procedimiento básico a contemplar para llevar a delante

los cambios que se generen durante el desarrollo del producto:

  • Generación de la solicitud de cambio
  • Actualización de la Base de Datos de cambios
  • Análisis – Evaluación del cambio solicitado
  • Generación de la orden de cambio
  • Ejecución del cambio
  • Implementación – prueba del cambio

2.3.4 AUDITORÍA DE LA CONFIGURACIÓN

El alcance de la auditoria de la configuración engloba tres aspectos bien diferenciados entre sí:

  • Verificación funcional: cuyo objetivo es comprobar que se han realizado todos los tests necesarios para el elemento de configuración auditado. Y evaluando los resultados obtenidos se puede afirmar que se cumplen los requisitos preestablecidos.
  • Verificación física: cuyo objetivo es comprobar que la documentación asociada a la línea base sea completa, precisa y adecuada.
  • Verificación de certificación: cuyo objetivo es comprobar que el elemento de configuración de software se comporta debidamente integrado a su entorno operativo.

2.3.5 DETERMINACIÓN DE REQUISITOS DEL SISTEMA

Tabla 2

Requisitos del sistema

DENOMINACION

OBJETIVO

SISPI

Sistema para sugerir la selección de un Perito Informático, especialista en Ley de Propiedad Intelectual

Fuente: Kevin D. Ashley, Artificial Intelligence and Law.

De acuerdo con los conceptos básicos que la Ing. Software considera para ésta etapa, es posible afirmar que la definición de requisitos es constante durante todo el ciclo de vida del sistema. Por lo tanto, no es una etapa en sí misma, sino que se "integra" con constantes aportes en todas las etapas, a saber:

  • Análisis (ANA)
  • Diseño (DIS)
  • Implementación (IMP)
  • Evaluación (EVA)
  • Mantenimiento (MAN)

Entonces, es importante señalar que si bien el objetivo específico de la definición de requisitos, es en la etapa de Análisis (ANA).

2.3.6 ATRIBUTOS QUE EL SISTEMA DEBERÁ EVALUAR

Universidad: en la que se ha formado el especialista que se evalúa. Se dará preferencia en el caso de universidades nacionales.

Antigüedad Académica: cantidad de años que han pasado desde que el candidato en análisis ha finalizado sus estudios universitarios. Sobre el punto, el cliente señala la importancia de aquellos casos que representan una antigüedad igual o mayor a cinco (5) años en la obtención del título de grado.

Especialización: para éste aspecto, se pone énfasis en la importancia de contar con un buen grado de especialización a través de:

  • Cursos de postgrado, para especialización
  • Doctorados o maestrías
  • Talleres de postgrado para especialización

Experiencia docente específica: se señala la importancia de aquellos casos que se encuentren desarrollando algún tipo de docencia específica en el tema Pericial Informático.

Esto es de especial atención, según su concepto. Pues hoy día existen varios postgrados que cuentan a informáticos especializados como docentes. Esos postgrados (a nivel de cursos, talleres o maestrías) generan un importante valor agregado a quien lo dicte. Pues este docente debe reunir aspectos como:

  • Experiencia en la temática pericial.
  • Manejo especializado del postulante en análisis como docente, principalmente porque los alumnos de dichos cursos son abogados o informáticos de alto nivel.
  • Adecuada preparación para responder a la exigencia de aplicación del tema en experiencias personales de los alumnos.

Experiencia Pericial: aquí se evaluarán las condiciones del postulante sobre las tareas periciales desarrolladas en su actividad profesional. El análisis sobre dicha experiencia se basará en los siguientes aspectos:

  • Cantidad de pericias desarrolladas en distintos fueros de la justicia (Penal, Laboral, Civil, Comercial, Contencioso Administrativo)
  • Cantidad de pericias realizadas en fueros específicos como el Penal y el Civil. El cliente señala que es importante la actividad

desarrollada en éstos dos fueros, porque guardan una relación directa con el tipo de problemas de Propiedad Intelectual del Software. Pues es éste el marco en el que se desarrollan los problemas embebidos en la problemática que el sistema deberá analizar.

  • Cantidad de pericias desarrolladas en el entorno mencionado en el punto anterior, pero en temas relacionados con planteos sobre plagios, apoderamiento indebido y fraudes.
  • Cantidad de pericias desarrolladas sobre problemas específicos de la problemática en Propiedad Intelectual del Software.

No obstante lo planteado, se advierte de una serie de características relacionadas con quien entreviste al postulante para ser seleccionado. Afirma que tal entrevistador puede ser un Juez, un secretario de Juzgado, una autoridad judicial o un abogado. En tales circunstancias existen una serie de aspectos que se analizarán sobre los atributos específicos del candidato.

Estos atributos guardan relación con la personalidad del postulante a seleccionar, como también con su perfil psicológico.

Este es uno de los mayores desafíos para esquematizar dentro del sistema a desarrollar, con el objetivo de poder completar el cuadro de evaluación, y poder así "sugerir" al perito adecuado.

No obstante, no se generará una evaluación de dichas aptitudes, pero tomara los valores que el entrevistador asigne en cada caso y los utilizará en el proceso de razonamiento para la detección del postulante adecuado, y posterior sugerencia como especialista en Propiedad Intelectual.

2.3.7 MODELO ENTIDAD – RELACIÓN / DIAGRAMA DE ENTIDAD

RELACIÓN (DER)

Permite apreciar cuáles son las vinculaciones entre sí, con el objetivo de lograr la evaluación del perito especialista en propiedad intelectual. A los efectos de poder comprender la nomenclatura utilizada en las relaciones establecidas en los gráficos de Entidad – Relación, se aclara que se aplica el mismo nombre (pertenece a – tiene), porque todas convergen en la entidad Profesional a Evaluar.

Figura 2

Diagrama entidad relación

Fuente: Kevin D. Ashley, Artificial Intelligence and Law.

2.3.8 IDENTIFICACIÓN DE ENTIDADES Y ATRIBUTOS

Se describen, las estructuras de datos pertenecientes al problema planteado:

Tabla 3

Entidades y Atributos

Fuente: Erwin Glasseé, Knowledge Based Systems.

Tabla 4

Entidades y Atributos

Fuente: Erwin Glasseé, Knowledge Based Systems.

Tabla 5

Entidades y Atributos

Fuente: Erwin Glasseé, Knowledge Based Systems.

2.3.9 DESCRIPCIÓN DE ENTIDADES

Tabla 6

Descripción de entidades

Fuente: Erwin Glasseé, Knowledge Based Systems.

Tabla 7

Descripción de entidades

Fuente: Erwin Glasseé, Knowledge Based Systems.

Tabla 8

Descripción de entidades

Fuente: Erwin Glasseé, Knowledge Based Systems.

Tabla 9

Descripción de entidades

  Fuente: Erwin Glasseé, Knowledge Based Systems.

Tabla 10

Descripción de entidades

Fuente: Erwin Glasseé, Knowledge Based Systems.

2.3.10 GRAFO CAUSAL DE DATOS

Figura 3

Grafo causal de datos 1/9

Fuente: Andrew Stranieri, Tools and Architectures.

Figura 4

Grafo causal de datos 2/9

Fuente: Andrew Stranieri, Tools and Architectures.

Figura 5

Grafo causal de datos 3/9

Fuente: Andrew Stranieri, Tools and Architectures.

Figura 6

Grafo causal de datos 4/9

Fuente: Andrew Stranieri, Tools and Architectures.

Figura 7

Grafo causal de datos 5/9

Fuente: Andrew Stranieri, Tools and Architectures.

Figura 8

Grafo causal de datos 6/9

Fuente: Andrew Stranieri, Tools and Architectures.

Figura 9

Grafo causal de datos 7/9

Fuente: Andrew Stranieri, Tools and Architectures

Figura 10

Grafo causal de datos 8/9

Fuente: Andrew Stranieri, Tools and Architectures

2.3.11 ANÁLISIS DE CONSISTENCIA DE LOS DATOS

Se han realizado un conjunto de sesiones informales con el cliente. En las mismas, se evaluó la representación de los conocimientos que intervienen al momento de realizar la tarea vinculada a la selección de un perito en la especialidad de propiedad Intelectual. Esta comprobación permite asegurar que las representaciones realizadas en éste punto son adecuadas y permiten seguir adelante con la etapa de Conceptualización del problema, y por ende avanzar con el análisis de los conocimientos estratégicos.

2.3.12 ELABORACIÓN DEL MODELO DE PROCESOS

Tabla 11

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 12

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 13

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 14

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 15

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 16

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 17

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 18

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Tabla 19

Modelo de procesos

Fuente: Andrew Stranieri, Tools and Architectures

Partes: 1, 2, 3
 Página anterior Volver al principio del trabajoPágina siguiente