Recent post
Modelo
de Desarrollo de Software
¿Que es un modelo de desarrollo?
Representación de la realidad por medio de abstracciones. Los modelos
enfocan ciertas partes importantes de un sistema (por lo menos, aquella que le
interesan a un tipo de modelo específico), restándole importancia a otras.
¿Qué es un modelo de desarrollo del software?
Un modelo de desarrollo es una representación abstracta de un proceso de
software, cada modelo representa el proceso de desarrollo de software de una
manera en particular. A pesar de estar definidos claramente, no representan
necesariamente la realidad de cómo se debe desarrollar el software, sino que
establece un enfoque común. Un modelo puede ser modificado y adaptado de
acuerdo a las necesidades del software en desarrollo.
Aunque existen muchos
tipos de modelos de desarrollo, de forma genérica la mayoría está clasificada
en una de estas 3 categorías, y estos a pesar de ser diferentes a veces son
usados de manera simultáneamente especialmente en sistemas grandes
Que incluye un modelo desarrollo:
En forma general podemos clasificar los modelos de desarrollo en 3 grupos:
1. El modelo en cascada. Considera las actividades
fundamentales del proceso de especificación, desarrollo, validación y
evolución, y los representa como fases separadas del proceso, tales como la
especificación de requerimientos, el diseño del software, la implementación,
las pruebas, etcétera.
2. Desarrollo evolutivo. Este enfoque entrelaza las
actividades de especificación, desarrollo y validación. Un sistema inicial se
desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina
basándose en las peticiones del cliente para producir un sistema que satisfaga
sus necesidades.
3. Ingeniería del software basada en componentes. Este
enfoque se basa en la existencia de un número significativo de componentes
reutilizables. El proceso de desarrollo del sistema se enfoca en integrar estos
componentes en el sistema más que en desarrollarlos desde cero.
Ventajas y desventajas de modelos de desarrollo de Software:
Ventajas
ü 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.
ü Mayor flexibilidad.
ü Menor codificación
manual.
ü Mayor involucramiento de
los usuarios.
ü Posiblemente menos
fallas.
ü Posiblemente menor
costo.
ü Ciclos de desarrollo más
pequeños.
Desventajas
ü 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 mala codificación).
ü Prototipos pueden no
escalar, un problema mayúsculo.
ü Funciones reducidas (por
"timeboxing").
ü Dependencia en
componentes de terceros: funcionalidad de más o de menos, problemas legales.
INTRODUCCIÓN
El
modelo de prototipos permite que todo el sistema, o algunos de sus partes, se
construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos
en los que se aseguren que el desarrollador, el usuario, el cliente estén de
acuerdo en lo que se necesita así como también la solución que se propone para
dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el
desarrollo, este modelo se encarga del desarrollo de diseños para que estos
sean analizados y prescindir de ellos a medida que se adhieran nuevas
especificaciones, es ideal para medir el alcance del producto, pero no se
asegura su uso real.
Este
modelo principalmente se lo aplica cuando un cliente define un conjunto de
objetivos generales para el software a desarrollarse sin delimitar
detalladamente los requisitos de entrada procesamiento y salida, es decir
cuando el responsable no está seguro de la eficacia de un algoritmo, de la
adaptabilidad del sistema o de la forma en que interactúa el hombre y la
máquina. Este modelo se encarga principalmente de ayudar al ingeniero de
sistemas y al cliente a entender de mejor manera cuál será el resultado de la
construcción cuando los requisitos estén satisfechos.
Modelo de Desarrollo de
Software de Prototipos
El paradigma de construcción de prototipos tiene tres
pasos:
ü Escuchar al cliente. Recolección de requisitos. Se
encuentran y definen los objetivos globales, se identifican los requisitos
conocidos y las áreas donde es obligatorio más definición.
ü Construir y revisar la maqueta (prototipo).
ü El cliente prueba la maqueta (prototipo) y lo utiliza
para refinar los requisitos del software.
Este modelo es útil cuando:
ü El cliente no identifica los requisitos detallados.
ü El responsable del desarrollo no está seguro de la
eficiencia de un algoritmo, sistema operativo o de la interface hombre-máquina.
Etapas para la elaboración del Modelo de Prototipo.
Ciclo de Vida de un
Sistema basado en Prototipos
Una maqueta o prototipo de pantallas muestra
la interfaz de la aplicación, su cara externa, pero dicha interfaz está fija,
estática, no procesa datos. El prototipo no tiene desarrollada una lógica
interna, sólo muestra las pantallas por las que irá pasando la futura
aplicación.
Por su parte, el prototipo funcional
evolutivo desarrolla un comportamiento que satisface los requisitos y
necesidades que se han entendido claramente. Realiza, por tanto, un proceso
real de datos, para contrastarlo con el usuario. Se va modificando y
desarrollando sobre la marcha, según las apreciaciones del cliente. Esto
ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el
software está constantemente variando, pero,
a la larga, genera un producto más seguro, en cuanto a la satisfacción
de las necesidades del cliente.
Cuando un prototipo se desarrolla con el sólo
propósito de precisar mejor las necesidades del cliente y después no se va a
aprovechar ni total ni parcialmente en la implementación del sistema final se habla
de un prototipo desechable, para que la construcción de prototipos sea posible
se debe contar con la participación activa del cliente.
Ventajas
del Modelo Prototipos
Este modelo es útil cuando el cliente conoce
los objetivos generales para el software, pero no identifica los requisitos
detallados de entrada, procesamiento o salida. 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.
Desventajas
del Modelo Prototipos
Su principal desventaja es que una vez que el
cliente ha dado su aprobación final al prototipo y cree que está a punto de
recibir el proyecto final, se encuentra con que es necesario reescribir buena
parte del prototipo para hacerlo funcional, porque lo más seguro es que el
desarrollador haya hecho compromisos de implementación para hacer que el
prototipo funcione rápidamente. Es posible que el prototipo sea muy lento, muy
grande, no muy amigable en su uso, o incluso, que esté escrito en un lenguaje
de programación inadecuado.
El cliente ve funcionando lo que para él es
la primera versión del prototipo que ha sido construido con "plastilina y
alambres", y puede desilusionarse al decirle que el sistema aún no ha sido
construido. El desarrollador puede ampliar el prototipo para construir el
sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento
que tiene con el cliente.
INTRODUCCIÓN
En un desarrollo iterativo e incremental el proyecto se
planifica en diversos bloques temporales (en el caso de Scrum de un mes natural
o hasta de dos semanas, si así se necesita) llamados iteraciones.
Las iteraciones se pueden entender como miniproyectos: en
todas las iteraciones se repite un proceso de trabajo similar (de ahí el nombre
“iterativo”) para proporcionar un resultado completo sobre producto final, de
manera que el cliente pueda obtener los beneficios del proyecto de forma
incremental. Para ello, cada requisito se debe completar en una única
iteración: el equipo debe realizar todas las tareas necesarias para completarlo
(incluyendo pruebas y documentación) y que esté preparado para ser entregado al
cliente con el mínimo esfuerzo necesario. De esta manera no se deja para el
final del proyecto ninguna actividad arriesgada relacionada con la entrega de
requisitos.
Modelo de Desarrollo de
Software Interactivo Incremental
En cada iteración el equipo evoluciona el producto (hace
una entrega incremental) a partir de los resultados completados en las
iteraciones anteriores, añadiendo nuevos objetivos/requisitos o mejorando los
que ya fueron completados. Un aspecto fundamental para guiar el desarrollo
iterativo e incremental es la priorización de los objetivos/requisitos en
función del valor que aportan al cliente.
Beneficios
Se puede gestionar las expectativas del cliente
(requisitos desarrollados, velocidad de desarrollo, calidad) de manera regular,
puede tomar decisiones en cada iteración. Esto es especialmente interesante
cuando el cliente no sabe exactamente qué es lo que necesita, lo va sabiendo
conforme va viendo cuales son los resultados del proyecto. El cliente necesita
hacer cambios a corto plazo (nuevos requisitos o a cambios en los ya
realizados) por:
ü Cambios en las
condiciones del mercado (por un cambio de necesidades, por un nuevo producto
que ha lanzado la competencia, urgencias).
ü La reacción y aceptación
del mercado respecto al uso de los primeros resultados del proyecto.
ü Cualquier cambio en el
entorno (recursos, etc.), que pueda incluso finalizar el proyecto manteniendo
como mínimo los resultados alcanzados hasta ese momento.
El equipo necesita saber si lo que ha entendido es lo que
el cliente espera, el cliente puede comenzar el proyecto con requisitos de alto
nivel, quizás no del todo completos, de manera que se vayan refinando en
sucesivas iteraciones. Sólo es necesario conocer con más detalle los requisitos
de las primeras iteraciones, los que más valor aportan. No es necesario
realizar una recolección completa y detallada de todos los requisitos antes de
empezar el desarrollo del proyecto.
El cliente puede obtener resultados importantes y usables
ya desde las primeras iteraciones. Se puede gestionar de manera natural los
cambios que van apareciendo durante el proyecto. La finalización de cada
iteración es el lugar natural donde el cliente puede proporcionar su feedback
tras examinar el resultado obtenido (ver control empírico y demostración). Con
esta información ya es posible planificar los cambios necesarios para alinearse
con las expectativas del cliente desde las primeras iteraciones, de manera que
al finalizar el proyecto el cliente obtenga los objetivos esperados.
El cliente como máximo puede perder los recursos
dedicados a una iteración, no los de todo el proyecto. La finalización de cada
iteración es el lugar natural donde el equipo puede decidir cómo mejorar su
proceso de trabajo, en función de la experiencia obtenida. Con esta información
ya es posible planificar los cambios necesarios para aumentar la productividad
y calidad desde las primeras iteraciones.
Permite conocer el progreso real del proyecto desde las
primeras iteraciones y extrapolar si su finalización es viable en la fecha prevista.
El cliente puede decidir priorizar los requisitos del proyecto, añadir nuevos
equipos, cancelarlo, etc, permite mitigar desde el inicio los riesgos del
proyecto. Desde la primera iteración el equipo tiene que gestionar los
problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes
estos riesgos, es posible iniciar su
mitigación de manera anticipada.
Permite gestionar la complejidad del proyecto.
ü En una iteración sólo se
trabaja en los requisitos que aportan más valor en ese momento.
ü Se puede dividir la
complejidad para que cada parte sea resuelta en diferentes iteraciones.
Dado que cada iteración debe dar como resultado
requisitos terminados, se minimiza el número de errores que se producen en el
desarrollo y se aumentar la calidad.
Restricciones
La disponibilidad del cliente debe ser alta durante todo
el proyecto dado que participa de manera continua:
ü El inicio de una
iteración, el cliente ha de detallar (o haber detallado previamente) los
requisitos que se van a desarrollar.
ü En la finalización de
cada iteración, el cliente ha de revisar los requisitos desarrollados.
La relación con el cliente ha de estar basada en los
principios de colaboración y ganar/ganar más que tratarse de una relación
contractual en la cual cada parte únicamente defiende su beneficio a corto
plazo. Cada iteración debe dar como resultado requisitos terminados, de manera
que el resultado sea realmente útil para el cliente y no deje tareas pendientes
para futuras iteraciones o para la finalización del proyecto.
Cada iteración ha de aportar un valor al cliente,
entregar unos resultados cerrados que sean susceptibles de ser utilizados por
él, es necesario disponer de técnicas y herramientas que permitan hacer cambios
fácilmente en el producto, de manera que pueda crecer en cada iteración de
manera incremental sin hacer un gran esfuerzo adicional, manteniendo su
complejidad minimizada y su calidad.
Recomendaciones
Utilizar iteraciones cortas de 2 a 4 semanas incrementa
la productividad del proyecto, dado que el equipo trabaja de forma más
eficiente cuando tiene objetivos a corto plazo. Asimismo, con iteraciones
cortas la precisión de las estimaciones aumenta. El tamaño depende de:
ü Los condicionantes del
proyecto.
ü La necesidad de tener
feedback más o menos rápido.
ü Que no se degrade la
relación trabajo útil / gestión operativa (por ejemplo reuniones, actividades
necesarias que no producen valor directo, etc.).
Utilizar iteraciones regulares, de manera que todas sean
un timebox de la misma duración. El equipo aprende a calcular la velocidad de
desarrollo, la cantidad de trabajo que puede hacer en una iteración (sin tener
que hacer extrapolaciones si las iteraciones no fuesen regulares), el cliente
puede proyectar cuantas iteraciones se necesitan para tener cada entrega, en
función de la velocidad de desarrollo del equipo (el trabajo que pudo completar
en iteraciones anteriores del mismo tamaño), y tomar decisiones al respecto.
Permite gestionar y sincronizar de manera sencilla las
necesidades del proyecto con respecto a las de otros proyectos (integración con
el trabajo realizado por otros equipos, compartición de personas que son
difíciles de asignar a un único equipo), las iteraciones coincidiendo con meses
naturales permiten sincronizar el trabajo del equipo con el de otros
departamentos y con el resto de la organización (por ejemplo, la organización
puede tener medidas de resultados y objetivos a nivel trimestral o
cuatrimestral).
Ventajas
ü Con un paradigma
incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la
funcionalidad parcial.
ü También provee un impacto
ventajoso frente al cliente, que es la entrega temprana de partes operativas del
software.
ü Resulta más sencillo
acomodar cambios al acotar el tamaño de los incrementos.
Desventajas
ü Requiere de mucha
planeación, tanto administrativa como técnica.
ü Requiere de metas claras
para conocer el estado del proyecto.
INTRODUCCIÓN
El desarrollo de los sistemas tradicionales de ciclo de
vida se originó en la década de 1960 para desarrollar a gran escala funcional
de sistemas de negocio en una época de grandes conglomerados empresariales. La
idea principal era continuar el desarrollo de los sistemas de información en
una muy deliberada, estructurada y metódica, reiterando cada una de las etapas
del ciclo de vida. Los sistemas de información en torno a las actividades
resueltas pesadas para el procesamiento de datos y rutinas de cálculo.
El desarrollo rápido de aplicaciones o RAD (acronimo en
inglés de 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 (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.
Modelo de
Desarrollo de Software RAD
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.
INCONVENIENTES DEL
RAD
Para proyectos grandes aunque por escalas, el DRA
requiere recursos humanos suficientes como para crear el número 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.
¿PORQUÉ USAR RAD?
Malas razones
ü Prevenir presupuestos rebasados (RAD necesita un equipo
disciplinado en manejo de costos).
ü Prevenir incumplimiento de fechas (RAD necesita un equipo
disciplinado en manejo de tiempo).
Buenas razones
ü
Convergir
tempranamente en un diseño aceptable para el cliente y posible para los
desarrolladores.
ü
Limitar
la exposición del proyecto a las fuerzas de cambio.
ü
Ahorrar
tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del
producto.
CARACTERÍSTICAS DE
RAD
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.
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)
"Timeboxing"
Las funciones secundarias son eliminadas como sea
necesario para cumplir con el calendario.
Prototipos Iterativos y Evolucionarios.
ü
Reunión
JAD (Joint Application Development):
ü
Se reúnen
los usuarios finales y los desarrolladores.
ü
Lluvia
de ideas para obtener un borrador inicial de los requisitos.
ü
Iterar
hasta acabar:
ü
Los
desarrolladores construyen y depuran el prototipo basado en los requisitos
actuales.
ü
Los
diseñadores revisan el prototipo.
ü
Los
clientes prueban el prototipo, depuran los requisitos.
ü
Los
clientes y desarrolladores se reúnen para revisar juntos el producto, refinar
los requisitos y generar solicitudes de cambios.
ü
Los
cambios para los que no hay tiempo no se realizan. Los requisitos secundarios
se eliminan si es necesario para cumplir el calendario.
VENTAJAS
ü
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.
ü
Mayor
flexibilidad.
ü
Menor
codificación manual.
ü
Mayor
involucramiento de los usuarios.
ü
Posiblemente
menos fallas.
ü
Posiblemente
menor costo.
ü
Ciclos
de desarrollo más pequeños.
ü
Interfaz
gráfica estándar.
DESVENTAJAS
ü
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”).
ü
Dependencia
en componentes de terceros: funcionalidad de más o de menos, problemas legales.
