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.
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.
Ingeniería de Software 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.
Al igual que todos los modelos de proceso, el enfoque DRA tiene
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.
0 Modelos de proceso del software
Modelo en cascada:
El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1.Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.
2.Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.
3.Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.
4.Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.
5.Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.
Cada fase tiene como resultado documentos que deben ser aprobados por el usuario.
Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.
Modelo de prototipo:
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final.
Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
Existen dos tipos de desarrollo evolutivo:
•Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.
•Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo están:
•La especificación puede desarrollarse de forma creciente.
•Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.
•Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:
•Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.
•Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.
•Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión.
Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.
Modelo formal de sistemas:
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.
Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación.
Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).
Observaciones sobre el desarrollo formal de sistemas:
•Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.
•Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.
•Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.
Modelo de desarrollo concurrente:
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto...La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
La figura siguiente proporciona una representación esquemática de una actividad dentro del modelo de proceso concurrente. La actividad "análisis" se puede encontrar en uno de los estados destacados anteriormente en cualquier momento dado. De forma similar otras actividades se pueden representar de una forma análoga. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicación con el cliente (no mostrada en la figura) ha finalizado su primera interacción y existe en el estado de cambios en espera. La actividad de análisis (que existía en el estado ninguno mientras que comenzaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.
El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparara la actividad de análisis del estado hecho al estado cambios en espera.
Modelo incremental:
sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Es una combinación del Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.
Entre las ventajas del modelo incremental se encuentran:
•Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.
•Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.
•Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.
•Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
•Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
•Cada incremento debe aumentar la funcionalidad.
•Es difícil establecer las correspondencias de los requisitos contra los incrementos.
•Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Modelo en espiral:
El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1.Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.
2.Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
3.Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.
4.Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.
Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc.
Modelo de desarrollo basado en componentes:
El desarrollo de aplicaciones por componentes se basa en la reutilización de código elaborado con anterioridad, este código en su momento fue probado, y su funcionalidad fue comprobada.
Mediante el uso de varios componentes simples se pueden construir proyectos bastante complejos los cuales si se realizaran desde el principio tomarían demasiado tiempo, de este modo lo que se tiene que hacer es revisar nuestros proyectos anteriores o comprar lo que necesitemos de otras personas, luego de esto podemos pasar a juntar las piezas que se van a reutilizar y las demás piezas que debemos obligatoriamente especificar para cada proyecto, ya que no todos los proyectos van a tener la misma oportunidad de reutilización.
No podemos tratar de hacer un proyecto totalmente con piezas preelaboradas ya que habrá partes que sean específicas para cada proyecto, y es mejor que lo que se reutilice sea muy general y bien probado para asegurar los resultados que se vayan a obtener de estos componentes.
Se debe producir software con el propósito de reutilizarlo en el desarrollo de aplicaciones futuras, si es proyecto así lo permite.
De este modo se pueden juntar o combinar partes hechas en distintos lugares, básicamente cuando existen diversos grupos de trabajo en distintos lugares, puede ser una ventaja porque cada grupo piensa únicamente en la finalización de su parte del proyecto y al final hay que juntar las piezas, sin embargo no se pueden pensar en combinar un numero demasiado grande de piezas, es mejor que sean pocas partes mas grandes (granularidad).
Es una muy buena opción usar código, documentación o interfaz graficas que uno mismo ha hecho y que en proyectos anteriores ya fueron usadas, probadas y que fueron efectivas para la venta de un producto, de este modo podemos establecer nuestro estilo en las aplicaciones que realicemos y así podemos hacer conocer nuestros productos y nuestro trabajo a otros desarrolladores que necesiten un componente que hayamos fabricado, pero para poder tener una buena cantidad de componentes reutilizables de nuestra autoría pasara mucho tiempo y varios proyectos.
Por otro lado también es muy eficiente comprar componentes de otras personas pero no se puede garantizar su correcto funcionamiento por lo que se debe verificar que este trabajando como uno espera.
0 Proceso de desarrollo de software
Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, . Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.
Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.
Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.
El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos:
1.Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.
2.Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación.
3.Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.
4.Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Además de estas actividades fundamentales, Pressman [1] menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación:
•Seguimiento y control de proyecto de software.
•Revisiones técnicas formales.
•Garantía de calidad del software.
•Gestión de configuración del software.
•Preparación y producción de documentos.
•Gestión de reutilización.
•Mediciones.
•Gestión de riesgos.
Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.
Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.
El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos:
1.Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.
2.Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación.
3.Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.
4.Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Además de estas actividades fundamentales, Pressman [1] menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación:
•Seguimiento y control de proyecto de software.
•Revisiones técnicas formales.
•Garantía de calidad del software.
•Gestión de configuración del software.
•Preparación y producción de documentos.
•Gestión de reutilización.
•Mediciones.
•Gestión de riesgos.
0 Calidad del Software
Calidad del software.
La calidad ha sido durante mucho tiempo una preocupación para las empresas, como lo debe ser para los analistas de sistemas en el análisis y diseño de sistemas de información.
Es demasiado arriesgado emprender todo el proceso de análisis y diseño sin usar un enfoque de aseguramiento de la calidad. Los tres enfoques para el aseguramiento de la calidad mediante ingeniería de software son: (1) garantizar el aseguramiento de la calidad total diseñando sistemas y software con un enfoque modular, descendente (de arriba abajo); (2) documentar el software con las herramientas adecuadas, y (3) probar, mantener y auditar el software.
Dos propósitos guían el aseguramiento de la calidad. El primero es que el usuario del sistema de información es el factor individual más importante en establecer y evaluar su calidad. El segundo es que mucho menos costoso corregir los problemas en sus fases iniciales que esperar hasta que un problema se manifiesta a trabes de las quejas o crisis del usuario.
Ya hemos aprendido acerca de la enorme inversión de mano de obra y otros recursos empresariales que se requieren para desarrollar con éxito un sistema. El uso del aseguramiento de la calidad a lo largo del proceso es una forma de reducir los riesgos, ayuda a garantizar que el sistema resultante será lo que se necesita y de sea, mejorara notablemente algún aspecto del desempeño del negocio. Este capítulo proporciona al análisis tres enfoques principales para la calidad.
La calidad ha sido durante mucho tiempo una preocupación para las empresas, como lo debe ser para los analistas de sistemas en el análisis y diseño de sistemas de información.
Es demasiado arriesgado emprender todo el proceso de análisis y diseño sin usar un enfoque de aseguramiento de la calidad. Los tres enfoques para el aseguramiento de la calidad mediante ingeniería de software son: (1) garantizar el aseguramiento de la calidad total diseñando sistemas y software con un enfoque modular, descendente (de arriba abajo); (2) documentar el software con las herramientas adecuadas, y (3) probar, mantener y auditar el software.
Dos propósitos guían el aseguramiento de la calidad. El primero es que el usuario del sistema de información es el factor individual más importante en establecer y evaluar su calidad. El segundo es que mucho menos costoso corregir los problemas en sus fases iniciales que esperar hasta que un problema se manifiesta a trabes de las quejas o crisis del usuario.
Ya hemos aprendido acerca de la enorme inversión de mano de obra y otros recursos empresariales que se requieren para desarrollar con éxito un sistema. El uso del aseguramiento de la calidad a lo largo del proceso es una forma de reducir los riesgos, ayuda a garantizar que el sistema resultante será lo que se necesita y de sea, mejorara notablemente algún aspecto del desempeño del negocio. Este capítulo proporciona al análisis tres enfoques principales para la calidad.
