La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:
- Modelo en cascada o Clásico (modelo tradicional)
- Modelo en espiral (modelo evolutivo)
- Modelo de prototipos
- Desarrollo por etapas
- Desarrollo iterativo y creciente o Interativo Incremental
- RAD (Rapid Application Development)
- Análisis de requisitos
- Diseño del Sistema
- Diseño del Programa
- Codificación
- Pruebas
- Implantación
- Mantenimiento
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.
Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante señalar que en esta etapa se deben consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.
Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras..
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.
Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.
Pruebas
Implantación
Mantenimiento
Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.
Desventajas
- En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
- Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.
- Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado, lo cual provoca una gran inseguridad por parte del cliente que anda ansioso de ver avances en el producto. Esto también implica toparse con requerimientos que no se habian tomado en cuenta, y que surgieron al momento de la implementación, lo cual provocara que se regrese nuevamente a la fase de requerimientos.
Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar.
El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
- Que necesidad debe cubrir el producto.
- Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
Características: experiencia del personal, requisitos a cumplir, etc.
Formas de gestión del sistema.
Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral.
- Angular: Indica el avance del proyecto software dentro de un ciclo.
- Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
Tareas Para cada ciclo habrá cuatro actividades:
Determinar o fijar objetivos
Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificación inicial o previa.
Análisis del riesgo
Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
Desarrollar, verificar y validar (probar)
-Tareas de la actividad propia y de prueba.
-Análisis de alternativas e identificación resolución de riesgos.
-Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.
Planificar
Mecanismos de control
La dimensión radial mide el coste.
La dimensión angular mide el grado de avance del proyecto.
Variaciones del Modelo En Espiral
-El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
-Reduce riesgos del proyecto
I-ncorpora objetivos de calidad
-Integra el desarrollo con el mantenimiento, etc.
-Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.
Desventajas
-Modelo costoso
-Requiere experiencia en la identificación de riesgos
Inconvenientes
Genera mucho trabajo adicional, y eso causa muchos problemas sobre todo si la compañía que esta produciendo el software es floja y holgazan. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil). El IEEE lo pone como modelo no operativo en sus clasificaciones de MCV.
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
-También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.
-La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.
Inconvenientes
En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.
Conclusiones
Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.
Que el prototipo se descarte, al menos en parte.
Que después se desarrolle el software real con un enfoque hacia la calidad.
Pueden distinguirse las siguientes fases:
- Especificación conceptual
- Análisis de requerimientos
- Diseño inicial
- Diseño detallado, codificación, depuración y liberación
- Estas diferentes fases se van repitiendo en cada etapa del diseño
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software.
1.1 Etapa de inicialización
1.2 Etapa de iteración
2 Caso práctico
3 Características
4 Debilidades de este modelo de desarrollo
Ciclo de vida
La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso eran comenzar con una implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté implementado. En cada iteración, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema.
El proceso en sí mismo consiste de:
Se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración, una lista de control de proyecto se crea, y esta lista contiene un historial de todas las tareas que necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y areas de rediseño de la solución ya existente. Esta lista de control se revisa periódica y constantemente como resultado de la fase de análisis.
Etapa de iteración
Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, y el análisis de la versión más reciente del sistema. La meta del diseño e implementación de cualquier iteración es ser simple, directa y modular, para poder soportar el rediseño de la etapa o como una tarea añadida a la lista de control de proyecto. El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del proyecto se modifica bajo la luz de los resultados del análisis.
Las guías primarias que guían la implementación y el análisis incluyen:
Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar a la necesidad de rediseñar o recodificar.
Las modificaciones deben ajustarse fácilmente a los módulos fáciles de encontrar y a los aislados. Si no es así, entonces se requiere algún grado de rediseño.
Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si dicha modificación no ocurre rápidamente, se debe aplicar algo de rediseño.
Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones. Si no es así, hay un problema primordial usualmente encontrado en un diseño débil o en la proliferación excesiva de parches al sistema.
Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el rediseño durante una fase de implementación.
La implementación existente debe ser analizada frecuentemente para determinar que tan bien se ajusta a las metas del proyecto.
Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el análisis de implementaciones parciales.
La opinión del usuario debe ser solicitada y analizada para indicar deficiencias en la implementación referida por él.
Caso práctico
La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una familia de lenguajes de programación en una gama de arquitecturas de hardware. Un conjunto de 17 versiones del sistema se desarrollaron en un lugar, generando 17 mil líneas de código fuente de lenguaje de alto nivel (6500 de código ejecutable). El sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a dos versiones diferentes del lenguaje base: una versión esencialmente se enfocaba en aplicaciones matemáticas, añadiendo números reales y varias funciones matemáticas, y la otra se centró en añadir capacidades para escribir del compilador. Cada iteración fue analizada del punto de vista de los usuarios (las capacidades del lenguaje fueron determinadas en parte por las necesidades del usuario) y el punto de vista del desarrollador (el diseño del compilador evolucionó para ser más fácilmente modificable, por ejemplo, para añadir nuevos tipos de datos). Mediciones tales como acoplamiento y modularización fueron seguidas sobre múltiples versiones.
Características
Usando análisis y mediciones como guías para el proceso de mejora es una diferencia mayor entre las mejoras iterativas y el desarrollo rápido de aplicaciones, principalmente por dos razones:
Proveé de soporte para determinar la efectividad de los procesos y de la calidad del producto.
Permite estudiar y después mejorar y ajustar el proceso para el ambiente en particular.
Estas mediciones y actividades de análisis pueden ser añadidas a los métodos de desarrollo rápido existentes.
De hecho, el contexto de iteraciones múltiples conlleva ventajas en el uso de mediciones. Las medidas a veces son difíciles de comprender en lo absoluto, aunque en los cambios relativos en las medidas a través de la evolución del sistema puede ser muy informativo porque proveén una base de comparación. Por ejemplo, un vector de medidas m1, m2,..., mn puede ser definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser el esfuerzo total realizado, los cambios, los defectos, los atributos lógico, físico y dinámico, consideraciones del entorno, etcétera. Así el observador puede decir como las carácterísticas del producto como el tamaño, la complejidad, el acoplamiento y la cohesión incrementan o disminuyen en el tiempo. También pude monitorearse el cambio relativo de varios aspectos de un producto o pueden proveer los límites de las medidas para apuntar a problemas potenciales y anomalías.
Debilidades de este modelo de desarrollo
Debido a la interacción con los usuarios finales, cuando sea necesaria la retroalimentación hacia el grupo de desarrollo, utilizar este modelo de desarrollo puede llevar a avances ser extremadamente lento.
Por la misma razón no es una aplicación ideal para desarrollos en los que de antemano se sabe que serán grandes en el consumo de recursos y largos en el tiempo.
Al requerir constantemente la ayuda de los usuario finales, se agrega un costo extra a la compañía, pues mientras estos usuarios evalúan el software dejan de ser directamente productivos para la compañía.
Desarrollo rápido de aplicaciones
Rapid application development (RAD) es un proceso de desarrollo de software (en inglés, software development process), 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 (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.
Hoy en día se suele utilizar para referirnos al desarrollo rápido de GUIs tal como Glade, o IDEs de desarrollo completas como Delphi, Foxpro o Anjuta. Uno de los programas más usados para hacer aplicaciones rápidamente es el Visual Basic.
Historia
Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1991.
Ventajas y desventajas
El desarrollo rápido tiene dos ventajas primarias:
Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE.
Calidad: según lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño.
El RAD tiene dos desventajas primarias:
Características reducidas.
Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo.
Herramientas RAD Multiplataforma
Icaria La plataforma MDA desarrollada por netZima. El analista que trabaja con Icaria® tiene conocimientos de diseño de sistemas y de los procesos de negocio que debe implantar. Sin embargo, no necesita conocimiento alguno de la tecnología en la que finalmente se generará el sistema.
NetBeans Herramienta Open Source
Eclipse Herramienta Open Source
WaveMaker WaveMaker Herramienta Open Source para aplicaciones Web2.0
Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
Lazarus Es un IDE cross-platform similar a Borland Delphi.
Real Basic Es un IDE cross-platform similar a Visual Basic.
Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
Microsoft Visual Studio 2005 / 2008
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).
Herramientas RAD para Escritorio
AppBuilder 1 2 3
Automated Architecure's Blue Ink
Borland C++Builder
Borland Delphi
Gambas
WinDev
Visual Basic
Ultimate++
NConstruct - .NET RAD herramienta para Winforms & Web
Herramientas RAD para Bases de Datos
Clarion Es una herramienta (ARAD) Advanced Rapid Application
FileMaker Pro Advanced
Omnis Studio
Oracle Forms
Oracle Application Express o APEX
Sybase PowerBuilder
WinDev
Magic Software uniPaaS
Servoy
NConstruct - .NET RAD herramienta para Winforms & Web
Microsoft Access
c++ builder
oracle 2000
power builder
Herramientas RAD Orientadas a la WEB WaveMaker [1] Herramienta Open Source para aplicaciones Web2.0
Django WebFramework para el desarrollo de aplicaciones web sobre Python.
37 Signals Ruby on Rails
Adobe ColdFusion
Symfony (PHP)
iRise 1
WebDev
Velneo
Leonardi
Microsoft Visual Studio 2005
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales.
NConstruct - .NET RAD herramienta para Winforms & Web
Historia [editar]
Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1991.
Ventajas y desventajas [editar]
El desarrollo rápido tiene dos ventajas primarias:
Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE.
Calidad: según lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño.
El RAD tiene dos desventajas primarias:
Características reducidas.
Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo.
Herramientas RAD Multiplataforma [editar]
Icaria La plataforma MDA desarrollada por netZima. El analista que trabaja con Icaria® tiene conocimientos de diseño de sistemas y de los procesos de negocio que debe implantar. Sin embargo, no necesita conocimiento alguno de la tecnología en la que finalmente se generará el sistema.
NetBeans Herramienta Open Source
Eclipse Herramienta Open Source
WaveMaker WaveMaker Herramienta Open Source para aplicaciones Web2.0
Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
Lazarus Es un IDE cross-platform similar a Borland Delphi.
Real Basic Es un IDE cross-platform similar a Visual Basic.
Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
Microsoft Visual Studio 2005 / 2008
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).
Herramientas RAD para Escritorio [editar]
AppBuilder 1 2 3
Automated Architecure's Blue Ink
Borland C++Builder
Borland Delphi
Gambas
WinDev
Visual Basic
Ultimate++
NConstruct - .NET RAD herramienta para Winforms & Web
Herramientas RAD para Bases de Datos [editar]
Clarion Es una herramienta (ARAD) Advanced Rapid Application
FileMaker Pro Advanced
Omnis Studio
Oracle Forms
Oracle Application Express o APEX
Sybase PowerBuilder
WinDev
Magic Software uniPaaS
Servoy
NConstruct - .NET RAD herramienta para Winforms & Web
Microsoft Access
c++ builder
oracle 2000
power builder
Herramientas RAD Orientadas a la WEB [editar]
WaveMaker [1] Herramienta Open Source para aplicaciones Web2.0
Django WebFramework para el desarrollo de aplicaciones web sobre Python.
37 Signals Ruby on Rails
Adobe ColdFusion
Symfony (PHP)
iRise 1
WebDev
Velneo
Leonardi
Microsoft Visual Studio 2005
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales.
NConstruct - .NET RAD herramienta para Winforms & Web
Véase también
Entorno de desarrollo integrado
Referencias externas
blueink.biz - Rapid Application Development - Más detalles sobre RAD y herramientas de desarrollo.
Información sobre RAD
What is Application Development?.
Obtenido de "http://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicaciones"Entorno de desarrollo integrado
Referencias externas blueink.biz - Rapid Application Development - Más detalles sobre RAD y herramientas de desarrollo.
Información sobre RAD
What is Application Development?.