4 1 personalizacion de metodologias

Metodologías de Ingeniería del software
Personalización de metodologías
METODOLOGIAS DE DESARROLLO DE SOFTWARE
Todos nos hemos hecho esta pregunta al desarrollar un
software, ¿Qué metodología debo usar para desarrollar
un sistema?.
Esto es muy importante ya que como arquitectos de
software, debemos tener un plano en donde apoyarnos.
Por muchos años han existido cientos de propuestas
para buscar una solución y sobre todo asegurar la
calidad del software.
El software debe ser pensado, diseñado y desarrollado
como un producto sujeto a normas de calidad.

El software es un producto desarrollado por grupos de personas cuya interacción
debe ser gestionada.

El énfasis en el proceso de desarrollo asegura un producto adecuado a los
requisitos de los clientes.
Muchas veces realizamos el diseño de
nuestro software de manera rígida, con los
requerimientos que el cliente nos solicitó de
tal manera que el cliente en la etapa final o
de pruebas solicita un cambio se nos hace
muy difícil realizarlo.

El desarrollo de software no es sin dudas una tarea fácil. Como resultado a este
problema ha surgido una alternativa desde hace mucho: la Metodología.

Las metodologías imponen un proceso disciplinado sobre el desarrollo de
software con el fin de hacerlo más predecible y eficiente.
Lo hacen desarrollando un proceso detallado
con un fuerte énfasis en la planificación
inspirado por otras disciplinas de la
ingeniería.
Surgen ante la necesidad de utilizar
procedimientos, técnicas, herramientas y
soporte documental a la hora de desarrollar
un producto software

 Las metodologías orientadas al control de los procesos, estableciendo
rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones
que se usarán. Estas metodologías son llamadas Metodologías Pesadas.
 Las metodologías orientadas a la interacción con el cliente y el desarrollo
incremental del software, mostrando versiones parcialmente funcionales del
software al cliente en intervalos cortos de tiempo, para que pueda evaluar y
sugerir cambios en el producto según se va desarrollando. Estas son llamadas
Metodologías ligeras/ágiles.

Metodología RUP
El Proceso Unificado Racional (Rational Unified Process- RUP), es un proceso de
desarrollo de software y junto con el Lenguaje Unificado de Modelado UML,
constituye la metodología estándar más utilizada para el análisis, implementación
y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un
conjunto de metodologías adaptables al contexto y necesidades de cada
organización, donde el software es organizado como una colección de unidades
atómicas llamados objetos, constituidos por datos y funciones, que interactúan
entre sí.
RUP es un proceso para el desarrollo de un proyecto
de un software que define claramente quien, cómo,
cuándo y qué debe hacerse en el proyecto

RUP – como proceso de desarrollo
• RUP es explícito en la definición de software y su trazabilidad, es decir,
contempla en relación causal de los programas creados desde los requerimientos
hasta la implementación y pruebas.
• RUP identifica claramente a los profesionales (actores) involucrados en el
desarrollo del software y sus responsabilidades en cada una de las actividades.

RUP – Elementos básicos
El proceso de desarrollo se representa usando un conjunto de elementos de
modelado: roles (el quién), actividades (el cómo), artefactos (el qué) y flujos de
trabajo (el cuándo).
 Rol expresa quién (individuo o grupo)
hace un trabajo
 Actividad describe cómo es hecho el
trabajo
 Artefacto
realizado

captura

el

trabajo

Roles: Un rol es una definición abstracta del conjunto de responsabilidades, para las
actividades a ser desempeñadas y artefactos a ser producidos dentro del proyecto
por un individuo o grupo.
 Analistas: captura de requerimientos -investigan (analista procesos negocios)
 Desarrolladores: diseño, implementación (arquitecto de software, el diseñador)
 Gerentes:
dirección
de
procesos
de
ingeniería.(Gte de proyecto, Gte de
publicación -deployment).
 Producción y Soporte: soporte al proceso de
desarrollo del software (escritor técnico,
especialista herramientas, administrador de
sistema, etc.)
 Probadores: dirigen las pruebas (probador,
analista de pruebas, etc.)

Actividades: Una actividad es una unidad de trabajo que se asigna a un rol, la cual
se requiere sea ejecutada por el individuo asociado a ese rol.
Las actividades están fraccionadas en pasos y estos agrupados en tres categorías:
Pasos de Análisis: cuando el individuo que
desempeña el rol comprende la naturaleza de
la tarea, recolectando y examinando los
artefactos de entrada y formulando resultados
o solución.
Pasos de Ejecución: El rol crea o actualiza
algún artefacto.
Pasos de Revisión: Donde el rol verifica los
resultados contra algún criterio.

Artefactos:
Un artefacto es una pieza de información que es producida o utilizada por
procesos. Los artefactos son los elementos tangibles de un proyecto, elementos
que el proyecto produce o usa mientras se trabaja en busca del producto final.

Flujos de trabajo:
Un flujo de trabajo es una secuencia de actividades que producen un resultado de
valor observable. Una de las grandes dificultades de describir un proceso de
software, es que hay muchas formas de organizar el conjunto de actividades
dentro de un flujo de trabajo.

RUP – fases de desarrollo de software
Inicio
Elaboración
Construcción
Transición

RUP – fases de desarrollo de software

RUP – 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.
Modelado del negocio
En esta fase el equipo se familiarizará más al funcionamiento de la empresa,
sobre conocer sus procesos.
 Entender la estructura y la dinámica de la organización para la cual el sistema
va ser desarrollado.
 Entender el problema actual en la organización objetivo e identificar
potenciales mejoras.
 Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento común de la organización objetivo.

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.

RUP – 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.
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.

RUP – Fase de elaboración

RUP - Fase de construcción
Se basa en la elaboración de un producto totalmente operativo y en la elaboración
del manual de usuario. Construir el producto, la arquitectura y los planes, hasta
que el producto está listo para ser enviado a la comunidad de usuarios.
En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.
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.
Se decide en qué orden implementa los elementos del subsistema.
Si encuentra errores de diseño, los notifica.
Se integra el sistema siguiendo el plan.

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.
 Encontrar y documentar defectos en la calidad del software.

 Generalmente asesora sobre la calidad del software percibida.
 Provee la validación de los supuestos realizados en el diseño y especificación de
requisitos por medio de demostraciones concretas.
 Verificar las funciones del producto de software según lo diseñado.

 Verificar que los requisitos tengan su apropiada implementación.

RUP - Fase 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.
Despliegue
Esta actividad tiene como objetivo producir con éxito distribuciones del producto
y distribuirlo a los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecución final.
Empaquetar el software para su distribución. Distribuir e instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.

RUP - Fase de transición

RUP – Principios clave
Adaptación del proceso: El proceso deberá adaptarse a las características
propias de la organización.
Balancear prioridades: Los requerimientos de los diversos inversores pueden
ser diferentes. Debe encontrarse un balance que satisfaga los deseos de todos.
Colaboración entre equipos: El desarrollo de software no hace una única
persona sino múltiples equipos.
Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de
modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los
inversores, la estabilidad y calidad del producto.
Elevar el nivel de abstracción: Este principio dominante motiva el uso de
conceptos reutilizables tales como patrón del software.

Enfocarse en la calidad: El control de calidad no debe realizarse al final de
cada iteración, sino en todos los aspectos de la producción.

RUP – características esenciales

RUP – características esenciales
Proceso Dirigido por los Casos de Uso:
La utilización de los Casos de Uso para el desenvolvimiento y desarrollo de las
disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son
la base para la implementación de las fases y disciplinas del RUP.
Proceso Iterativo e Incremental: Este modelo plantea la implementación del
proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por
cumplir en cada iteración y así poder ir completando todo el proyecto iteración
por iteración.
Proceso Centrado en la Arquitectura:
Define la Arquitectura de un sistema, y una arquitectura ejecutable construida
como un prototipo evolutivo. Una arquitectura ejecutable es una implementación
parcial del sistema, construida para demostrar algunas funciones y propiedades.

RUP – Quiénes deben usar RUP?
RUP es la metodología indicada para el desarrollo y publicación de proyectos de
software críticos dentro de una organización. Esta metodología fue desarrollada
pensando en dos grupos de usuarios:
• Desarrolladores de software, que trabajan como parte de un equipo de
desarrollo de software.
• Personas que practican la ingeniería de procesos, específicamente gerentes e
ingenieros de procesos de software.
Los desarrolladores de software pueden encontrar en RUP una guía, sobre qué es
lo requerido de su rol (o de ellos como desarrolladores) en la definición de roles.

Esta guía también proporciona el cómo, cada uno de estos roles colaboran entre
si, en términos del trabajo detallado que es requerido para establecer el flujo de
trabajo dentro de una iteración.

RUP – Cuándo usar RUP?
RUP puede ser utilizado desde el principio de un proyecto de software y puede
continuar usándose en los subsecuentes ciclos de desarrollo del software después
que la fase inicial ha finalizado.
Sin embargo, la manera en la cual se use RUP, necesita ser trasformada para
ajustarse a las necesidades. Existen algunas consideraciones que modifican el
cuándo y cómo se utilizarán las diferentes partes de RUP, éstas son:

 El ciclo de vida del proyecto (número de iteración, longitud de cada fase, el
largo del proyecto).
 Los objetivos de negocio del proyecto, visión, alcance y riesgos.
 El tamaño del esfuerzo para el desarrollo del software.

Microsoft Solutions Framework (MSF)
MSF es una guía de desarrollo de software flexible que permite aplicar de manera
individual e independiente cada unos de sus componentes, es escalable pues está
diseñada para poder expandirse según la magnitud del proyecto.
MSF está basada en un conjunto de principios, modelos, disciplinas, conceptos,
directrices y practicas aprobadas por Microsoft, que asegura resultados con menor
riesgo y de mayor calidad, centrándose en el proceso y las personas.

MSF se introdujo por primera vez en 1994 como un conjunto de las mejores
prácticas en los desarrollo de Software de Microsoft y Microsoft Consulting Service.

Éste Framework está basado en los modelos espiral y cascada, lo cual indica que
toma elementos de los métodos tradicionales que aún son referentes importantes
para procesos de software.
Es adaptable, flexible y escalable, e independiente de tecnologías, lo cual
significa que no se cierra a un sólo modelo de programación sino más bien queda
abierto según la naturaleza del proyecto.

Usa como referente el DSL (Domain-Specific Language) para realizar el modelado,
así como RUP se apoya en UML para hacer el modelado (Microsoft).


Microsoft Solutions Framework (MSF) -Componentes
MSF es un FrameWork que contiene tres componentes: Los principios fundamentales,
los modelos y las disciplinas. Pueden ser utilizados individuamente o adoptados
como un todo integrado según la naturaleza del proyecto.
Principios fundamentales
Los principios de MSF son 8 valores y normas que son comunes en todo el
FrameWork, los cuales contribuyen a mejorar el trabajo en equipo y a centrarse en
mantener el objetivo del proyecto siempre en marcha:
• Fomentar la comunicación abierta
• Trabajar hacia una visión compartida
• Empoderar a los miembros del equipo
• Establecer la rendición de cuentas claras y la responsabilidad compartida
• Centrarse en ofrecer valor empresarial
• Mantenerse ágil, en espera de un cambio
• Invertir en la calidad
• Aprender de todas las experiencias


Modelos
Los modelos describen esquemas a seguir para la organización de los equipos y los
procesos del proyecto, y especifica un modelo para el equipo de trabajo y uno para
los procesos:
a) Equipo de trabajo: Este modelo
se encarga de organizar las personas
para que realicen el trabajo y se
asegura que todas las metas del
proyecto se cumplan.
Define los principios, los roles y las
actividades involucrando al equipo
en
todas
las
decisiones
fundamentales que rodean el
proyecto.


Modelos
b) Proceso: Se encarga de organizar los procesos necesarios para lograr llevar a
término una solución.
Para esto se divide las tareas del proyecto en cinco fases, las cuales proporcionan
herramientas para mejorar el control sobre el proyecto, minimizar el riesgo y
aumentar la calidad del producto.
Al igual que el proceso RUP, MSF también
tiene sus prácticas inherentes al desarrollo
de software, tales como la especificación,
el desarrollo, la validación y la evolución
del software.


 Fase planificación: Se debe tener la ingeniería de requerimientos, planificación y
gestión de riesgos.

 Fase desarrollo: En esta fase se codifica y se realizan las respectivas pruebas,
también se identifican y mitigan los riesgos existentes.
 Fase estabilización: Se realizan pruebas beta, se crea un plan de gestión de
incidencias, se revisa la documentación final de la arquitectura y se elabora un
plan de despliegue.
 Fase implantación: Se libera la solución software, se crea un registro de mejoras
y sugerencias, se revisan las guías y manuales de usuario y se entrega el proyecto
final.


Disciplinas
MSF presenta un conjunto de métodos para la gestión del proyecto, la gestión del
riesgo y la gestión de preparación para el cambio
o Gestión de proyecto: Permitir mayor escalabilidad en proyectos pequeños,
grandes y complejos, basado en la planificación sobre las entregas cortas, la
incorporación de nuevas características sucesivamente, e identificar cambios
ajustando el cronograma.
o Gestión del riesgo: Ayuda al equipo a tomar las decisiones correctas y controlar
las emergencias que puedan presentarse, por medio de un entorno estructurado
para la toma de decisiones y acciones, valorando los riesgos que puedan provocar.
o Gestión de cambios: Lograr que el equipo sea proactivo en lugar de reactivo,
teniendo en cuenta que los cambios deben considerase riesgos y por lo tanto se
deben registrar y hacer evidentes.


En conclusión, la metodología propuesta por MSF tiene como propósito:
Lograr entregas con un margen amplio de éxito, basados en la calidad del producto
software, teniendo presente las necesidades del cliente y el principio de
flexibilidad, así como el cumplimiento con los compromisos adquiridos, la gestión de
los costos y la minimización de los riesgos inherentes en todo proyecto de desarrollo
de software.

XP (EXTREME PROGRAMMING )
La programación extrema es una metodología de desarrollo ligero (o ágil) basada
en una serie de valores y de prácticas de buenas maneras que persigue el objetivo
de aumentar la productividad a la hora de desarrollar programas.
Este modelo da prioridad a los trabajos que dan un resultado directo y que
reducen la burocracia que hay alrededor de la programación.

Una de las características principales de este método de programación, es que sus
ingredientes son conocidos desde el principio de la informática. Los autores de XP
han seleccionado aquellos que han considerado mejores y han profundizado en sus
relaciones y en cómo se refuerzan los unos con los otros.
El resultado de esta selección ha sido esta metodología única y compacta. Por
esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva
manera de ver el desarrollo de software.
El objetivo que se perseguía en el momento de crear esta metodología era la
búsqueda de un método que hiciera que los desarrollos fueran más sencillos
aplicando el sentido común.

La programación extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la adaptabilidad que en la
previsibilidad.

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son
un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los
cambios de requisitos en cualquier punto de
la vida del proyecto es una aproximación
mejor y más realista que intentar definir
todos los requisitos al comienzo del proyecto
e invertir esfuerzos después en controlar los
cambios en los requisitos.


XP (EXTREME PROGRAMMING ) -Prácticas
 Equipo completo: Forman parte del equipo todas las personas que tienen algo
que ver con el proyecto, incluido el cliente y el responsable del proyecto.

 Planificación: Se hacen las historias de usuario y se planifica en qué orden se van
a hacer y las mini-versiones. La planificación se revisa continuamente.
 Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus
propias pruebas para validar las mini-versiones.

 Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas
como para poder hacer una cada pocas semanas. Deben ser versiones que
ofrezcan algo útil al usuario final y no trozos de código que no funcionen.
 Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla
posible. Mantener siempre sencillo el código.
 Pareja de programadores: Los programadores trabajan por parejas (dos delante
del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio
diario).


 Desarrollo guiado por las pruebas automáticas: Se deben realizar pruebas
automáticas con mucha frecuencia. Cuantas más pruebas se hagan, mejor.
 Integración continua: Deben tenerse siempre un ejecutable del proyecto que
funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe
recompilarse y probarse.
 El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte
del código. Para eso se hacen las pruebas automáticas.
 Normas de codificación: Debe haber un estilo común de codificación, de forma
que parezca que ha sido realizado por una única persona.
 Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las
distintas partes del programa, de forma que sólo con los nombres se pueda uno
hacer una idea de qué es lo que hace cada parte del programa.
 Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener
indefinidamente. Esto quiere decir que no debe haber días muertos en que no se
sabe qué hacer y que no se deben hacer un exceso de horas otros días.

XP (EXTREME PROGRAMMING ) –Proceso

Se desarrolla en 4 fases
 Fase de planeación: Inicia con las historias de usuario que describen las
características/funcionalidades del software. El cliente asigna un valor o
prioridad a la historia; se evalúa cada historia y le asignan un costo que se mide
en semanas de desarrollo.
 Fase de diseño: Con diseños simples y sencillos para facilitar el desarrollo. Se
recomienda la correcta especificación de métodos y clases para facilitar
modificaciones, ampliaciones o reutilización de código.
 Fase de codificación: Se deben diseñar las pruebas de unidad que ejercitarán
cada historia de usuario. Después de tener las pruebas, los desarrolladores
trabajarán en parejas en lo que debe implementarse.
 Fase de pruebas: Las pruebas de unidad deben implementarse con un marco de
trabajo que permita automatizarlas, con la finalidad de realizar pruebas de
integración y validación diarias.

XP (EXTREME PROGRAMMING ) –Proceso

Diferencias RUP y XP


SCRUM
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en
un proceso iterativo e incremental utilizado comúnmente en entornos basados en
el desarrollo ágil de software.
Puede ser utilizado en equipos de mantenimiento de software, o en una
aproximación de gestión de programas: Scrum de Scrums.

Scrum es una metodología de desarrollo muy
simple, que requiere trabajo duro porque no se
basa en el seguimiento de un plan, sino en la
adaptación continua a las circunstancias de la
evolución del proyecto
• Es un modo de desarrollo de carácter adaptable más que predictivo.
• Orientado a las personas más que a los procesos.
• Emplea estructura de desarrollo ágil: incremental basada en iteraciones y

SCRUM
Se comienza con la visión general del producto, especificando y dando detalle a las
funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden
llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días).
Cada uno de estos periodos de desarrollo es una iteración que finaliza con la
producción de un incremento operativo del producto.
Estas iteraciones son la base del desarrollo ágil,
y Scrum gestiona su evolución a través de
reuniones breves diarias en las que todo el
equipo revisa el trabajo realizado el día anterior
y el previsto para el día siguiente.

SCRUM – Control de evolución del proyecto
Scrum controla empírica y adaptablemente la evolución del proyecto usando:
Revisión de las Iteraciones: Al fin de cada iteración se lleva a cabo una revisión
con todas las personas implicadas en el proyecto.
Desarrollo incremental: El desarrollo incremental implica que al final de cada
iteración se usa una parte del producto que se puede inspeccionar y evaluar.
Desarrollo evolutivo: Los modelos ágiles se emplean para trabajar en entornos de
incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales
cómo será el producto final no es realista.

Auto-organización: En Scrum los equipos son auto-organizados (no auto-dirigidos),
con decisión suficiente para tomar las acciones que consideren oportunas.
Colaboración: El entorno de trabajo ágiles facilitan la colaboración del equipo.

SCRUM – Visión general del proceso
Scrum denomina “sprint” a cada iteración de desarrollo y recomienda realizarlas
con duraciones de 30 días. El sprint es por tanto el núcleo central que proporciona
la base de desarrollo iterativo e incremental.
Los elementos que conforman el desarrollo Scrum son:
Las reuniones
• Planificación de sprint: Previa al inicio de cada
sprint en la que se determina cuál va a ser el
trabajo y los objetivos que se deben cumplir
en esa iteración.
• Reunión diaria: Breve revisión del equipo del
trabajo realizado hasta la fecha y la previsión
para el día siguiente.
• Revisión de sprint: Análisis y revisión del
incremento generado.

SCRUM

SCRUM - Valores
Scrum es una ayuda para organizar a las personas y el flujo de trabajo; como lo
pueden ser otras propuestas de formas de trabajo ágil.
• Delegación de atribuciones (empowerment) al equipo para que pueda autoorganizarse y tomar las decisiones sobre el desarrollo.

• Respeto entre las personas. Los miembros del equipo deben confiar entre ellos
y respetar sus conocimientos y capacidades.
• Responsabilidad y auto-disciplina (no disciplina impuesta).
• Trabajo centrado en el desarrollo de lo comprometido.
• Información, transparencia y visibilidad del desarrollo del proyecto.

4 1 personalizacion de metodologias

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie 4 1 personalizacion de metodologias

Ähnlich wie 4 1 personalizacion de metodologias (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

4 1 personalizacion de metodologias