PDF de programación - No todo es codificar - Modelos de Madurez en SL

No todo es codificar – Modelos de

Madurez en SL





Integrantes
A.C. Anahí Rodríguez
A.C. Valeria Soria

Modelos de Madurez

CMMI evalúa el modelo de madurez del proceso
de desarrollo del software. El nivel que posee
es demasiado complejo y no es aplicable a los
procesos de desarrollo de software libre.

En los últimos años se han desarrollado varios

métodos para definir un proceso de evaluación
de software Free/Open Source.





Selección de un Software

A la hora de seleccionar un software Free/Open Source, es

necesario contar con un método de clasificación, examinando
las limitaciones y los riesgos que tiene este tipo de software.

Algunas preguntas generales para hacer antes de seleccionar un

software son las siguientes:
¿Cual es la durabilidad del software?
¿Que nivel de estabilidad tiene o se espera?
¿Es fácil y factible agregarle funcionalidad al software?
¿Tiene una comunidad activa que lo avale?

Estas preguntas llevaron a definir los modelos de madurez de
proyectos de software Free/Open Source, los cuales en su
mayoría cuentan con:
Una puntuación según las características del software.
Una elección final, según los criterios de puntuación establecidos





OSMM – Capgemini

Primer modelo de madurez para software Open

Source.

Posee una licencia privada pero con autorización

para su distribución.

Fue desarrollado para comparar y decidir la

utilización de un producto.





OSMM – Capgemini (cont.)

Existen 27 parámetros (12 características

genéricas del producto y 15 características
basadas en las necesidades del usuario.)

La puntuación va de 1 a 5.









OSMM – Capgemini (cont.)

Ayuda a determinar la madurez del producto.
Ayuda a determinar si el producto cumple con los

requerimientos de la empresa.

Permite comparar los productos con alternativas

comerciales.

Muestra la importancia de utilizar productos Open

Source.





OSMM – Navica
Su método es más compacto que el propuesto

por Capgemini.

Academic Free License

Consta de 4 fases:

Primera Fase: Seleccionar el software que se va

a evaluar.





OSMM – Navica (cont.)

Segunda Fase: Ponderación de las siguientes

categorías:
Software (4 ptos)
Soporte (2 ptos)
Documentación (1 pto)
Capacitación (1 pto)
Integración (1 pto)
Servicios de profesionales (1 pto)





OSMM – Navica (cont.)
Tercer Fase: aplicación de cada una de las

plantillas correspondientes a las categorías
nombradas en la fase anterior en las cuales se
sugiere qué aspectos dentro de la categoría
deben ser evaluados ponderando cada uno de
estos aspectos.

Cuarta Fase: consiste en multiplicar la puntuación

de cada categoría por su ponderación para
producir una puntuación final de 0 a 100









BRR (Business Readiness Rating)

El proyecto fue anunciado en el 2005, este método

permite evaluar Software Free/Open Source.

Incluye cuatro pasos:

• Creación una lista con el software a evaluar.
• Clasificación y ponderación de los criterios de

selección.

• Recopilación de datos para cada criterio.
• Cálculo y publicación de los resultados.





BRR (cont.)

Tiene 12 criterios que pueden ser utilizados para evaluar

el software.

Por lo general sólo se utilizan 6 o 7 para la evaluación.

Funcionalidad: el software satisface las necesidades del

usuario?

Usabilidad: el software es intuitivo / fácil de instalar / fácil

de configurar / fácil de mantener?

Calidad: el software está bien diseñado, implementado y

probado?





BRR (cont.)

Seguridad: qué tan seguro es el software?
Rendimiento: cómo se comporta el software ante ciertas

circunstancias?

Escalabilidad: puede hacer frente al grandes volúmenes

de datos?

Arquitectura: el software es modular, portátil, flexible,
extensible y abierto? Puede ser integrado con otros
componentes?

Soporte: la comunidad cuenta con apoyo profesional?





BRR (cont.)

Documentación: existe documentación de buena

calidad?

Adopción: el software ha sido adoptado por la

comunidad, el mercado, y la industria?

Comunidad: la comunidad del software es activa?
Profesionalismo: que nivel de profesionalismo presentan

el proceso de desarrollo y la organización del
proyecto?





BRR (cont.)

No ha tenido el nivel de adopción (aceptación)
que se esperaba. Desde julio de 2010 que se
dio de baja el proyecto.

El proyecto aún no ha creado una comunidad

próspera





Qualification and Selection of Open
Source Software (QSOS)

Es un método, diseñado para calificar, seleccionar
y comparar Software Free/Open Source de una
manera objetiva.

GNU Free Documentation License.





QSOS (cont.)

El proceso consiste en 4 pasos. Cada una de estas

etapas son independientes entre si.

Paso 1 – Definición: definir elementos tales como:

Clasificación del software y descripción funcional.
Clasificación de Licencias
Clasificación de la comunidad

Paso 2 – Evaluación: consiste en coleccionar

información general del software, servicio ofrecidos y
aspectos funcionales y técnicos





QSOS (cont.)

Paso 3 – Calificación: Ponderación de los criterios. Esta
etapa sirve para eliminar el software que no satisface
las necesidades del usuario en un contexto específico.

Paso 4 – Selección: identificar el software que cumple
con los requisitos del usuario de dos modos posibles:

Una selección estricta
Una selección más amplia









NASA's Reuse Readiness Levels (RRL)
La NASA Earth Science Data Systems (ESDS) Software Reuse Working Group

(WG) reconoció la necesidad de medir la madurez del software para su
reutilización y propone una serie de niveles de preparación para la
reutilización (RRLs).La madurez de una tecnología en particular se puede
medir de varias maneras, un metodo conocido es el Technology Readiness
Levels (TRLs)

Se identificaron 9 áreas para medir la madurez de reutilización del software:

– Documentación
– Extensibilidad
– Cuestiones de Propiedad Intelectual
– Modularidad
– Empaquetado
– Portabilidad
– Cumplimiento de estándares
– Soporte
– Verificación y Pruebas





RRL (cont.)

Basado en TRL (Technology Readiness Levels), se tienen 9

niveles RRL (1 menos maduro – 9 más maduro):
– RRL 1 – Reutilización limitada.
– RRL 2 – Reutilización inicial.
– RRL 3 – Reutilización básica.
– RRL 4 – La reutilización es posible.
– RRL 5 – La reutilización es práctica.
– RRL 6 – Software es reutilizable.
– RRL 7 – El software es altamente reutilizable.
– RRL 8 – Se puede demostrar una reutilización local.
– RRL 9 – Se puede demostrar una reutilización extensa.





RRL (cont.)

Se creó una tabla (producto cartesiano) donde se
tienen las 9 áreas junto a los 9 niveles con una
breve descripción (Reuse Readiness Level
(RRL) Topic Area Levels Summary).









Nuestro estudio

Se toma como base de conocimiento dichos

métodos adoptando algunos criterios de
evaluación propuestos por los mismos.

Los puntos más importantes a ser evaluados son:









Links

OSMM – Capgemini
http://www.osspartner.com/portail/sections/accueil-public/evaluation-osmm
OSMM – Navica
http://www.oss-watch.ac.uk/resources/osmm.xml
BRR
http://www.oss-watch.ac.uk/resources/brr.xml
QSOS
http://www.qsos.org/
RLL
http://www.esdswg.org/softwarereuse/Resources/rrls/





Muchas Gracias!!!