3er parcial

Qué es el PROYECTO POE




Fomentamos la escritura, la creación, la lectura y les acompañamos en todo el proceso creativo: escritura, guion y cómic. 


El Proyecto Poe busca fomentar la creación entre los jóvenes a través de un espacio compartido con los oficios de creación. Colaboramos con centros culturales, bibliotecas, institutos y colegios, para desarrollar actividades dentro del sector literario que van desde los procesos creativos y editoriales hasta la distribución, registro, derechos de autor y promoción de las obras. Es decir, enseñamos creando, ellos crean y nosotros queremos acompañar a los jóvenes en sus procesos creativos, dotarles de medios y herramientas para que no se encuentren solos a la hora de emprender proyectos literarios o guiones.


Mostramos cómo funciona la creación literaria partiendo del origen, es decir, la idea y el texto. Recorremos todas las fases de creación, corrección, registro, maquetación, edición, distribución y promoción. ¡Ellos lo hacen todo!
Creemos que conocer el camino que sigue un texto ayuda al joven a iniciarse en los oficios literarios de una manera más valiente y segura, sin sentirse aislado. 
Además, durante el taller se adquiere: 

Competencia en comunicación lingüísticaSe refiere a la habilidad para utilizar la lengua, expresar ideas e interactuar con otras personas de manera oral o escrita. 
Competencia básicas en tecnologíaAplicar los conocimientos y métodos tecnológicos para crear, desarrollar y promocionar el libro conjunto. 
Organización de tareas, trabajar de manera individual en el proceso creativo o en grupo para conseguir un objetivo.
Competencias sociales y cívicas. Comunicación del proyecto dentro de su entorno académico y familiar de manera activa y en equipo. 
Competencias en iniciativa y emprendimiento al participar en todo un proceso de desde la idea hasta su promoción final del libro.  

Utilizando el desarrollo rapido


 El RAD es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. ... El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrolloextremadamente corto. Con el proyecto de poe implementado mejoró notablemente.

DESARROLLA UN PROYECTO UTILIZANDO POE Y EL DESARROLLO RAPIDO

Para generar un buen proyecto y más completo se pueden utilizar estas dos metodologías, implementarlas unirlas y realizarlas, en el desarrollo encontrarás obstáculos y dificultades sobre todo muy constantes pero superándose una vez ya es más sencillo 
Puede escoger algunos modelos he aquí varios

El desarrollo rápido de aplicaciones o RAD por sus siglas en ingles Rapid Application Development.
El RAD es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.
El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a “Alta velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:
• Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
Obviamente la limitación de tiempo impuesto en un proyecto DRA demanda “ámbito en escalas”. Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un solo conjunto.
Algunos inconvenientes:
  • Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
  • DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.
No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.
DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.
Ventajas de RAD
  1. Comprar puede ahorrar dinero en comparación con construir.
  2. Los entregables pueden ser fácilmente trasladados a otra plataforma.
  3. El desarrollo se realiza a un nivel de abstracción mayor.
  4. Visibilidad temprana.
  5. Mayor flexibilidad.
  6. Menor codificación manual.
  7. Mayor involucramiento de los usuarios.
  8. Posiblemente menos fallas.
  9. Posiblemente menor costo.
  10. Ciclos de desarrollo más pequeños.
  11. Interfaz gráfica estándar.
Desventajas de RAD
  1. Comprar puede ser más caro que construir.
  2. Costo de herramientas integradas y equipo necesario.
  3. Progreso más difícil de medir.
  4. Menos eficiente.
  5. Menor precisión científica.
  6. Riesgo de revertirse a las prácticas sin control de antaño.
  7. Más fallas (por síndrome de “codificar a lo bestia”).
  8. Prototipos pueden no escalar, un problema mayúsculo.
  9. Funciones reducidas (por “timeboxing”).
  10. Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales.

¿COMO ELABORAR UNO?
PASO1. Modelo de gestion
PAso2. Modelo de datos
PASO3. Modelo de procesos
PASO4.Generacion de aplicaciones
PASO4. Prueba y entrega
PASO5. verificación 

Comments

Popular posts from this blog

Temas del SubModulo II

1er Parcial