El Proceso Unificado Racional en las Pruebas de Software
La metodología del Proceso Unificado Racional (RUP) utiliza el enfoque orientado a objetos en su diseño y el uso de la notación UML (Lenguaje de Modelado Unificado) está diseñado y documentado para ilustrar los procesos en acción. Utiliza técnicas y prácticas comercialmente probadas.
Es un proceso considerado pesado y preferentemente aplicable a grandes equipos de desarrollo y grandes proyectos, pero el hecho de que sea ampliamente personalizable permite adaptarlo a proyectos de cualquier escala.
Específicos
Para la gestión de proyectos, el modelo RUP (Proceso Unificado Racional) proporciona una solución disciplinada, como las tareas y responsabilidades que se perfilan dentro de una organización de desarrollo de software.
RUP (Proceso Unificado Racional) es, en sí mismo, un producto de software. Es modular y automatizado, y toda su metodología se apoya en varias herramientas de desarrollo integradas y vendidas por IBM a través de sus «Rational Suites».
Los métodos de la competencia en el campo de la ingeniería del software incluyen «salas limpias» (consideradas pesadas) y ágiles (ligeras) como Extreme Programming (XP-Programación Extrema), Scrum, FDD, y otros.
Hay ciertas directrices y plantillas que se definen, para los miembros del personal de un ciclo de producción, por RUP: parte del cliente y una evaluación del progreso del proyecto por su gestión. Ayuda a los desarrolladores a mantenerse centrados en el proyecto.
Requisitos de gestión
La documentación adecuada es esencial para cualquier proyecto a gran escala; tenga en cuenta que RUP describe cómo documentar la funcionalidad, las limitaciones del sistema, las restricciones de diseño y los requisitos de negocio.
Los casos de uso y los escenarios son ejemplos de artefactos de procesos dependientes, que se han considerado mucho más eficaces para capturar los requisitos funcionales.
El uso de una arquitectura basada en componentes
La arquitectura basada en componentes crea un sistema que puede ser fácilmente extensible, promoviendo la reutilización y el software una comprensión intuitiva. Un componente suele referirse a un objeto en la programación orientada a objetos.
El RUP proporciona una forma sistemática de construir este tipo de sistemas, centrándose en la producción de una arquitectura ejecutable en las primeras etapas del proyecto, es decir, antes de comprometer recursos a gran escala.
Los componentes a los que se hace referencia aquí suelen estar incluidos en las infraestructuras ya existentes en el lugar. Estas infraestructuras incluyen CORBA así como el Modelo de Objetos de Componentes (COM).
El uso de modelos visuales de software en el modelo RUP
Al abstraer la programación de su código y representarlo utilizando bloques de construcción gráficos, RUP puede ser una forma efectiva de obtener una visión general de una solución.
El uso de modelos visuales también puede permitir a las personas con un perfil menos técnico (como los clientes) tener una mejor comprensión de un determinado problema, y por lo tanto estar más involucrados en el proyecto en su conjunto.
El lenguaje de modelado UML se ha convertido en un estándar de la industria para la representación de proyectos, y es ampliamente utilizado por RUP!
Saber más: Lea sobre detalles exclusivos de Agile Testing
Comprobar la calidad del software
No asegura la calidad del software es el fallo más común en todos los proyectos de sistemas informáticos. Por lo general, se piensa en la calidad del software después de la finalización de los proyectos o la calidad es la responsabilidad de un equipo de desarrollo de equipo diferente.
Gestión y Control de Cambio de Software
En todos los proyectos de software, la existencia de cambio es inevitable. RUP define métodos para controlar y supervisar los cambios. Como un pequeño cambio puede afectar a las aplicaciones de forma totalmente impredecible, el control de cambios es esencial para el éxito de un proyecto.
RUP (Rational Unified Process)también define las áreas de trabajo y seguridad, lo que garantiza a un programador que los cambios en otro sistema no afectarán a su sistema.
Fases de la Metodología RUP
Hasta aquí estas directrices son generales, a las que hay que atenerse para recorrer la vida de un ciclo de proyecto. Las fases (véase la figura siguiente) indican el énfasis dado en el proyecto en un momento dado. Para capturar la dimensión temporal de un proyecto, RUP divide el proyecto en cuatro fases diferentes:
Inicio o Diseño: énfasis en el alcance del sistema;
Preparación: énfasis en la arquitectura;
Construcción: énfasis en el desarrollo;
Transición: énfasis en la aplicación.
El RUP también se basa en las 4 Ps:
- Personas
- Diseño
- Producto
- Proceso
Las capas se componen de iteraciones. Las iteraciones son ventanas de tiempo; las iteraciones han definido el término como las fases son objetivo.
Todas las fases generan artefactos. Estos serán utilizados en la siguiente fase y documentan el proyecto y permite un mejor seguimiento.
Fase de diseño
La fase de diseño o iniciación contiene los flujos de trabajo necesarios para el acuerdo de las partes interesadas – actores – con los objetivos, la arquitectura y la planificación del proyecto. Si estos actores tienen un buen conocimiento, no será necesario analizar. En caso contrario, se requiere un análisis más elaborado.
En esta etapa, los requisitos esenciales del sistema se transforman en casos de uso. El objetivo no es cerrarlos del todo, sino sólo aquellos que son necesarios para dar forma al dictamen.
La etapa suele ser corta y sirve para definir si es factible continuar con el proyecto y definir los riesgos y el coste del último. Se puede hacer un prototipo para que el cliente lo apruebe. Como cita el RUP, lo ideal es realizar iteraciones, las cuales deben estar bien definidas en cuanto a su cantidad y objetivos.
Fase de elaboración
La preparación será para el diseño del sistema, como complemento al levantamiento y/o documentación de casos de uso, frente a la arquitectura del sistema, para revisar el modelo de negocio para el proyecto y para iniciar la versión del manual de usuario. Hay que aceptar: ¿La descripción del producto (aumento + integración) es estable; el plan del proyecto es fiable? ¿Los costes son elegibles?
Fase de construcción
En la fase de construcción se inicia el desarrollo físico del software, códigos de producción, pruebas alfa. Las pruebas beta se llevaron a cabo al comienzo de la fase de transición.
Debe aceptar las pruebas, los procesos estables y de prueba, y el código del sistema es «línea de base».
Fase de Transición
En esta fase es la entrega («despliegue») de software, que lleva a cabo el plan de despliegue y entrega, el seguimiento y la calidad del software. Los productos (lanzamientos, versiones) van a ser entregados, y colocar la satisfacción del cliente. Esta etapa también tiene lugar la formación de los usuarios.
Disciplinas de la Metodología RUP (Rational Unified Process)
La Disciplina de Modelado de Negocio
Las organizaciones son cada vez más dependientes de los sistemas de TI, por lo que es imprescindible que los ingenieros de sistemas de información sepan cómo se integran las aplicaciones en el desarrollo de la organización. Las empresas invierten en TI, que entienden la ventaja competitiva del valor añadido por la tecnología.
El objetivo del modelado de negocio es, en primer lugar, establecer un mejor entendimiento y comunicación entre la ingeniería de negocio y la ingeniería de software.
Entender el negocio significa que los ingenieros de software deben comprender la estructura y la dinámica de la empresa objetivo (el cliente), los problemas actuales a los que se enfrenta la organización y los posibles métodos y estrategias para enmendarlos.
Otro aspecto importante que no debe ser socavado es que las partes relevantes como los desarrolladores, así como los clientes y también los usuarios finales deben tener una comprensión clara sobre la organización, y una característica importante de esta comprensión es que debe ser común entre todas las partes involucradas.
El modelado del negocio explica cómo describir la visión de una organización en la que se implementará el sistema y cómo utilizar esta visión como base para describir los procesos, funciones y responsabilidades.
Requisitos del curso
Este curso explica cómo obtener las peticiones de las partes interesadas («interested parties») y convertirlas en un conjunto de requisitos para que los productos funcionen dentro del sistema que se va a construir y proporcionar los requisitos detallados de lo que es necesario para el sistema.
Análisis y diseño de la disciplina («Design»)
El propósito del análisis y diseño es mostrar cómo se llevará a cabo el sistema. El objetivo es construir un sistema que:
Ejecute en un entorno de ejecución específico, las tareas y funciones especificadas en las descripciones de los casos de uso
Satisfaga todas sus necesidades
Es fácil de mantener cuando no hay cambios en los requisitos funcionales, los resultados del proyecto en un modelo de análisis y diseño opcionalmente tiene un modelo de análisis.
El modelo de diseño se utiliza como una versión conceptual del código fuente, mostrando sólo lo mínimo. Esto permite al usuario de cualquier inspección averiguar el estilo en el que se ha renderizado el código fuente.
El modelo de diseño se renderiza de tal manera que contiene diferentes divisiones de diseños. Estas divisiones se almacenan dentro de subsistemas definidos.
Cada subsistema tiene una interfaz distinta que está diseñada con precisión. También contiene descripciones de cómo los objetos de estas clases colaboran para llevar a cabo el diseño de casos de uso.
La Disciplina Implementación
Los efectos de la aplicación son:
- Con referencia a los subsistemas en capas organizados para una aplicación, se configura el código de organización.
- Se llevan a cabo las diferentes clases o divisiones de componentes. Estos componentes incluyen
- Ficheros fuente
- Ejecutables y
- Binarios
- Los componentes desarrollados como unidades se prueban
Incorporan los resultados producidos por los ejecutores individuales (o equipos), en un sistema ejecutable. Los sistemas se logran a través de los componentes de la aplicación.
El proceso tiene como objetivo realizar una función importante, que es definir el procedimiento exacto que se utilizará, con el fin de reutilizar los componentes que son; ya existentes o han sido introducidos recientemente.
Esto permite una posibilidad de mantenimiento del sistema de molestia y una mejora sustancial en las posibilidades de la utilización de los componentes.
Pruebas de disciplina
Los propósitos de las pruebas de disciplina son:
- Comprobar la interacción entre los objetos
- Comprobar la correcta integración de todos los componentes del software
- Comprobar que todos los requisitos se han ejecutado correctamente
- Identificar y asegurar que los defectos se abordan antes de la implementación del software
- Asegurarse de que todos los defectos son revisados y cerrados
Conclusión
En caso de que haya defectos en el proyecto, su corrección puede suponer costes innecesarios debido a que los defectos no salgan a la luz a su debido tiempo.
Sin embargo, si el proyecto se pone a prueba en su totalidad, esto sería beneficioso, ya que cualquier defecto que pudiera estar introduciéndose en los proyectos puede ser identificado y averiguado lo antes posible.
Esto, a su vez, tendrá una reducción masiva en los costos involucrados con la rectificación de los defectos. Este es el enfoque iterativo propuesto por el Proceso Racional Unificado.
Para que la prueba dé sus frutos y tenga los mejores resultados posibles, es necesario que las pruebas se realicen sobre cuatro parámetros de calidad y también deben establecerse normas que deben cumplirse para que se considere que el proyecto ha superado la prueba.