Rup Metodologia De Modelamiento Unificado

INGENIERÍA DEL SOFTWARE

Es una disciplina o ciencias de la computación, que ofrece método y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Hoy día es cada vez más frecuente la consideración de la Ingeniería del Software como una área de la ingeniería, y el Ingeniero del Software comienza a ser una profesión implantada en el mundo laboralinternacional, con derechos, deberes y responsabilidades que cumplir, junto a una, y reconocida consideración social en el mundo empresarial.
La dificultad propia del desarrollo de software, y su impacto en el negocio, han puesto de manifiesto las ventajas y en innúmeros casos la necesidad de aplicar una metodología formal para llevar a cabo los proyectos de este tipo.
Muchos de los proyectos dedesarrollo de software fracasan o el resultado final no es el esperado, para el cliente o usuario final, o para los propios desarrolladores. Para el cliente un proyecto de desarrollo de software es infructífero porque se demoró más del tiempo esperado o peor aún, porque el software resultado no resuelve los problemas para los cuáles se encargó.
Varios son los factores que pueden conllevar al fracasode un proyecto de desarrollo de software. El modelamiento del negocio en la etapa de concepción de un proyecto de desarrollo de software es una de las actividades más importantes, y a veces no se lleva, provocando esto que no haya una total comprensión de los procesos a informatizar y un falso sentido de entendimiento entre los clientes (o usuarios) y el equipo de desarrollo respecto al trabajo arealizar.

1. Historia de los Procesos de Desarrollo
Uno de los grandes pasos dados en la industria del software fue aquel en que seplasmó el denominado modelo de cascada ya que sirvió como base para la formulación del análisis estructurado, el cual fue uno de los precursores en el camino hacia laaplicación de prácticas estandarizadas dentro de la ingeniería de software.
En esta época yaexistían modelos iterativos e incrementalespero no eran disciplinados ni estaban formalizados.
A consecuencia de esta realidad, la idea de tener un modelo que ordenara elproceso de desarrollo y que parecía bastante sencillo de llevar a la práctica hizo que elmodelo en cascada tuviese gran promoción. Este modelo se basaba en el desarrollo enforma de cascada ya que se requería de la finalización de laetapa anterior paraempezar la siguiente. Esto degeneraba en un “congelamiento” temprano de losrequerimientos, los cuales al presentar cambios requerían gran esfuerzo enretrabajo. Otra opción era no permitir cambio alguno a los requerimientos una vezque se iniciara el desarrollo lo que traía aparejado que el usuario no veía la aplicaciónhasta que ya estaba construida y una vez que interactuaba nocubría susnecesidades.
Asimismo, dadas las características inherentes del modelo, la fase deimplementación del mismo requería el desarrollo de los módulos en formaindependiente con las correspondientes pruebas unitarias, y en la siguiente fase,se realizaba la integración de los mismos. Esto traía grandes inconvenientes debidoa que todo estaba probado en forma unitaria sin interacción con losdemásmódulos. Las sorpresas llegaban cuando se integraban estas piezas para formar laaplicación; lo cual inevitablemente desembocaba en un retraso del proyecto,sacrificando la calidad del mismo.
De esta forma y en forma bastante temprana en algunos casos, fueronsurgiendo diversos procesos denominados iterativos que proponían lidiar con laimpredictibilidad del software (subsanando muchas de las falenciasdel modelo encascada) mitigando los riesgos en forma temprana. Los procesos iterativos de loscuales se desprenderían diversas instancias, como son el modelo iterativo eincremental, el modelo en espiral, el modelo basado en prototipo, el modelo SLCD, elMBASE, el RUP, etc.
Del modelo en espiral desarrollado por Bar ryBoehm surgió una de lasideas fundamentales que las metodologías posteriores...