Revista Digital

Calidad en desarrollo del Software Libre

Semestre: IX. Facilitador: Ing. Maria Alejandra Reyes

Sección: 1Alumno: Alcides Franco ‐ 5.451.716

Cátedra: Software Libre

República Bolivariana de VenezuelaMinisterio Del Poder Popular Para La Educación Universitaria

Universidad Bicentenaria de AraguaVicerrectorado Académico

Facultad de Ingeniería Escuela de Ingeniería de Sistemas

2

Introducción

La calidad se ha convertido en uno de los elementos diferenciadores en el ámbito mundial entre las compañías desarrolladoras de sistemas de software. La búsqueda de la calidad de los sistemas ha propiciado la creación de modelos, frameworks y metodologías para evaluar y asegurar su calidad.

El Software Libre también ha tenido un impulso que ha despertado un interés particular en sus herramientas y modelos de negocios, pero sobre todo en sus procesos de desarrollo.

Para eso es necesario definir la calidad y la necesidad de que este presente en el Software Libre.

3

La evaluación de la calidad del software siempre ha sido una parte importante del negocio de software. El proceso de evaluación de la calidad se basa generalmente en modelos jerárquicos de calidad que miden diversos aspectos de la calidad del software y deducir una caracterización de la calidad del producto que se está evaluando. La particular naturaleza del software de código abierto ha convertido a los modelos existentes en inadecuados para las evaluaciones detalladas de calidad. 

La realidad es que 

“No es aceptable que el vendedor de software acepte que su producto tiene errores, que no funciona adecuadamente y que cobre por algo que está MAL”.

PROBLEMAS IDENTIFICADOS EN LA CALIDAD DEL SOFTWARE LIBRE

• Desarrollo incompleto • Funcionamiento inadecuado• Abandono del desarrollo• Se escoge un distribuidor ¿y luego?• ¿Existe un verdadero control de la calidad?• No hay un rumbo definido• Todos ayudamos y colaboramos ¿y luego? • Se pueden agregar nuevas funciones ¿y luego?• Mucho desarrollo y ¿la documentación? 

El Mayor Problema:Se tiene el talento y el número de desarrolladores pero…Ausencia de procesos formales (CALIDAD) en el desarrollo y modificación de software libre. 

4

Rasgos de la Calidad en el SW libre

• Se trabaja en un entorno colaborativo.• Se trabaja de manera actualizada.• Fácil de compartir.• Existe estabilidad en los productos.• Se realizan pruebas piloto.• Está basado en una MEJORA CONTINUA.• Existe un modelo de negocio para cada organización. 

Rumbo a la Calidad en el SW libre

• Usar metodologías.• Definir y publicar los procesos de desarrollo y modificación entre la comunidad.

• Definir plazos.• Establecer controles.• Estar comunicados en un solo canal.• Medir la calidad.• Establecer verdaderos modelos de negocio.

¿Qué es un modelo de calidad de software? 

Es un conjunto de buenas practicas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos. 

Debemos tomar en cuenta  que Los modelos de calidad te dicen QUE hacer. no COMO hacerlo. 

¿Porque? 

Depende las metodologías que uses Depende de tus objetivos de negocio 

5

MOdelo Sistémico de CAlidad (MOSCA)La calidad de los Sistemas de Software no es algo que depende de una sola característica en particular, sino que obedece al compromiso de todas sus partes. Tomando en cuenta la calidad del producto y la calidad del proceso, el LISI‐USB desarrolló el Modelo Sistémico de Calidad de Software –MOSCA‐ que integra el modelo de calidad del producto y el modelo de calidad del proceso de desarrollo y está soportado por los conceptos de calidad total sistémica.

la hora de definir la calidad del software se debe diferenciar entre la calidad del producto software y la calidad del proceso de desarrollo de éste ‐calidad de diseño y fabricación. No obstante, las metas que se establezcan para la calidad del producto van a determinar los objetivos del proceso de desarrollo, ya que la calidad del primero va a depender, entre otros aspectos, de estos últimos. La calidad de los Sistemas de Software no es algo que depende de una sola característica en particular, sino que obedece al compromiso de todas sus partes. Ésta es una visión sistémica de la calidad del software.A

MOSCA es un modelo que integra los modelos de calidadpropuestos (ISO 926, SPICE, modelo Dromey),considerándolos como sub‐modelos de éste.

En cuanto a la perspectiva del producto, este modelo plantea, sobre la base de las 6 características de calidad del estándar internacional ISO/IEC 9126 (1991), un conjunto de categorías, características y métricas asociadas que miden la calidad y hacen del modelo un instrumento de medición de gran valor, ya que cubre todos los aspectos imprescindibles para medir directamente la calidad del producto de software. 

En cuanto a la perspectiva del proceso, este modelo se formuló sobre la base de las 5 características de calidad del estándar internacional  ISO/IEC 15504,  un conjunto de categorías, características y métricas asociadas que miden la calidad de un proceso de software con un enfoque sistémico. 

6

(MOSCA)

Consta de 4 Niveles

• Nivel 0 Dimensiones

• Nivel 1 Categorías

• Nivel 2 Características 

• Nivel 3 Métricas

Nivel 0: Dimensiones. 

• Eficiencia del proceso, • Efectividad del proceso, • Eficiencia del producto  • Efectividad del producto 

Son las cuatro dimensiones propuestas en el prototipo de modelo. Sólo un balance y una buena interrelación entre ellas permite garantizar la calidad Sistémica global de una organización.

Nivel 1: Categorías. 

Se contemplan 11 categorías: 6  pertenecientes al producto y las otras 5 al proceso de desarrollo.

Producto:Funcionalidad (FUN), Fiabilidad (FIA), Usabilidad (USA), Eficiencia (EFI), Mantenibilidad (MAB) Portabilidad (POR).

Proceso:Cliente‐Proveedor (CUS), Ingeniería (ENG), Soporte (SUP), Gestión (MAN)  Organizacional (ORG).

7

Nivel 2: Características. 

Cada categoría tiene asociado un conjunto de características (56 asociadas al producto y 27 al proceso de desarrollo), las cuales definen las áreas claves a satisfacer para lograr, asegurar y controlar la calidad tanto en el producto como en el proceso. 

Entre las características asociadas a cada categoría del producto, se proponen en el modelo MOSCA, una serie de características del proceso. Esto se debe a que algunas características de la calidad del  proceso, impactan directamente en las categorías del producto, al igual que ciertas características de la calidad del producto definen categorías del proceso.

Nivel 3: Métricas. 

La cantidad de métricas asociadas a cada una de las características que conforman MOSCA es de 587 en total.  Adicionalmente, MOSCA cuenta con un algoritmo que facilita su operacionalización y permite estimar la calidad de software. El algoritmo contempla tres fases: 

1. Estimación de la calidad del producto de software con un enfoque sistémico; 

2. Estimación de la calidad del proceso de desarrollo de software con un enfoque sistémico;  

3. Integración de las mediciones de los sub‐modelos de la calidad del producto y la calidad del proceso.

8

9

Algoritmo de aplicación de 

MOSCA

10

(MOSCA) Categorías del sub‐modelo del producto

Categoría del producto

Definición

Funcionalidad(FUN)

Capacidad del producto del software para proveerfunciones que cumplan con necesidadesespecíficas o implícitas, cuando el software esutilizado bajo ciertas condiciones

Fiabilidad (FIA) Capacidad del producto de software paramantener un nivel especificado de rendimientocuando es utilizado bajo condiciones especificadas

Usabilidad(USA)

Capacidad del producto de software para seratractivo, entendido, aprendido y utilizado por elusuario bajo condiciones específicas

Eficiencia (EFI) Capacidad del producto de software para proveerun rendimiento apropiado, relativo a la cantidadde recursos utilizados, bajo condicionesespecíficas

Mantenibilidad(MAB)

Capacidad del producto para ser modificado

Portabilidad(POR)

Capacidad del producto de software para sertransferido de un ambiente a otro

11

Distribución de las características y métricas para medir la calidad sistémica del producto

Distribución de las características y métricas para medir la calidad sistémica del producto

12

FUN. 3 Interoperabilidad Existencia de funcionalidades que pertenecen a otro sistema

¿Existen funcionalidades utilizadas por el producto, que  pertenecen  a otro sistema? 

0: no tiene1: tiene

DESARROLLADOR

Fiabilidad (FIA)FIA.1 Madurez Tiempo promedio entre 

fallas Tiempo promedio entre fallas

5= Semestral o más  4= Trimestral          3= Mensual             2= Semanal               1=  Diario

DESARROLLADORUSUARIO

FUN.1 Ajuste a los propósitos Cumplimiento de las necesidades funcionales

¿El producto cumple con todas las necesidades funcionales?

5=TODAS       4=CASI TODAS     3=MUCHAS                2=MUY POCAS          1= NINGUNA

USUARIO

MAB.4 Capacidad de prueba Funciones de pruebas ¿Existen pruebas internas en el código?

0=No1=Si

DESARROLLADOR

MOSCA Ejemplos de métricas definidas

13

Metodología SQO‐OSSEl modelo de calidad SQO‐OSS distingue de otros modelos de calidad de código abierto existentes de varias maneras:

1. Fue construido con un enfoque a la automatización, mientras que el resto de los modelos requieren gran injerencia del usuario y carecen de la automatización de la colección de métricas.

2. Es el núcleo de un sistema de monitoreo continuo de la calidad y la colección automática de métricas  garantizando  que se realicen evaluaciones con relativamente datos recientes. 

3. No evalúa funcionalidad. Evaluar la funcionalidad requiere que el evaluador debe jugar un papel importante en el proceso de evaluación y por lo tanto introduce la subjetividad. El modelo SQO‐OSS se centra en los aspectos fundamentales de la Calidad OSS, a saber mantenibilidad, fiabilidad y seguridad.

4. Se centra en el código fuente. El código fuente es el producto mas importante de un proyecto de desarrollo de software y su calidad debe desempeñar un papel importante en la determinación de la evaluación final del producto.

5. El modelo SQO‐OSS también considera la comunidad de código abierto. Sin embargo, tiene en cuenta sólo aquellos factores de la comunidad que se pueden medir automáticamente.

6. A medida que la evaluación  necesita el punto de vista del  evaluador, permitimos que el usuario intervenga en el proceso de evaluación basado en la medición de categoría de perfiles. 

14

Metodología SQO‐OSSDefinición del Modelo:

Se trata de centrarse sólo en los atributos que se pueden medir con mínima intervención humana (automatización)

Generalmente podemos asumir que un proceso de evaluación se puede dividir en dos fases, la definición del modelo de evaluación y la definición del proceso de medición. En nuestro caso, cada fase incluye dos etapas distintas: Fase Uno: Definición del modelo de evaluación 

Asumimos que la calidad del software libre depende de dos factores críticos: Código y Comunidad

Con el fin de medir esos factores y la construcción del modelo se utiliza una versión simplificada del Meta ‐ Pregunta – Métrico Enfoque (GQM)

1. Definición de los criterios del modelo (atributos y sub‐atributos).2. Definición de métricas.

Fase dos: Definición del método de agregación

1. Definición de las categorías de evaluación2. Definición de las categorías de perfiles.

Dos objetivos finales donde:

Analizar el código fuente de un proyecto de código abiertoAnalizar la comunidad de un proyecto de código abierto

15

Metodología SQO‐OSSLa fase uno representa el trabajo realizado con el fin de definir el marco de evaluación, la aplicación de nuestra noción de calidad, la definición de los criterios de calidad y las métricas que miden estos criterios. Para estos objetivos  nos formulamos preguntas iterativas: 

"¿Cómo se mide la calidad del código fuente?" 

Entonces, respondiendo a las preguntas  nos formulamos nuevas:

"¿Cómo se mide la capacidad de mantenimiento, la fiabilidad y la seguridad?" 

Y para el mantenimiento seguimos el enfoque dela norma ISO / IEC 9126  

"¿Cómo es la analizabilidad, mutabilidad, la estabilidad y la capacidad de prueba medida? " 

Seguimos formulando preguntas hasta que llegamos a un nivel donde los atributos podrían medirse directamente (métricas) Elegimos sólo los indicadores y métricas adecuadas y aceptables para la automatización

La segunda fase

Representa la parte de recolección de datos yla agregación de los resultados de lasmediciones con el fin de llegar a un resultadopara la calidad del artefacto en evaluación.

En este punto tenemos que poner más énfasisen el hecho de que en todo este proceso, laautomatización era la principal preocupación.Es necesario un modelo que se pueda aplicarde forma automática y en una buena cantidadde proyectos, alimentado continuamente conlos datos del observatorio SQO‐OSS. Así quetratamos de enfocar en los atributos decalidad que se puede medir con lainterferencia humana mínima.

Para ejemplo usabilidad implica una ampliainteracción humana por lo que no fue elegidocomo un atributo de calidad para el modelo. Elmismo criterio se sigue para la selección demétricas.

16

Metodología SQO‐OSS

17

Metodología SQO‐OSSEjemplo de criterio de Métricas para calidad del producto y la comunidad

18

Metodología SQO‐OSSProceso de evaluación

Con el fin de tener un resultado tenemos que combinar todas las métricas.  Para ello se ha utilizado el perfil basado en la evaluación, en lugar del método de la suma promedio ponderado tal como lo hace el proceso de jerarquía Analítica . 

La razón para ello era que queríamos medidas en escala ordinal  en lugar de escalas de intervalo 

Se toman  resultados en forma de excelente, bueno, regular y pobres ‐ Estos también son nuestras cuatro categorías de evaluación (por ahora en E, G, R y F)

El  método, para cuatro categorías, requiere la definición de tres perfiles de calidad ‐ E, B y F • Estos perfiles representan los valores mínimos de medición necesarios para cada categoría y se definen por separado para cada criterio compuesto por el modelo  Por lo tanto, con el fin de caracterizar la calidad del producto con una  E, en  mantenibilidad, fiabilidad y seguridad deben también ser caracterizados como E. 

Los usuarios del modelo pueden modificar los perfiles de acuerdo a su necesidad ‐ también pueden alterar los pesos, aunque esto no es recomendado.

19

Proceso de agregación

El proceso de agregación se realiza con el uso de relaciones iterativa con todos los perfiles dados expresando nuestra decisión de comparar el artefacto con los perfiles

Un artefacto x se considera que es al menos tan buena como la y perfil si y sólo si la mayoría "ponderada" de los criterios acuerdan así ‐ hay pruebas específicas que representan la fuerza para llegar a fin de llegar a tal decisión

Hay otro tipo de asignación, que identifica el perfil que seguramente es peor que x y asigna x al anterior (por ejemplo, si x es estrictamente peor que E, entonces se asigna a G), pero esto no se toma en cuenta

Metodología SQO‐OSS

20

Metodología SQO‐OSS

Revista Digital

Calidad en desarrollo del Software Libre