Monografias.com > Computación > Programación
Descargar Imprimir Comentar Ver trabajos relacionados

El proceso unificado del desarrollo de software (Capítulos 4, 5, 6 y 7)




Enviado por ezequielher



    Resumen del libro

    Autores: Jacobson, Booch,
    Rumbaugh

    1. Un proceso centrado en la
      arquitectura
    2. Un proceso iterativo e
      incremental
    3. Cap. de requisitos: de la
      visión a los requisitos
    4. Captura de requisitos como caso
      de uso

    CAPITULO 4

    Un proceso centrado en la
    arquitectura

    Arquitectura:

    Da una perspectiva del sistema completo;
    todos los empleados deben estar de acuerdo con ella.

    Describe los elementos más importantes del
    sistema.

    El 1er. Objetivo de la
    fase de elaboración es construir una arquitectura
    sólida que sirva de base para construir el
    sistema.

    1. Arquitectura en pocas palabras

    1. El conjunto de todas las vistas representa a la
      arquitectura. Cada vista es una perspectiva diferente del
      sistema. Cantidad de páginas para la Descripción de arquitectura: Se
      recomienda que sea de entre 50 y 100

      Para que los desarrolladores progresen hasta obtener una
      visión común (en sist. soft. grandes)

      Para dividir el proyecto en
      clases y facilitar su reutilización (futuros
      cambios)

      1. Compresión del sistema
      2. Todos las personas que trabajen en el desarrollo del
        sistema deben comprenderla lo cual es un reto
        difícil porque: operan en entornos complejos y al
        dividirlos en miniproyectos es difícil
        coordinarlos.

        Mientras más grande sea el proyecto
        habrá mayor sobrecarga en la
        comunicación entre los distintos
        desarrolladores; para ello se divide el sistem en
        subsistemas donde cada uno tendrá un responsable.
        También es importante tener interfaces bien
        definidas.

      3. Organización del desarrollo

        Este capitulo es un quilombo. Jacobson andate a la
        concha de tu madre que te parió cagando.

      4. Fomento de la reutilización
      5. Evolución del sistema

      Un sistema grande evoluciona con el tiempo
      incluso durante su desarrollo, o sea, sufrirá futuras
      modificaciones (nuevos casos de usos). Si el sistema es
      flexible (tolerable a cambios) dichas modificaciones no deben
      causar resultados inesperados. Las arquitecturas de sistemas
      pobres deben ser parcheadas hasta el final y su coste es
      grande e innecesario.

    2. Por qué es necesaria la arquitectura
    3. Casos de uso y arquitectura

    La arquitectura se ve condicionada por:

    • Los casos de usos más importantes (más
      significativos).
    • El producto
      software que se desea desarrollar. Por ej.: sist.op.; base de
      datos;
      etc.
    • Los productos de
      capa media que se van a utilizar.
    • Sistemas heredados a utilizar.
    • Estándares y políticas corporativas.
    • Requisitos no funcionales.

    La arquitectura del sistema se desarrolla en fase de
    elaboración juntos con los casos de usos más
    importantes. Una vez que se tiene una arquitectura estable se
    realiza el resto de los casos de uso (los menos relevantes) que
    por lo general se basan en los requisitos de los clientes y
    usuarios.

    El valor de
    costo de nuevos
    casos de usos se reflejan según la arquitectura del
    sistema.

    La arquitectura guía los casos de uso: Mientras
    más se conozca la arq. mejor se hará la captura de
    requisitos para desarrollar los casos de usos.

    Los casos de uso conducen a la arquitectura: ???

    Cada vez que se quiera implementar un conjunto de CU al
    sistema, lo ideal es ampliar la arquitectura para darles soporte.
    Dicha ampliación se realiza una vez por cada
    iteración.

    Entonces, Los CU ayudan a tener una arquitectura cada vez
    mejor.

    1. La arquitectura se desarrolla mediante un conjunto de
      iteraciones, principalmente en fase de elaboración. El
      resultado de esta fase es una línea base de la
      arquitectura (esqueleto del sistema) que consta de poco
      software.

      1. Línea base de arq: sistema pequeño y
        flaco
      2. Lo mismo que el 4.4 pero con más boludeces.

        La línea base del sistema es una versión
        interna y se basa en la descripción de la
        arquitectura.

        Cada versión nueva de un modelo
        se desarrolla a partir de la versión anterior.
        Nunca son independientes unos de otros.

        Los elementos de un mismo modelo se relacionan por
        medio de dependencias de trazas.

        Descripción de arquitectura: Sirve para guiar a
        los desarrolladores durante ciclo de
        vida actual y como base para el futuro.

        Teniendo una arquitectura estable, la
        descripción de ésta también
        será estable.

      3. Utilización de patrones en la arquitectura
    2. Pasos hacia una arquitectura

    Definición de Patrón: Solución a un
    problema de diseño
    que aparece con frecuencia.

    Estos patrones están documentados en libros; en
    ella hay diferentes plantillas donde asignan un nombre a cada
    patrón y describe los problemas,
    qué los causa y las soluciones.

    Algunos patrones de diseño: Facade, Decorator, Proxy Observer,
    Strategy, Visitor.

    • Los patrones de diseño son ideal para lenguajes con
      orientación a objetos.
    • Los patrones de arquitectura son ideal para sistemas,
      subsistemas e interfaces.

    Definición de Capa: Conjunto de subsistemas que
    comparten la misma generalidad y de volatilidad de interfaces:
    Las capas inferiores (media y de sistema) requieren de interfaces
    estables; las capas superiores (de aplicación) requieren
    interfaces menos estables.

    1. Descripción de la arquitectura

    Debe contener todo lo que los trabajadores necesitan para
    hacer sus trabajos.

    Debe actualizarse en forma constante para reflejar cambios y
    adiciones.

    También debe presentar:

    • Vistas de los distintos modelos.
    • Requisitos que no figuran en los CU (NO funcionales /
      adicionales)
    • Breve descripción de plataforma, sistema heredados y
      software comercial q se va a utilizar.

    En la DA se describen con más detalle los subsistemas
    que son significativos para la arquitectura que representan un
    aprox.10%. Los CU en su mayoría no modifican al
    sistema.

    1. El arquitecto crea la arquitectura: que novedad

    Es importante que el arquitecto tenga conocimientos
    sobre…

    • ..la empresa con
      la que está trabajando: adquirir experiencia con
      usuarios.
    • ..desarrollo de software: saber escribir códigos
      para comunicarse con desarrolladores.

    Puede que se necesiten más de un arq. para desarrollar
    sistemas grandes.

    El desarrollo de arquitectura consume mucho tiempo.

    1. Ejemplo pág. 72
    2. Resumen

    CAPITULO 5

    Un proceso iterativo e
    incremental

    Cada fase de desarrollo se compone por una
    serie de iteraciones e incrementos.

    1. Iterativo e incremental en pocas palabras

    3 Claves del Proceso Unificado para el desarrollo de
    software:

    • El sistema esté dirigido por casos de usos.
    • Se centre en una arquitectura.
    • Tenga un desarrollo iterativo e incremental.
    1. Desarrollo en pequeños pasos

    En las primeras iteraciones se realiza:

    • Determinación del ámbito del proyecto.
    • Eliminación de riesgos
      críticos.
    • Creación de la línea base de
      arquitectura.

    Se deben dominar los requisitos, el problema y los riesgos que
    pueden surgir.

    En las iteraciones posteriores

    • Se reducen los riesgos menos graves
    • Se implementan componentes

    Se añaden incrementos hasta llegar a la versión
    extrema (para el cliente).

    El ciclo de vida de un proyecto se divide en miniproyectos =
    iteraciones, cada una compuesta por sus respectivos flujos de
    trabajo
    (requisito, análisis, diseño,
    implementación, prueba).

    Se les llama miniproyectos porque no es algo que el usuario
    haya pedido.

    El jefe de proyecto es quien se encarga de ordenar las
    iteraciones.

    1. No es una iteración

    Si el desarrollador pasa del ciclo de inicio al de
    elaboración…

    • Sin resolver los riesgos más críticos.
    • Sin establecer una línea base de la
      arquitectura.
    • Sin implementar los casos de usos importantes.

    Además de ser un choto está construyendo un
    proyecto no fiable y no vale la pena que siga con él.

    La iteración NO es aleatoria. Sirve como herramienta;
    para que los directores controlen el proyecto y reduce los
    riesgos q puedan amenazar al principio del ciclo de vida.

      1. Riesgo: es una variable que pone en peligro o impide
        el éxito del proyecto.

        "Aproximación al proceso de desarrollo dirigido
        por riesgos": El Proceso Unificado reconoce los riesgos
        más importantes en las primeras 2 fases y reduce
        los mismos. Los que no, pueden poner en peligro el
        proyecto entero.

        Método cascada: El desarrollo del sistema no se
        divide en iteraciones. Los problemas graves pueden saltar
        en la fase de integración & prueba; esto
        obliga a contratar a desarrolladores con más
        experiencia, el proyecto queda parado y se retrasan las
        fechas.

        Método iterativo: Los riesgos importantes se
        tratan en las primeras fases, quedando muy pocas en la de
        construcción. El proyecto marcha
        sin inconvenientes hasta el final.

      2. Atenuación de riesgos

        Método cascada: Es en las últimas fases
        donde se sabe con certeza si la arquitectura que se
        diseñó es la adecuada. Si no lo es, se
        habrá perdido mucha guita y no podremos cumplir
        con la fecha de entrega.

        Método iterativo: Es al final de la fase de
        elaboración donde se evalúa la
        arquitectura; si aún no está madura se
        trabaja en una nueva iteración; esto es posible ya
        que es muy poco lo que se in-vierte en esta fase y las
        fechas aún no están definidas.

      3. Obtención de una arquitectura robusta

        construcción: es una versión operativa
        del sistema que demuestra un subconjunto de
        posibilidades.

        Es más fácil para el usuario ver un
        sistema ejecutable en funcionamiento que leer cientos de
        páginas de documentos. Esto permite a que los
        usuarios opinen y sugieran modificar o agregar cosas que
        se nos pasó de largo. En método cascada los usuarios ven al
        sistema funcionando recién en la
        integración y prueba, y si desea cambiar algo
        deberán aumentar presupuesto y atrasar las fechas.

      4. Gestión de requisitos cambiantes
      5. Permitir cambios tácticos
    1. ¿Por qué un desarrollo iterativo e
      incremental?

    Con método iterativo los directores se encargan de ver
    al final de cada iteración..

    • Si hubo un incremento y se han resueltos los problemas;
      entonces autorizará a los desarrolladores a seguir con
      la siguiente iteración.
    • Si el éxito fue parcial, se ampliará la
      iteración hasta poder
      cumplir con lo requerido.
    • Si el resultado es negativo puede llegar a cancelarse el
      proyecto.

    1. Método cascada: Muchos errores parecen no estar
      presentes y el proyecto progresa con norma-lidad hasta
      llegar a la integración y prueba; ahí salen
      todos a la luz.
      Estas ponen en peligro al proy

      Método iterativo: Ya desde un principio se hacen
      frecuentes construcciones, y con éstas aparecen los
      errores que se tratarán a lo largo de todo el
      proyecto. No habrá sorpresas para el final.

    2. Conseguir una iteración continua
    3. Conseguir un aprendizaje
      temprano

    Se ingresa gente nueva a medida que se pasa de una
    iteración a otra. Puede empezar con unas 5 a 10 pers.
    pasar a 25 y finalmente a 100. Los nuevos tienen una
    formación adecuada y trabajan con gente con experiencia,
    rápidamente se ajustan a la velocidad
    adecuada.

    1. La aproximación iterativa está dirigida
      por riesgos

    Se analizan los riesgos, luego se priorizan y se organizan las
    iteraciones para

    • Tratar los requisitos pedido por los usuarios
    • Obtener una arquitectura robusta.
    • Tratar otros aspectos como rendimiento, disponibilidad,
      portabilidad: éstos se ven cuando se implementa y se
      prueba el software.

    Objetivo: acabar con los riesgos en una iteración
    temprana.

    En fase de inicio y elaboración se tratan la
    mayoría de los riesgos.

    1. Las iteraciones alivian los riesgos técnicos

    Hay 4 formas de tratar a un riesgo
    según su prioridad:

    • Evitarlo: Quizás se tenga que replanificar el
      proyecto o hacer un cambio de
      requisitos.
    • Limitarlo: Achicarlo para que afecta una parte
      pequeña del proyecto.
    • Atenuarlo: Probar repetidas veces hasta ver si aparecen o
      no.
    • Controlarlo: Ver si el proyecto puede convivir con
      ésta. Caso contrario no se podrá continuar: algo
      que no es tan malo ya que se detectó en un principio y
      los gastos fueron
      mínimos.

    Se manejan por iteraciones para no tener que tratar con todos
    los errores a la vez.

    1. Iteración genérica

    1. Qué es una iteración

    Una iteración es un miniproyecto donde se tiene como
    resultado una versión interna.

    Está compuesto por 5 flujos de trabajos: requisitos,
    análisis, etc.

    Los trabajadores y artefactos pueden trabajar en más de
    un flujo de trabajo.

    Las Fases están divididas en N iteraciones.
    Descripción de cada fase:

    • Inicio: Hacer análisis del negocio y reducir los
      riesgos más importantes.
    • Elaboración: Obtener línea base de la
      arquitectura, capturar requisitos, reducir demás
      riesgos.
    • Construcción: Desarrollar el sistema entero. Ofrecer
      funcionalidad operativa a clientes.
    • Transición: Tener el producto preparado para la
      entrega. Se enseña a usuarios a utilizar el
      software.

    Cada iteración se analiza cuando termina y se ven si
    cambiaron o aparecieron nuevos requisitos que modificarán
    a la siguiente iteración.

    Prueba de regresión: Sirve para ver si no se han
    estropeado iteraciones anteriores. Se aplica al antes de terminar
    con la iteración actual.

    1. Requiere de más tiempo que en el modo
      cascada.

      En método cascada la planificación se realiza en un
      principio, osea, antes de tratar los riesgos importantes y
      tener una línea base sólida.

      Método iterativo: No se planifica proyecto entero
      en fase de inicio, solo unos pasos. Es al final de la fase
      de elaboración donde se tiene una base para
      planificar la mayor parte.

    2. Planificación de las iteraciones
    3. Secuencia de iteraciones

    Los casos de usos establecen una meta. La arquitectura
    establece un patrón.

    En las primeras iteraciones se conocen mejor los requisitos,
    riesgos y soluciones. Las iteraciones sgtes. dan como resultado
    incrementos aditivos que terminan en una versión
    externa.

    La planificación y trabajo de una iteración
    empieza cuando la anterior se está por entregar.

    1. El resultado de una iteración es un
      incremento

    1. Definiciones de Incremento:

      Diferencia entre la versión interna de la
      iteración anterior y la siguiente.

      Diferencia entre 2 líneas bases sucesivas.

      Colaboración: Es la representación de los CU
      más significativos para la arquitectura. Sirve para
      identificar subsistemas e interfaces. Luego se les da forma
      (implementa código).

      Hay más incrementos a medida que nos acercamos a la
      fase de transición.

      La integración del último incremento se
      convierte en el sistema final.

    2. Iteraciones sobre el ciclo de vida

    Cada una de las 4 fases termina con un hito principal.

    Objetivos de cada fase: Ya están en punto 4.2

    Al final de cada iteración se producen artefactos como
    resultado.

    • Hitos principales: Se dan al final de cada fase. Jefes y
      desarrolladores toman decisiones impor-tantes: continuar o no
      con el proyecto, calendario y presupuesto.
    • Hitos secundarios: Se dan al final de una iteración.
      Los jefes deciden cómo continuar en itera-ciones
      siguientes.

    En fases inicio y elaboración es poco el grupo de gente
    trabajando (bajo costo).

    Aumenta el número de personas en fase de
    construcción.

    CAPITULO 6

    Cap. de requisitos: de la visión a los
    requisitos

    1. Capturas de requisitos: es el proceso de averiguar
      en circunstancias difíciles qué se debe
      construir.

      Los desarrolladores no pueden escribir un
      código sin saber qué es lo que debe hacer. Algo
      que sucede en algunas ocasiones. Analistas documentaban
      requisitos según lo que los usuarios pedían,
      pero llegaba a cientos de páginas y no podían
      concretarse fácilmente. Los usuarios sabían
      bien qué debía hacer el software recién
      cuando el producto estaba casi terminado y para hacer los
      cambios pedidos no quedaba otra que postergar las fechas y
      aumentar presupuesto. El usuario no saben cuáles son
      los requisitos.

    2. Por qué la captura de requisitos es
      complicada

      Objetivo: Guiar el desarrollo hacia el sistema
      correcto.

      Suponiendo que el usuario no es un especialista
      informático, debemos ser capaces de hacer entender al
      cliente el resultado de los requisitos; utilizando el
      lenguaje del cliente e introduciendo (con mucho cuidado)
      formalidad y estructuras.

    3. Objeto de flujo del trabajo de los
      requisitos

      Se puede comenzar con la captura de requisitos de
      muchas maneras: haciendo un modelo de negocio, o de dominio por
      ejemplo.

      Flujos de trabajo arquetípicos:

      Enumerar los requisitos candidatos: De
      aquí se obtienen características: lista de
      sugerencias que el usuarios va dando. Aumenta cuando se
      agregan elementos; se restan al convertirse en otros
      artefactos como casos de uso. Compuesto por un nombre corto,
      breve descripción y un conj. de valores:

      Estado (propuesto, aprobado, validado) Coste
      estimado, Prioridad, Nivel de Riesgo.

      Estos valores sirven para calcular tiempo que
      llevará el proyecto y cómo dividirlo en
      iteraciones.

      Comprender contexto del sistema: Hay 2
      aproximaciones para expresar el contexto de sist.

      Modelo de dominio: Describe los objetos del
      dominio*, se les asignan un nombre que se pasan a un glosario
      para mejorar la comunicación entre la gente que
      trabaja. Los objetos ayudan a identificar clases.

      Modelo de negocio: Es más amplio que el
      modelo de dominio. Describe los procesos
      que componen el negocio. Objetivo à Comprender
      cuáles son los procesos que soportará el
      sistema..

      Capturar requisitos funcionales: Se basa en
      los caso de usos = Describen de qué forma el
      usuario va a utilizar el sistema. Cada usuario requiere de
      varios CU. Los analistas proponen cómo será la
      interfaz del sistema esbozando varias versiones para que el
      usuario decida.

      Capturar requisitos NO funcionales:
      Especifica las propiedades del sistema que tienen que ver con
      rendimiento, velocidad, uso de memoria,
      plataforma. Fiabilidad: tiempo de respuesta media, defectos
      por miles de líneas de código. Imponen
      condiciones a requisitos funcionales.

      Puede que no pertenezca a ningún caso de uso
      => se agregan como requisitos adicionales.

      * objetos de dominio: Cosas o eventos que
      existen o suceden en el entorno donde trabaja el
      sistema.

    4. Visión general de la captura de
      requisitos
    5. Papel de los requisitos en el ciclo de vida de
      software

    inicio: Se identifican la mayoría de los CU para
    detallar los más importantes (10%)

    elaboración: Se captura un 80% de requisitos para
    estimar tiempo de proyecto.

    construcción: Se capturan e implementan los
    demás requisitos.

    transición: No hay captura de
    requisitos.

    1. Cómo desarrollar un modelo de negocio (2
      pasos)

    El modelador..

    • hace un modelo de CU del negocio que identifique a
      los actores y los CU que utilicen los actores.
    • Desarrolla un modelo de objetos del negocio compuesto
      por trabajadores, entidades del negocio y unidades de
      trabajo.

    Una entidad del negocio representa algo que los
    trabajadores toman, manipulan, modifican, utilizan (una factura por
    ejemplo). Una unidad de trabajo es un conjunto de entidades de
    trabajo.

    CAPITULO 7

    Captura de requisitos como caso de
    uso

    1. Los artefactos fundamentales en captura de requisitos
      son:

      Modelos de CU: Incluye actores y casos de usos

      Otros: Prototipos de interfaz de usuario.

      1. Artefacto: modelo de CU
      2. El modelo de CU sirve para llegar a un acuerdo entre
        el cliente y desarrollador sobre los requisitos que
        deberá tener en cuenta el sistema. Describe lo que
        hace el sistema para cada tipo de usuario.

        Actor: Representa el entero externo al sistema.

        Rol: Define lo que hace un trabajador en proceso de
        negocio.

        Instancia: es un actor que interactua con el
        sistema.

      3. Artefacto: actor

        Interacción: Es una secuencia de acciones que el sistema lleva a cabo
        (interactuando con actores) para dar un resultado de
        valor. Descripción de CU puede incluir diagramas de actividad.

        Instancia de CU: Es la realización de los CU.
        Son atómicas: se ejecutan todo o nada. Sin otros
        de por medio.

        Los CU tienen atributos, valores que en su
        ejecución se pueden usar y modificar.

        Flujos de sucesos: Especifica qué hace el
        sistema cuando ejecuta un determinado CU.

        Flujos especiales: Describe a un grupo de requisitos
        no funcionales.

      4. Caso de uso

        Contiene una vista del modelo de CU que describe los
        aspectos más importantes de la arquitectura.

      5. Artefacto: descripción de una arquitectura
      6. Artefacto: Glosario
      7. Artefacto: prototipo de interfaz de usuario

      Mejora la interfaz de usuario y ayuda a comprender los
      CU.

    2. Artefactos
    3. Trabajador

    1. Representa los comportamientos, descripciones y
      responsabilidades del mismo.

      No es lo mismo que un individuo
      ya que éste puede representar a varios trabajadores si
      es que realiza distintas actividades.

      1. Analista de sistemas

      Hace la captura de requisitos func. y no func. para
      moldearlos a los CU. Hay 1 por cada sistema.

      Especificador de CU: Asiste al analista de
      sistema.

      Diseñador de interfaz: Es responsable del
      prototipo de interfaz de usuario.

      Arquitecto: Trabaja con la captura de requisitos
      para diseñar las vistas de la arq del modelo de
      CU.

      Conjunto de actividades que están ordenados. Los
      trabajadores crean, ejecutan y modifican artefactos.

      Cada salida de una actividad sirve como entrada para la
      siguiente.

      Los artefactos se completan y mejoran a través de
      las iteraciones. Los analistas para hacer captura de
      requisitos requiere de la ayuda de usuarios, desarrolladores
      y otros analistas.

      4 pasos para tener una nueva versión del modelo de
      CU con actores:

      Encontrar los actores / CU / describir cada CU / Describir
      modelo de CU. No requieren de un órden.

      1. Encontrar actores:
      2. Es fácil hacerlo teniendo el modelo de negocio.
        1 actor por c/ trabajador. 1 actor por c/ cliente.

        Hay que elegir un actor candidato que represente a
        todos sus pares.

        No pueden haber 2 o más actores que tengan los
        mismos roles.

        El analista le asigna un nombre a cada actor y hace
        una breve descripción q aclare necesidades y
        respon.

        Encontrar casos de uso:

        En general empieza con un verbo e indica el objetivo
        del CU para cada actor.

        Resultado de valor:

        La ejecución satisfactoria de un CU da un
        resultado de valor para que el actor pueda alcanzar su
        objetivo.

        La instancia de un CU involucra a más de un
        actor.

        Los CU más importantes se desarrollan en
        primeras iteraciones.

        La vista de arquitectura del modelo de CU describe los
        CU más significativos para la arquitectura.

      3. Priorizar casos de uso
      4. Detallar un caso de uso
    2. Flujos de trabajo

    Objetivo: Describir su flujo de sucesos de cada CU. Puede
    hacerse en texto o
    diagramas.

    Transacción: Secuencia de acciones q se llevan a cabo
    en una instancia de CU.

    Desviaciones: Puede darse por que..

    • El actor puede tomar caminos diferentes.
    • El sistema detecta entradas erróneas del actor.

    ¿Qué incluye la descripción de un CU?

    • Estado inicial como precondición.
    • Cómo y cuándo comienza un CU.
    • Orden en que se ejecutan las acciones.
    • Cómo y cuándo termina un CU.
    • Descripción de estado final
      como postcondición.
    • Descripción de caminos alternativos.
    • Utilización de objetos, valores y recursos.
    • Separar las responsabilidades del sistema / actores.

    Requisitos especiales: Son los requisitos no
    funcionales; especifica sgte. características del
    sistema:

    velocidad, estado de memoria, tiempo de respuesta,
    rendimiento, disponibilidad.

    Diagramas de estado: Sirve para comprender un CU complejo y
    largo con caminos alternativos.

    1. Prototipar interfaz de usuario:

    Sirve para ver cómo un usuario puede utilizar el
    sistema para ejecutar un CU.

    Se diseña durante fases de análisis,
    diseño e implementación.

    SECCIÓN: Ing. de software / Análisis de
    sistema

    Ezequiel Hernández

    Argentina

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter