Este documento describe el método de Desarrollo Rápido de Aplicaciones (RAD), el cual enfatiza un corto ciclo de desarrollo utilizando componentes reutilizables y herramientas automatizadas. El RAD asume el uso de técnicas de cuarta generación y la reutilización de componentes existentes. Algunas características clave del RAD son los equipos híbridos interdisciplinarios, herramientas especializadas y un proceso iterativo que involucra prototipos y retroalimentación de usuarios.
Universidad Politécnica de Tecamac
Desarrollo de aplicaciones móviles
Jazmin Reyes Becerra
Sistema Dual
Metodologías para desarrollar(moviles )
Ing. en Software
Universidad Politécnica de Tecamac
Desarrollo de aplicaciones móviles
Jazmin Reyes Becerra
Sistema Dual
Metodologías para desarrollar(moviles )
Ing. en Software
La Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software. Integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería. Define paradigmas de desarrollo estructurado como base a seguir en un proyecto de Software. Si ninguno de estos paradigmas se adecua al problema por resolver, entonces el desarrollador se verá obligado a combinar los paradigmas o definir uno nuevo.
Presentación del taller sobre la Metodología de la Red Nacional de Integración y Desarrollo de Software Libre (MeRinde), realizada en el Sexto Congreso Nacional de Software Libre, en fecha 16 de Abril de 2010, instalaciones de la Universidad Bolivariana de Venezuela,
MeRinde más comunitaria que nunca
Metodologías para el desarrollo en dispositivos móvilesFernand Bernowly
Universidad Politécnica de Tecamac
Desarrollo de aplicaciones móviles
Juan Fernando Ramirez Hernandez
Sistema Dual
Metodologías para el desarrollo en dispositivos móviles
Ing. en Software
2817IS
A partir de este paso y en adelante el equipo de desarrollo software trabaja para tirar adelante el proyecto. El equipo se reúne con varios depositarios de dominio del problema, e intentan conseguir la máxima cantidad de información posible sobre lo que requieren. Los requisitos se contemplan y agrupan en requisitos del usuario, requisitos funcionales y requisitos del sistema. La recolección de todos los requisitos se lleva a cabo como se especifica a continuación
Estudio de viabilidad
Después de la recolección de requisitos, el equipo idea un plan para procesar el software. En esta fase, el equipo analiza si el software puede hacerse para cubrir todos los requisitos del usuario y si hay alguna posibilidad de que el software ya no sea necesario.
La Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software. Integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería. Define paradigmas de desarrollo estructurado como base a seguir en un proyecto de Software. Si ninguno de estos paradigmas se adecua al problema por resolver, entonces el desarrollador se verá obligado a combinar los paradigmas o definir uno nuevo.
Presentación del taller sobre la Metodología de la Red Nacional de Integración y Desarrollo de Software Libre (MeRinde), realizada en el Sexto Congreso Nacional de Software Libre, en fecha 16 de Abril de 2010, instalaciones de la Universidad Bolivariana de Venezuela,
MeRinde más comunitaria que nunca
Metodologías para el desarrollo en dispositivos móvilesFernand Bernowly
Universidad Politécnica de Tecamac
Desarrollo de aplicaciones móviles
Juan Fernando Ramirez Hernandez
Sistema Dual
Metodologías para el desarrollo en dispositivos móviles
Ing. en Software
2817IS
A partir de este paso y en adelante el equipo de desarrollo software trabaja para tirar adelante el proyecto. El equipo se reúne con varios depositarios de dominio del problema, e intentan conseguir la máxima cantidad de información posible sobre lo que requieren. Los requisitos se contemplan y agrupan en requisitos del usuario, requisitos funcionales y requisitos del sistema. La recolección de todos los requisitos se lleva a cabo como se especifica a continuación
Estudio de viabilidad
Después de la recolección de requisitos, el equipo idea un plan para procesar el software. En esta fase, el equipo analiza si el software puede hacerse para cubrir todos los requisitos del usuario y si hay alguna posibilidad de que el software ya no sea necesario.
Este trabajo fue hecho por los alumnos del Colegio Manuel Carlos Piar 3er "B"
*Aldahir Gonzalez
*Fabiana Suarez
*Franklin Leon
*Hector Rivero
*Simon Palacios
*Jesus uriza
UDABOL ISI311
Integrantes:
Claudia Andrea Leaños Gonzales
Edwin Condori Gonzales
Carlos Eduardo ramos Cáceres
carrera:
Ingeniería de sistemas
Facultad:
Análisis y diseño de sistemas
Docente:
Ing. David Enrique Mendoza Gutiérrez
1. TEMA:
RAD
NOMBRE:
HENRY CAMBAL
CARRERA:
SISTEMAS
ASIGNATURA:
SISTEMAS DE INFORMACION
TUTOR:
ING. JOHN TOASA
FECHA DE ENTREGA:
01/08/2012
2. El desarrollo rápido de aplicaciones o
RAD (Rapid Application
Development) 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.
3. 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.
4. 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?
5. 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.
6. 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.
7. 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.
8. 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.
9.
10. Entre las principales características del RAD
tenemos:
1. Equipos Híbridos
Equipos compuestos por alrededor de seis
personas, incluyendo
desarrolladores y usuarios de tiempo
completo del sistema así como
aquellas personas involucradas con los
requisitos.
Los desarrolladores de RAD deben ser
"renacentistas": analistas,
diseñadores y programadores en uno.
11. 2. Herramientas Especializadas
Desarrollo "visual"
Creación de prototipos falsos (simulación
pura)
Creación de prototipos funcionales
Múltiples lenguajes
Calendario grupal
Herramientas colaborativas y de trabajo en
equipo
Componentes reusables
Interfaces estándares (API)
Control de versiones
12. Reunión JAD (Joint Application Development):
o Se reúnen los usuarios finales y los desarrolladores.
o Lluvia de ideas para obtener un borrador inicial de los requisitos.
Iterar hasta acabar:
o Los desarrolladores construyen y depuran el prototipo basado en
los requisitos actuales.
o Los diseñadores revisan el prototipo.
o Los clientes prueban el prototipo, depuran los requisitos.
o Los clientes y desarrolladores se reunen para revisar juntos el
producto, refinar los requisitos y generar solicitudes de cambios.
o Los cambios para los que no hay tiempo no se realizan. Los
requisitos secundarios se eliminan si es necesario para cumplir
el calendario.
13. La aplicación funcionará de manera
independiente.
Se pueden usar mayormente bibliotecas
existentes.
Desempeño no crítico.
Distribución limitada, interna o vertical.
Alcance del proyecto limitado.
Confiabilidad no crítica.
El sistema puede dividirse en muchos
módulos independientes.
El producto está dirigido a un mercado
altamente especializado.
14. La aplicación debe interoperar con sistemas
existentes.
Existen pocos componentes reutilizables.
Alto desempeño crítico.
El desarrollo no puede aprovechar herramientas de
alto nivel.
Distribución amplia, horizontal o masiva.
RAD se convierta en QADAD (Quick And Dirty
Application Development).
Métodos RAD para desarrollar sistemas operativos
(confiabilidad
demasiado alta) o juegos (desempeño demasiado
alto).
Riesgos técnicos de tecnología de punta.
15. Comprar puede ahorrar dinero en
comparación con construir.
Los entregables pueden ser fácilmente
trasladados a otra plataforma.
El desarrollo se realiza a un nivel de
abstracción mayor.
Visibilidad temprana.
Ingeniería de Software
Mayor flexibilidad.
Menor codificación manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
16. Comprar puede ser más caro que construir.
Costo de herramientas integradas y equipo
necesario.
Progreso más difícil de medir.
Menos eficiente.
Menor precisión científica.
Riesgo de revertirse a las prácticas sin control de
antaño.
Más fallas (por síndrome de "codificar a lo
bestia").
Prototipos pueden no escalar, un problema
mayúsculo.
Funciones reducidas (por "timeboxing").