En nuestra etapa formativa como ingenieros y ya en nuestra etapa
profesional, se presenta una malinterpretación de la metodología RUP,
provocando aversión y buscando esquivar su implementación en detrimento de
otras más conocidas, pero las ventajas que ofrece RUP en cuanto a calidad de
software debido a su minuciosidad son rescatables, al ser una metodología
orientada a casos de uso, y en la que al final de cada fase se realiza una
evaluación para ver el nivel de consecución de metas se pretende crear un
ambiente seguro, permitiendo determinar con minuciosidad si se han cumplido con
las metas y los estándares propuestos antes de avanzar a la siguiente fase, además
al ser una metodología más dinámica debido a que los registros de sus avances y
su seguimiento se realiza por medio de herramientas de “Rational Software” junto
con el Lenguaje Unificado de Modelado (UML) se puede interpretar de una manera
más fácil su implementación y su destino final.
Algunas de las dificultades más comunes que se presentan con RUP y sus
soluciones son: (Tomadas de
http://elblogdelfrasco.blogspot.com.co/2008/07/dificultades-comunes-al-implementar-rup.html)
Dificultades Comunes en Inception
Demasiada formalidad / Demasiados
artefactos
·
Sólo producir los artefactos que agreguen valor.
·
Minimizar la formalidad si es posible.
·
Cuando es dudoso el valor que aporta algún artefacto, no realizarlo.
La Parálisis del Análisis
·
Los artefactos se pueden mejorar más tarde.
·
Es importante avanzar, no estancarse en el análisis.
·
Mantener foco en los objetivos de la fase de Inception.
·
No describir todos los requerimientos en detalle.
Iteración Inicial muy Larga
·
Recortar el alcance rápidamente.
·
Si la primera iteración falla, el proyecto entero estará destinado a
fallar.
Dificultades Comunes en Elaboration
Dejar la "Parte Difícil" para
Después
·
Atacar los riesgos en forma temprana, o los riesgos lo atacarán
a usted.
·
Atacar la parte difícil ahora, para tener una vida más fácil después.
No Implementar ni Validar la Arquitectura
·
No se puede obtener una arquitectura correcta o abordar los riesgos
principales sin implementar y testear la arquitectura.
·
Construir una Arquitectura Ejecutable y Testearla.
Los Cambios No Son Bienvenidos
·
Los cambios permiten mejorar.
Dificultades Comunes en Construction
Basar el Trabajo en una Arquitectura
Inestable
·
Mayor retrabajo y bugs de integración.
·
El precio a pagar por un trabajo insuficiente en la fase de Elaboration es
alto.
Reinventar Soluciones a Problemas
Comunes
·
¿Fueron desarrollados los patrones de arquitectura en la fase de Elaboration y
comunicados a todo el equipo?
No se realiza Integración Continua
·
Un build diario o semanal minimiza la reiteración en el mismo trabajo.
Las Pruebas no se Inician hasta el
Final de la Construcción
·
Es muy probable que en el desarrollo no se llegue a los deadlines.
·
La versión beta puede resultar de tan baja calidad, que
está ni siquiera daría un valor agregado.
Dificultades Comunes en Transition
No Toda la Funcionalidad fue Testeada
·
¿Se hizo una inclusión o inserción de una funcionalidad que no había
sido testeada en la release?
·
¿La release es utilizable (Fácil de usar, reutilizable,
versátil, relacional, documentada)?
El Cliente no está Contento con en
desarrollo o la Funcionalidad Entregada
·
¿Los clientes aprobaron los criterios de aceptación al desarrollo?
·
¿Estuvo involucrado el cliente en el desarrollo del proyecto?
Las dificultades presentadas con la implementación de esta metodología
puede darse debido a que esta funciona mejor para proyectos los cuales
presentan un grado de funcionalidad más robusto o complejo, por lo que está
diseñado para tolerar en menor cantidad el número de fallas, de esta forma
procura que todos los stakeholders así queden satisfechos.
ya que en ocasiones puede resultar en un proceso de desarrollo denso,
con alto número de interrupciones y errores, que a la larga se transforman en trabas,
si este es un desarrollo desde cero, que debe pasar por la fase de inception se
deben dejar claros para todos los actores los objetivos para un mejor provecho
en el proyecto; al ser un desarrollo que evalúa los cumplimientos que fueron
evaluados en la elección de objetivos en cada fase, si se presentan problemas
desde sus primeras etapas hasta el final del ciclo, lo más probable es que el
producto resultante no acapare las soluciones o los resultados esperados.
Esta rigurosidad puede afectar la visión que tienen los usuarios sobre
la metodología de RUP, dándola a conocer
como una metodología con un alto grado de rigurosidad, complejidad y robustas
especificaciones; en cambio, si el proyecto es una mejora de software
existente, su uso se implementara con el objetivo de centrarse específicamente viabilidad
y sustentación del proyecto en ejecución. Una vez se cumplan todas las metas,
se encuentre claro el alcance con sus condiciones y la viabilidad del proyecto
se procede a la fase de elaboración.
Para esta nueva fase se tiene como fin establecer la arquitectura base
del sistema, es necesario evaluar cada uno de los riesgos y tomar en cuenta así
los puntos más importantes de cada requerimiento, esto con el fin de escoger la
arquitectura más adecuada para el desarrollo esperado; de esta forma culminar
cumpliendo con el objetivo de que el diseño y la implementación sean rápidos y
cumplan a cabalidad sus objetivos.
En la fase de construcción se aclararan cada uno de los requerimientos
faltantes, así se completa completa el desarrollo del sistema basado en la
arquitectura en referencia establecida en la fase de elaboración; aquí se busca
optimizar y reducir los costos, mejorar la calidad del producto, reducir el
estimado de tiempo y utilizando los recursos otorgados de forma eficaz y
eficiente.
En la etapa de transición el software, ya sea que este se encuentre en
sus primeras etapas debe estar disponible para los usuarios, con el fin de que
haya una retroalimentación que permita depurar el producto, realizarle ajustes
a su configuración y su modo de uso, para que sea lo más cercano a las
especificaciones del usuario y cumpla con todos sus requerimientos.
Al ser un desarrollo Iterativo brinda facilidades de mejora al poder ir
probando cada una de sus ejecuciones, lo que representa una cualidad
fundamental e ideal para el desarrollo, ya que esto permite que sea adaptable y
este en constante crecimiento, optimización y evolución; en paralelo sus adaptaciones promueven que sus módulos
pueden ser reutilizados, lo que disminuye costos y tiempo lo que se traduce en
atención más rápida a las necesidades o solicitud de los clientes.
Una de sus grandes falencias y por la cual es poco comprendida esta
metodologia, es por el alto nivel de experticia que se sugiere debe tener cada
uno de los miembros del equipo para que este sea ejecutado en sus tareas, ya
que por su minuciosidad no es fácil realizar un desarrollo de software
utilizando las pautas que brinda este método; ya que tiende a ser compleja y un
poco desorganizada y dependiendo de la experticia de los miembros, la
reutilización de componentes puede llegar a ser compleja, además, al ser
software Rational se tiene que usar (Comprar) todo el paquete dispuesto por IBM
|
PROS
|
CONTRAS
|
|
Es
iterativo
Se compone
de muchos artefactos
El proceso
es modificable
|
Pesado en
la parte de procesos
El cliente
no esta tan involucrado como en otras arquitecturas (XP)
Ligado a un
set de herramientas costoso (Rational)
Lento para
cierto tipo de proyectos
|
PRACTICAS DE RUP
-
Proceso de desarrollo iterativo
-
Organizará los requerimientos
-
El sistema se divide en partes que serán de fácil
manejo
-
El modelado del software será simple y permitirá
que todo el equipo lo entienda
-
El software es probado y verificado para asegurar
su calidad
-
Cualquier cambio en los requerimientos podrá ser
realizado y rastreado.
Parece
haber una percepción de que RUP no es compatible con proyectos pequeños, pero
las metodologías agiles se pueden usar combinadas con RUP, la fortaleza de las
metodologías agiles es vista en la fase de construcción de un nuevo sistema o
programa, pero todavía hay una necesidad de administrar los eventos
relacionados a las otras tres fases, como determinar lo que necesita ser
realizado (Requerimientos) y como el ambiente operacional lo afectara.
RUP no fuerza, por el usa de todas las disciplinas a lo largo de las
cuatro fases de incepcion, elaboración, construcción y transición, lo que
sucede es que la reiteración más bien provee un marco de trabajo óptimo para
estas actividades.
Esto demuestra que su rango de uso abarca desde proyectos pequeños pero
que pueden ser fundamentales para una organización, hasta proyectos titánicos
que requieran más horas de dedicación, ya que proporciona la solvencia para
abarcar un proyecto con la mejor calidad asi de esta forma no caer en errores
que elevaran los costos y el tiempo de desarrollo. Adicionalmente estos se guiaran
por los mismos lineamientos, haciendo que el software y su desarrollo sea un
proceso sensible o entendible para todos los actores involucrados y que pueda
ir creciendo de la mano de la retroalimentación (por sus iteraciones) que se
genere para evitar duplicidad, errores, desgaste o malos entendidos en su
estructura y elaboración.
Como en cualquier disciplina que esté relacionada con la tecnología, la
carrera de ingeniería de sistemas enfrenta el reto de la actualización. Los
métodos, los procesos y, en general, las ciencias de la computación están en
constante cambio; en ejemplo la metodología o los contenidos académicos del
2015 no puede ser comparado con el plan de estudios de 2016. Esta es una
tendencia en la que poco podemos hacer, es la naturaleza misma de este negocio:
el estar en constante cambio. Tratar de enseñar y casarse con una metodología
en específico resultaría desastroso, seriamos especialistas de nada, con el
riesgo de que esas prácticas queden desfasadas y obsoletas.
La metodología RUP está en la elite en cuanto a las buenas prácticas
para el desarrollo de software. Esta
disciplina exige en sus practicantes un esfuerzo y una vocación por hacer las
cosas con calidad. El RUP ha tenido tal
éxito en la industria de la computación que desde nuestro punto de vista
necesita estar incluida en los conocimientos básicos de cualquier ingeniero de
sistemas.
El RUP no es un sistema con pasos firmemente establecidos, sino un
conjunto de metodologías adaptables al contexto, requerimientos y necesidades
del cliente. Esto ayuda a que los desarrolladores, fortalezcan sus habilidades
a la vez que estas serán más versátiles al cambio y a los nuevos requerimientos
del mercado. La forma en la que debería implantarse este conocimiento desde las
aulas de clase para que los futuros profesionales migren a optimizar la calidad
de sus tareas es con las buenas prácticas que conllevan a la metodología.
El modelado del negocio es el inicio del proyecto, nos ayuda a entender
el giro de la empresa o el problema a estudiar, leva a deducir cual es la mejor
metodología que necesitamos para dar en marcha el desarrollo ajustado a las
necesidades del cliente.
La evaluación de requerimientos establece el alcance del proyecto, ayuda
a estimar tiempo, costos y consigue una adecuada interacción entre todos los
interesados, en fin de la realización del proyecto de forma adecuada a los
retos que asume la empresa en su implementación del software solicitado.
Análisis y Diseño constituyen la transformación de los requerimientos, en las
opciones de desarrollo, así se encontrara la opción optima a soluciones
implementadas a través de desarrollo. La implementación es la ejecución de las
actividades que se analizaron, administraron y aprobaron en el diseño a
implementar de forma que para llegar a este punto se fijó el objetivo y la
metodología más eficaz para la producción del producto
Luego de desarrollar llega la distribución que es el punto donde se
falla muchas veces, haciendo el producto inestable para su usabilidad carece de
administración técnica para la configuración y mantenimiento de cambios, se
debe tener muy claro el proceso para la alineación de los cambios que son
consecuentes a los mejores indicadores de producción, para ello se requiere de
una buena administración de proyectos, marco de trabajo para administración de riesgos;
Manejo de hitos, y métricas para medir el avance o retraso. En el análisis y
evaluación de proyectos se debe aprender a conocer el ambiente, ya que este es
responsable de la estabilidad de la configuración del proyecto, proyecta e
involucra las herramientas y procesos adecuados para el funcionamiento del
desarrollo conseguido.
Hay que resaltar que esta metodología, según el análisis que realizamos,
es aplicable a muchas materias de la carrera, e incluso, a otras carreras que
se ofertan en el mercado. Esta es una metodología que es tan flexible que puede
solucionar problemas y estandarizar procesos que no sean exclusivos del
desarrollo de software.
Una forma de abordar estos contenidos y fomentar la competencia de la
transversalidad es mediante la elaboración de proyectos interdisciplinarios.
Aprovechando que en la materia de desarrollo de emprendedores convergen profesionales
de diferentes experticias, así se puede convocar a la realización de un
proyecto que sea modelado mediante el RUP. Obviamente este tema debe ser
introducido a cada uno de los miembros de equipo de desarrollo de software para
que al momento de llevarlo a la práctica o producción, ya se tengan claros los
procedimientos y cuando menos conocimientos previos.
En conclusión los aportes que involucra una metodología de desarrollo
como RUP, son acertadas iniciando con el modelo o propósito de Innovación que cada negocio en determinado
mercado debe fijar para el éxito, el modelamiento de negocios de la metodología
RUP ha permitido que las empresas puedan adquirir toda la
información necesaria para un análisis del negocio actual y por
ende, hallar errores, trabajar con resultados, implementación de estrategias,
evolución, factibilidad del negocio y llegar a identificar qué áreas se pueden
mejorar o potencializar en corto o a largo plazo. Consecuente encontramos a la
tecnología, el modelado del negocio a través del proceso de ingeniería de
software, permite a través del tiempo asegurar una buena producción de software
de alta calidad, versatilidad y regulación, así este debe satisfacer la
necesidad de un usuario final o solicitante dentro de un tiempo, presupuesto, y
demás recursos requeridos de una forma establecida, previsible o predecible. El
impacto social al obtener un buen resultado que permitirá detectar y analizar
las estructuras funcionales y las áreas encargadas de la automatización para
poder mejorar los procesos, determinar todo tipo de oportunidades obteniendo
una solución de calidad en cada servicio ofrecido a el grupo solicitante, es
decir llegar a un nivel absoluto de solución en nuestro para la sociedad que
satisfaga por completo los requerimientos iniciales.
Cualquier negocio puede ser exitoso con las medidas adecuadas ya que todo
dependerá de muchas variables, para
esto es necesario conocer los elementos claves en el modelo del negocio
e implementación de metodología de desarrollo eficiente y evolutivo, que en
conjunción deberán ser aplicados de forma adecuada a cada tipo de negocio según
el mercado en que este se rija. Reitéranos la importancia que requiere realizar
un estudio del negocio con la mayor minuciosidad, ya que es de vital
importancia para identificar las necesidades, expectativas, soluciones y
requerimientos que desean fortalecer los clientes ya que se encuentran en
determinado nicho de mercado. El modelado de negocio es muy importante porque
nos permite ver que partes se verán afectadas o dicho de otro modo,
involucradas en constante usabilidad y comunican con los procesos a los que da
acceso el desarrollo, por lo que se pretende de esta forma, ubicar un mejor
control de la información para que esta sea clara, completa y eficiente desde
el punto de vista de lo verdaderamente requerido.
Rational Unified Process (RUP) ofrece las actividades para modelar el
negocio y Unified Modeling Language (UML) ofrece los símbolos necesarios para
modelar el negocio.
Las herramientas que proporciona un lenguaje
gráfico para visualizar, especificar, construir y documentar un sistema tales
como las que ofrece UML, para realizar un estándar y así describir un
"plano" del sistema (modelo), incluyendo aspectos conceptuales tales
como son los procesos de negocio, funciones propias del sistema, y aspectos
estables por ende concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un
"lenguaje de modelado" para especificar o para describir métodos o
procesos. Se utiliza para definir un sistema lo que requiere detallar los
artefactos en el sistema, para documentar cada uno de los cambios y finalmente
construir una solución satisfactoria. En otras palabras, es el lenguaje en el
que está descrito el modelo.
Se puede aplicar en el desarrollo de software
gran variedad de formas para dar soporte a una metodología de desarrollo de
software (tal como el Proceso Unificado Racional o RUP), pero no especifica en
sí mismo qué metodología o proceso usar. UML no puede compararse con la
programación estructurada, pues UML significa Lenguaje Unificado de Modelado,
no es programación, solo se diagrama la realidad de una utilización en un
requerimiento. Mientras que, programación estructurada, es una forma de
programar como lo es la orientación a objetos, la programación orientada a
objetos viene siendo un complemento perfecto de UML, pero no por eso se toma
UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los
cuales muestran diferentes aspectos de las entidades representadas.
Los casos de uso describen lo que
debe hacer el sistema en términos del usuario final, su representación es
simple y permite una comunicaron directa entre el usuario de la aplicación y el
analista de la misma. Se pueden elaborar diagramas de contexto que muestran de
forma general los requerimientos funcionales de la aplicación y luego
representar cada requerimiento de forma detallada en otro diagrama de caso de
uso. Los elementos que se utilizan son. Casos de uso representados por una
elipse, relaciones, actores. Los actores son las personas y/o elementos físicos
externos que consumen la aplicación. Las relaciones existentes entre cada de
uso son de asociación, herencia y dependencia.
Si bien no es necesario realizar
todos los diagramas especificados por el UML en la implementación del modelo
RUP para la construcción de una aplicación,
es importante tener diagramas de alto nivel que representen el dominio
del problema y por cada etapa de la metodología los necesarios para comprender
los diferentes procesos que enmarcan la solución. Los diagramas durante el
proceso de construcción de la aplicación pueden variar ya que por lo general el
problema se subdivide en pequeños problemas, convirtiéndose en desarrollos
incrementales e iterativos, permitiendo el refinamiento de los mismos.
POR:
Deysan
Lavarcé 066091058
Oscar
Rodriguez 066092083
No hay comentarios:
Publicar un comentario