¿que es una Metodología de desarrollo de Software?
La metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información(1).
¿Qué nos aporta una metodología de desarrollo de software? (2)
La
gracia
de una metodología es que aporta una garantía de calidad.
¡IMPORTANTE!
—Un
producto de software es de calidad si cumple rigurosamente con todos y cada uno
de sus
—requisitos.
Es decir, calidad = requisitos satisfechos.
—La
gracia
de una metodología es que aporta una garantía de calidad.
¡IMPORTANTE!
—Un
producto de software es de calidad si cumple rigurosamente con todos y cada uno
de sus requisitos.
Es decir, calidad = requisitos satisfechos.
¿Qué
metodología escoger?
—Existen
dos tipos principales de metodologías, las Ligeras y las Pesadas.
—Las primeras
son
metodologías extremadamente
prácticas que generalmente obvian
gran parte de la documentación y
están mas
preparadas para utilizarse en proyectos cuyos requisitos cambiarán constantemente
durante
todo
el proceso.
—Las segundas, son metodologías donde todo está
mucho más controlado y se genera mucha
documentación antes
de proceder a implementar el proyecto, con mucho mayor peso del análisis y
el diseño sobre el proyecto.
Ejemplos
de Metodologías
Metodologías
ligeras podrían
ser:
— eXtreme Programming (XP)
— SCRUM
—Crystal
—
Metodologías
pesadas podrían
ser:
— Rational Unified Process (RUP),
—ICONIX
—Métrica 3.
Proceso Unificado de Desarrollo (RUP) (metodología pesada)
RUP es un proceso para el desarrollo de un proyecto de software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. La versión de RUP que se ha estandarizado vio la luz en 1998 y se conoció en sus inicios como Proceso Unificado de Rational 5.0.
No son Metodologías de Desarrollo de Software: (3)
La "Programación estructurada" o la "Programación Orientada a Objetos" son paradigmas o modelos de programación. Indican pautas de comportamiento en los sistemas de programación. No tienen que ver con el ciclo de vida del software ni la manera en la que debe realizarse cada tarea para un proyecto concreto, así pues NO SON METODOLOGÍAS. Los términos "Ciclo de vida en espiral", "Incremental", en "Cascada", con "prototipo", etc., indican esquemas generales de organización en las tareas del ciclo de vida, unas con respecto a otras y con respecto a otros aspectos como el tiempo, los requisitos o el riesgo. Actualmente se denominan "PATRONES" del ciclo de vida del software, aunque antaño fueron denominados simplemente distintos "Ciclos de vida". Indican ideas estructurales sencillas en el proceso de desarrollo, y no la manera en la que debe realizarse cada tarea del ciclo para un proyecto concreto, así pues, NO SON METODOLOGÍAS. El lenguaje UML (Unified Modeling Languaje) es un gran logro de la ingeniería. Aún con sus carencias, es algo muy importante: un lenguaje común para que todos los profesionales del desarrollo de sistemas -de software o no expresen sus ideas, pero UML no le indica a nadie la manera de realizar las tareas en un proyecto concreto: tan solo es una herramienta para expresar ideas, así pues NO ES UNA METODOLOGÍA. Sin embargo, algunas metodologías de las que hemos comentado, como RUP o METRICA hacen referencia a UML como lenguaje de modelado para expresar ideas.
.- Estructura o elementos específicos de la metodología (3)
Fases de desarrollo del software
· Inicio
· Elaboración
· Construcción
· Transición
1.- Fase de inicio
Se hace un plan de fases, donde se identifican los principales casos de uso y se identifican los riesgos. Se concreta la idea, la visión del producto, como se enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es determinar la visión del proyecto.
1.1.- Modelado del negocio
En esta fase el equipo se familiarizará más al funcionamiento de la empresa. Entender la estructura y la dinámica de la organización. · Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
1.2.- Requisitos
En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.
· Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer.
· Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
· Definir el ámbito del sistema.
· Proveer una base para estimar costos y tiempo de desarrollo del sistema.
· Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
2.- Fase de elaboración
Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos. Planificar las actividades necesarias y los recursos requeridos, especificando las características y el diseño de la arquitectura. En esta etapa el objetivo es determinar la arquitectura Óptima.
2.1.- Análisis y Diseño
En esta actividad se especifican los requerimientos y se describen sobre cómo se van a implementar en el sistema.
· Transformar los requisitos al diseño del sistema.
· Desarrollar una arquitectura para el sistema.
· Adaptar el diseño para que sea consistente con el entorno de implementación.
3.- Fase de construcción
Se basa en la elaboración de un producto totalmente operativo. En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.
3.1- Implementación
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable.
· Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados, formando el Plan de Integración.
· Cada implementador decide en qué orden implementa los elementos del subsistema.
· Si encuentra errores de diseño, los notifica.
· Se integra el sistema siguiendo el plan.
3.2.- Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
4.- Etapa de transición
El objetivo es llegar a obtener el release del proyecto. Se realiza la instalación del producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios.
4.1.- Implantación
Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:
5.- Ciclo de Vida de desarrollo de software utilizado
· Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software.
Definición de Scrum (metodología liviana) (4)
Scrum es
un proceso
ágil y liviano que sirve para administrar y controlar el desarrollo de software, de
manera iterativa e incremental. Cada iteración termina con una pieza de
software ejecutable que incorpora nueva funcionalidad.
Las
metodologías ágiles se centran en aspectos como la flexibilidad en
la introducción de cambios y nuevos requisitos durante el proyecto, el factor
humano,
el producto
final,
la colaboración
con el cliente y el desarrollo incremental
como formas de asegurar los buenos resultados, en proyectos con requisitos muy
cambiantes o cuando se exige, como es habitual, reducir los tiempos de
desarrollo manteniendo una alta calidad. En la siguiente figura se muestra la dinámica de Scrum
Fases de la metodología Scrum
El desarrollo de producto tiene un ciclo de vida en la metodología Scrum. Estas son fases en las que se divide un proceso Scrum:(5)
- ¿Qué y quién? El producto que queremos conseguir una vez terminemos el Sprint, y los roles de equipo con sus tareas asignadas.
- ¿Dónde y cuándo? El plazo y el contenido del Sprint.
- ¿Por qué y cómo? Las distintas herramientas para aplicar esta metodología ágil.
Cada Sprint puede tener una serie de eventos o etapas. Los más comunes son:
- Reunión para la planificación del Sprint. En ella, se divide el tiempo de duración del Sprint, así como el objetivo y entregable del mismo. Además, el equipo de desarrollo deberá saber cómo realizarlo. Muy parecido a lo que llamamos reunión de Kick off y que puedes descubrir en este curso gratis y online de gestión de proyectos.
- Scrum diario. Se basa en poner en común y sincronizar actividades para elaborar el plan del día.
- Trabajo de desarrollo durante el Sprint. Nos aseguramos que los objetivos se están cumpliendo, que no se producen cambios que alteran el objetivo del Sprint y se mantiene un feedback constante con el cliente o dueño del proyecto.
- Revisión del Sprint. Reunión con el cliente o dueño del proyecto, en la que se estudia y revisa el Product Backlog del Sprint. Se definen los aspectos a cambiar, en caso necesario, de mayor valor o probables para planificarlo en el siguiente Sprint.
- Retrospectiva del proyecto. Oportunidad del equipo de desarrollo para mejorar su proceso de trabajo y aplicar los cambios en los siguientes Sprints.
La idea de este documento es que los alumnos comparen dos tecnologías una pesada (RUP) y una liviana (Scrum) , que vean ventajas y desventajas de cada una y en qué caso es mas adecuado usar cada una.
Fuentes:
(1)SELECTING A DEVELOPMENT APPROACH. Revalidated: March 27, 2008. Consultado el 27 de octubre de 2008.
(2)Jacobson, Ivar, Booch, Grady y Rumbaugh, James. El Proceso Unificado de Desarrollo de Software. España
(3)Tekhne Revista de la facultad de ingeniería de la universidad Católica Andrés Bello Caracas, Venezuela N°10 año 2007
(4) proyectosagiles.org
(5)https://www.sinnaps.com/blog-gestion-proyectos/metodologia-scrum
