• Permite estudiar y después mejorar y ajustar el pro-
ceso 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 proveen una base de comparación. Por ejemplo, un vector de me- didas m1, m2,..., mn puede ser definido para caracterizar varios aspectos del producto en cierto punto, como pue- den ser el esfuerzo total realizado, los cambios, los defec- tos, los atributos lógico, físico y dinámico, consideracio- nes del entorno, etcétera. Así el observador puede decir como las características del producto como el tamaño, la complejidad, el acoplamiento y la cohesión incrementan o disminuyen en el tiempo. También puede monitorear- se 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.
55.5 Ventajas del desarrollo incre-
mental
• En este modelo los usuarios no tienen que esperar
hasta que el sistema completo se entregue para hacer uso de él. El primer incremento cumple los reque- rimientos más importantes de tal forma que pueden utilizar el software al instante.
• Los usuarios pueden utilizar los incrementos inicia-
les como prototipos y obtener experiencia sobre los requerimientos de los incrementos posteriores del sistema.
• Existe muy pocas probabilidades de riesgo en el sis-
tema. Aunque se pueden encontrar problemas en al- gunos incrementos, lo normal es que el sistema se entregue sin inconvenientes al usuario.
• Ya que los sistemas de más alta prioridad se entre-
gan primero, y los incrementos posteriores se inte- gran entre ellos, es muy poco probable que los sis- temas más importantes sean a los que se les hagan más pruebas. Esto quiere decir que es menos proba- ble que los usuarios encuentren fallas de funciona- miento del software en las partes más importantes del sistema.*[6]
55.6 Ventajas del desarrollo itera-
tivo
• En el desarrollo de este modelo se da la retroalimen-
tación muy temprano a los usuarios.
• Permite separar la complejidad del proyecto, gracias
a su desarrollo por parte de cada iteración o bloque.
• El producto es consistente y puntual en el desarrollo. • Los productos desarrollados con este modelo tienen
una menor probabilidad de fallar.
• Se obtiene un aprendizaje en cada iteración que es
aplicado en el desarrollo del producto y aumenta las experiencias para próximos proyectos.*[7]
55.7 Debilidades de este modelo de
desarrollo
• La entrega temprana de los proyectos produce la
creación de sistemas demasiados simples que a ve- ces se ven un poco monótonos a los ojos del personal que lo recibe.*[6]
• La mayoría de los incrementos se harán en base de
las necesidades de los usuarios. Los incrementos en si ya son estipulados desde antes de la entrega del proyecto, sin embargo hay que ver cómo se maneja el producto para ver si necesita otros cambios ade- más de los estipulados antes de la entrega del pro- yecto. Este problema no se ve frecuentemente ya que la mayoría de las veces los incrementos estipu- lados suplen satisfactoriamente al usuario.*[6]
• Los incrementos no deben constar de muchas líneas
de código ya que la idea de los incrementos es agre- gar accesorios al programa principal (o funcional), para que este tenga una y mil formas de desenvol- verse en su tarea; llenar los incrementos de muchas líneas de código provocaría que se perdiera la obje- tividad o base de lo que se trata el desarrollo incre- mental.*[6]
• Requiere de un cliente involucrado durante todo el
curso del proyecto. Hay clientes que simplemente no estarán dispuestos a invertir el tiempo necesario.
• El trato con el cliente debe basarse en principios
éticos y colaboración mutua, más que trabajar ca- da parte independientemente, defendiendo sólo su propio beneficio.*[8]
• La entrega de un programa que es parcial pero fun-
cional puede hacer vulnerable al programa debido a la falta de robustez en su sistema, provocando que agentes ajenos puedan interferir con el correcto fun- cionamiento del programa en sí.*[6]
• Infunde responsabilidad en el equipo de desarrollo
al trabajar directamente con el cliente, requiriendo de profesionales sobre el promedio.
• Sufre fuertes penalizaciones en proyectos en los cua-
les los requerimientos están previamente definidos, o para proyectos“todo/nada”en los cuales se requie- re que se completen en un 100% el producto para ser implementado (por ejemplo, licitaciones) otro pun- to muy importante es asegurarnos de que el trabajo se pueda cumplir tomando en cuenta los costos que podamos usar en nuestros propios recursos.
55.8 Véase también
• Scrum • Iteración • Desarrollo en cascada • Ingeniería de software • Desarrollo de software55.9 Referencias
[1] |Proceso de Desarrollo Iterativo|http://fernandosoriano. com.ar/?p=13
[2] |Desarrollo de software. Ciclo de vida iterativo in- cremental| https://jummp.wordpress.com/2011/03/31/ desarrollo-de-software-ciclo-de-vida-iterativo-incremental/
[3] |Desarrollo iterativo e incremental| http://www. proyectosagiles.org/desarrollo-iterativo-incremental
[4] |Modelo Iterativo| http://procesosoftware.wikispaces. com/Modelo+Iterativo
[5] Constantine, L. L., Lockwood, L. A. D.: Software for Use: A Practical Guide to the Models and Methods of Usage - Centred Design. Addison - Wesley ( 1999)
[6] Ian Sommerville (2005). «Entrega Incremental». Ingenie- ría del Software, Séptima edición edición... España: Pear- son.
[7] |Proceso de Desarrollo Iterativo|http://fernandosoriano. com.ar/?p=13
[8] |Desarrollo iterativo e incremental| http://www. proyectosagiles.org/desarrollo-iterativo-incremental
Capítulo 56
Detección dinámica de invariantes
La “generación dinámica de invariantes”es una téc- nica dinámica para el análisis informático, normalmente orientado a lapruebaymonitorización de software
56.1 Implementaciones
La implementación más famosa esDaikon
Diagrama de colaboración
Un diagrama de colaboración en las versiones deUML
1.x es esencialmente un diagrama que muestra interaccio- nes organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Por otra par- te, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
• Muestra cómo las instancias específicas de las clases
trabajan juntas para conseguir un objetivo común.
• Implementa las asociaciones del diagrama de clases
mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada “enlace”. Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de aso- ciación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación describen la con- figuración de los objetos y de los enlaces que pueden ocu- rrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempe- ñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del pro- cedimiento. Los símbolos de enlace pueden llevar este- reotipos para indicar enlaces temporales.
57.1 Usos
Un uso de un diagrama de colaboración es mostrar la im- plementación de una operación. La comunicación mues- tra los parámetros y las variables locales de la operación, así como asociaciones más permanentes. Cuando se im- plementa el comportamiento, la secuencia de los mensa- jes corresponde a la estructura de llamadas anidadas y el paso de señales del programa.
Un diagrama de secuencia muestra secuencias en el tiem- po como dimensión geométrica, pero las relaciones son
implícitas. Un diagrama de comunicación muestra rela- ciones entre roles geométricamente y relaciona los men- sajes con las relaciones, pero las secuencias temporales están menos claras.
57.2 Tipos
Es útil marcar los objetos en cuatro grupos: los que exis- ten con la interacción entera; los creados durante la in- teracción (restricción {new}); los destruidos durante la interacción (restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción {tran- sient}).
Aunque las comunicaciones muestran directamente la implementación de una operación, pueden también mos- trar la realización de una clase entera. En este uso, mues- tran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles múltiples que los objetos pueden desempe- ñar en varias operaciones.
No hay ejemplos de los diagramas, diferentes casos o sis- temas, ya que con UML se modelan áreas de un negocio así como los sistemas que estos requieren
57.3 Mensajes
Los mensajes se muestran como flechas etiquetadas uni- das a los enlaces. Cada mensaje tiene un número de se- cuencia, una lista opcional de mensajes precedentes, una condición opcional de guarda, un nombre, una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan se- cuencialmente. Los mensajes de diversos hilos son con- currentes a menos que haya una dependencia secuencial explícita. En conclusión en un diagrama muy sencillo de hacer.