Calidad

Explicando la Calidad de Software Usando Sillas

sg — Wed, 07 Nov 2018 15:23:46 +0000

Explicando la Calidad de Software Usando Sillas sg Wed, 11/07/2018 - 09:23

Publicado en

SG #42

Calidad

Autor

José Sánchez Vázquez

Aunque en principio puede parecer que los costos de contratar el desarrollo de un software a la medida a través de una empresa especializada son mucho mayores que si contratamos a un equipo de freelancers, es importante evaluar todos los aspectos involucrados, especialmente la calidad y tiempo de entrega, lo cual a la larga puede resultar incluso más caro. Para entender esta dicotomía, pensemos en cómo funciona la calidad en el software comparándola con algo más tangible como la elaboración de unas sillas. Imaginemos la siguiente historia ...

Una empresa hotelera en crecimiento ha decidido cambiar las sillas de sus lujosos hoteles alrededor del mundo. La dirección de operaciones ha decidido descartar las soluciones “de caja” ya que una silla prefabricada y empaquetada no soluciona las necesidades y requerimientos especiales de sus hoteles más fastuosos. Así que el personal de compras se da a la tarea de buscar fábricas de sillas para cubrir las necesidades especiales y los altos requerimientos de las mismas. Después de algunos días dicho personal entrega un análisis a su jefe inmediato al cual le dicen lo siguiente:

"En general todos las fábricas de sillas requieren de un análisis de entre 1 y 4 semanas tan solo para analizar qué tipo de silla necesitamos y a partir de esto poder realizar una cotización".

Algunas caras de asombro se dejan ver en la reunión mientras que una gerencia que no conoce la importancia y sensibilidad del tema, expresa:

"Yo tengo un conocido que se dedica a eso, es un excelente ebanista quien ya ha fabricado una gran cantidad de sillas y además trabaja a un precio muy económico, yo podría llamarlo y concertar una reunión".

La reunión termina con la decisión de contratar al ebanista para que elabore una silla de prueba, y adicionalmente escoger a alguna de las fábricas de sillas para que realice el análisis.

Al día siguiente, un par de personas de una de las fábricas de sillas hacen una visita y realizan una enorme cantidad de preguntas: cuál es el perfil de los clientes del hotel, cantidad de estrellas de los hoteles, ubicación geográfica de cada uno, altitud, cercanía al mar, etcétera. La gran cantidad de preguntas llega al grado de desesperar a más de uno del personal que los atiende y que ya entre pasillos comentan:

"¿Para que tantas preguntas? Sólo pedimos hacer una silla"

El equipo de la fábrica de sillas se retira y comenta que en una semana enviarán la cotización.

Por su parte, el ebanista llega varios días después de que lo citaron, se disculpa sin mucho afán ya que ha tenido mucho trabajo y hasta ese día ha tenido tiempo de atender la solicitud. Sin embargo, se torna muy seguro, pregunta el tipo de madera del cual quieren las sillas, toma algunos datos con un lápiz en una pequeña libreta ya con muy pocas hojas, hace algunas señas con las manos indi- cando el tamaño que tendrá la silla, murmura unas palabras para sí mismo; piensa un poco y un par de minutos después comenta que estará en una semana y que el costo será de $1,000.

Pasa la semana y llega la cotización de parte de la fábrica de sillas. De acuerdo con esta, el costo será de $50,000 por el diseño y la configuración de la maquinaria de la fábrica mas $500 por cada silla. Además comentan que el tiempo requerido para el diseño y la configuración será de 6 meses explicando que es el tiempo mínimo que se toma reconfigurar la maquinaria de la fábrica de sillas y que se requiere el 50% de anticipo.

Al día siguiente el ebanista llega con su preciosa silla con un excelente acabado y con algunos detalles y adornos que le mermaron su utilidad.

En la siguiente reunión para tratar el tema, estos son algunos de los comentarios que se escuchan de parte de los gerentes:

"¡El precio de la fábrica de sillas es ridículo! ¿Nos van a cobrar por configurar su maquinaria? ¡Es una fábrica! ¡Deberían de ser más rápidos!"

Ante esto, y a pesar de que algunos no están convencidos y saben que algo no está del todo bien, se toma la decisión de con- tratar al ebanista para hacer todas las sillas.

Unos días después citan al ebanista para negociar la elaboración de las 300 sillas de cada uno de sus 10 hoteles, y como es evidente la empresa hotelera busca que el ebanista les cobre menos por la fabricación de las mismas, al fin y al cabo son 3,000 sillas así que por volumen debe de ser más barato. Se le da al ebanista un plazo máximo de 2 años, por lo que tendrá que contratar a algunos amigos y compañeros de su oficio. Después de negociar mucho, fijan el precio en $750.00 por silla, el ebanista hace cuentas para sí mismo y piensa:

"Son $2,250,000.00 ¡claro que me conviene!"

Al cabo de 4 años, el ebanista y sus compañeros terminan las sillas. Todas son similares pero no idénticas como esperaba la dirección de la empresa hotelera. Además, no resultan tan útiles en algunos hoteles donde la humedad o el clima les presentan problemas mayores con la calidad.

Al igual que en esta pequeña historia, cuando se habla de desarrollo de software es común que se piense que los costos por el análisis y diseño son excesivos; peor aún si se mencionan actividades como la gestión de la calidad, gestión de la configuración o instalación en producción. Esto sucede porque el software, al ser un bien intangible, se vuelve susceptible de apreciaciones erróneas como: "si se hace bien a la primera, no hay razón para que tenga errores", "¿para qué necesitas analizar si ya te dije lo que quiero?", "¿establecer una arquitectura y un diseño?, ¡ni que fuera un edificio!".

Si bien las características del software lo hacen un blanco natural para este tipo de cuestionamientos por parte de los clientes, nosotros mismos como profesionales del software también lo mutilamos con el uso de malas prácticas, por ejemplo:

No analizar: “¿Para qué analizar? Total, los requerimientos siempre cambian”.
No hacer diseño: “Es más fácil escribir directo el código y sobre la marcha decido el diseño”.
Desarrollar y no documentar: “Es mi código, nadie tiene por qué entenderlo”.
Liberar sin hacer un plan de pruebas: “El cliente nunca va a hacer eso, no tiene por qué fallar”.

Estos y muchos otros vicios tenemos que quitar antes de poder alfabetizar a los clientes sobre cómo funcionan las cosas en nuestra profesión.

Entre todos podemos cambiar la Industria del Software.

Bio

José Sánchez Vázquez es Licenciado en Sistemas Computacionales y cuenta con una Maestría en Habilidades Directivas. Tiene más de 10 años experiencia en desarrollo de Aplicaciones de Escritorio y Sistemas Web de los cuales los últimos 6 han estado enfocadas al Comercio Exterior. Cuena con conocimientos y experiencia en Administración de Proyectos y Análisis de Negocios.

Asegurando la Calidad de la Experiencia de Usuario

sg — Wed, 12 Oct 2016 08:03:33 +0000

Asegurando la Calidad de la Experiencia de Usuario

sg Wed, 10/12/2016 - 03:03

Publicado en

SG #52

Calidad

Autor

Roselyn Piñango

Según el ISTQB (International Software Testing Qualifications Board), uno de los objetivos de las pruebas, es satisfacer compromisos aplicando la validación de los requisitos de usuario respecto al sistema que está siendo objeto de la prueba. Igualmente este estándar define las pruebas de sistema como aquellas que se realizan desde la perspectiva del usuario y predomina como protagonista el equipo de QA para ejecutarlas [1]. Por otro lado, uno de los atributos no funcionales de la calidad según la norma ISO9126 es la usabilidad que consiste en la capacidad que tiene un software de ser amigable, atractivo y útil al usuario final. Ahora bien, el dinamismo tecnológico ha permitido que usuarios no expertos interactúen con la tecnología como parte de su día a día haciéndolos más exigentes. La validación de requisitos, pruebas de sistema y la usabilidad ya no son suficientes, es necesario que las pruebas incluyan en su alcance la experiencia de usuario (UX).

La experiencia de usuario es el conjunto de factores y elementos relativos a la interacción del usuario con dispositivos o software tecnológico cuyo resultado es la generación de una percepción positiva o negativa de dicho servicio, producto o dispositivo. Ésta depende no solo de los factores relativos al diseño sino además de aspectos relativos a las emociones, sentimientos, confiabilidad y transmisión de la marca (2). El diseño de la experiencia del usuario se define como el proceso de aumentar la satisfacción y lealtad del cliente mediante mejoras en la usabilidad, facilidad de uso y el placer de la interacción entre el cliente y el producto.

El diseño de experiencia de usuario se preocupa por un número mayor de variables que el diseño de interfaz de usuario y no necesariamente están relacionadas con el aspecto visual, por ejemplo: la presentación de los productos, redacción de contenidos, la velocidad de carga, entre otros factores. Algunos de los principios de este tipo de diseño son el color, eficiencia, error humano, estética, íconos, jerarquía visual, legibilidad, mapeo natural y visibilidad, entre otros. Definitivamente esto compromete aún más a los especialistas en ingeniería de requisitos y en sí, al proceso de interacción con los usuarios de manera que el equipo de desarrollo y pruebas pueda conocer las pautas, funcionalidades y expectativas que debe cumplir el sistema.

En el ámbito de las pruebas, esto significa que no será suficiente la base de pruebas que utiliza un equipo de QA (listado de funcionalidades) sino es necesario comprender claramente cuál es la motivación del sistema, qué beneficios traerá, qué se busca con su construcción y qué se espera de él. Para ello es necesario que las pruebas de calidad de la experiencia de usuario cuenten con la participación del usuario, pero no significa que estas pruebas deban realizarse al final del ciclo de vida de desarrollo, al contrario, debe ser una de las primeras exploraciones (por ejemplo por medio de prototipos) a realizar dentro del enfoque de pruebas definido respetando el principio “pruebas tempranas” de ISTQB. Pudiera ser un nuevo nivel de pruebas híbrido probador/usuario.

De de las pruebas más conocidas en este ámbito son las A/B que consisten en dos escenarios controlados que se envían/cargan de forma aleatoria a los usuarios (normalmente una muestra de ellos) con el objetivo de medir la efectividad de un diseño de interfaz y/o contenido en específico. Otro tipo de prueba utilizada es la llamada think aloud (piensa en voz alta) en donde se le solicita al usuario que utilice el sistema, narrando sus pensamientos y percepciones del mismo mientras navega por las funcionalidades del sistema. Lo importante es que se contemple desde QA que las pruebas del diseño de experiencia de usuario no es tarea única del profesional de QA, se trata de un trabajo conjunto con el usuario, y aunque algunos autores califican estas pruebas como “costosas”, sin duda no es equivalente a desarrollar un sistema que no sea utilizado cuando esté en producción.

Conclusión

La tecnología avanza y los usuarios son cada día más exigentes con los sistemas que reciben para su rutina laboral o vida diaria, lo cual significa un reto adicional para los profesionales de QA, en donde el objetivo de satisfacer compromisos lo obliga a ser un tecnólogo multidisciplinario que debe garantizar la mejor experiencia de usuario posible, funcionalidad (y otros atributos de la calidad) bajo la arquitectura idónea para el contexto donde se ejecutará el sistema, convirtiéndolo en un profesional integral.

Referencias:

“Foundation Level Syllabus”. ISTQB, 2011. http://swgu.ru/rt

Bio

Roselyn C. Piñango Díaz es Ingeniero en Computación con especialización en Sistemas de Información. Gerente de QA Factory en Global R, Venezuela. Cuenta con 10 años de experiencia en desarrollo y pruebas de software; y certificaciones: OCE SQL, OCA PL/SQL Developer, CTFL ISTQB, ASE HP ALM v11, CAA SAPB1.

El futuro es hoy

sg — Fri, 19 Sep 2014 18:20:17 +0000

El futuro es hoy sg Fri, 09/19/2014 - 13:20

Publicado en

SG #45

Calidad

Autor

Ana Vázquez

La semana pasada me di cuenta que el futuro que habíamos visualizado para MoProSoft llegó. Por un lado un consultor de procesos de software canadiense me dijo que estaba trabajando con sus clientes para implantar la ISO/IEC 29110, “por fin una norma que avala todo lo que le digo a mis clientes” externó. Por otro lado, vi que Brasil lanzó un paquete de formatos para la adopción de la norma en Portugués, Inglés y Español, lo que para mí es un claro indicador de que ya se subieron a la norma internacional, pues algunos lo dudábamos debido a que tienen una norma nacional bastante consolidada .

Mi júbilo aumentó cuando tratando de explicar a mi colega canadiense sobre la situación de los procesos de software en México encontré que en el 2013 México reporto 58 evaluaciones CMMI ocupando con esto el 4º lugar a nivel mundial. También encontré que hay más de 300 evaluaciones en MoProSoft y que ya hay 5 empresas evaluadas en la ISO/IEC 29110. El asombro del canadiense era evidente, después de hablar un poco sobre precios me dijo “no sabía, voy a mandar a desarrollar mi software allá”, en ese momento pensé “lo estamos logrando”.

Estaba en este tenor cuando leí la columna de mi querida Dra. Oktaba, con quien he tenido la fortuna de trabajar en forma intermitente desde finales de los 90. Ella estaba muy lejos de compartir la euforia en la que yo estaba inmersa, fue entonces cuando decidí, contrario a mi costumbre, sentarme a escribir estas líneas para compartir la visión que teníamos en el 2006 cuando presentamos MoProSoft ante ISO/IEC y como hoy desde el extranjero la veo convertida en una realidad.

Un poco de historia

La primera visionaria fue Gloria Quintanilla quien, cuando se enteró del esfuerzo que se estaba haciendo en ISO/IEC buscó la oportunidad de hablar sobre MoProSoft al Dr. Claude Laporte, una de las personas que está liderando el esfuerzo. Él a su vez invitó a México a unirse al grupo. En aquel entonces, Gloria en su calidad de presidenta de la (lamentablemente extinta) AMCIS gestionó la participación de México ante el grupo de ISO/IEC. Cuando todo estaba listo un contratiempo personal no le permitió asistir, y fue así como Jorge Palacios y una servidora haciendo milagros con el presupuesto que teníamos e invirtiendo de nuestras propios ahorros nos lanzamos a la aventura de hacer que la norma internacional se pareciera lo más posible a la norma mexicana, que fue el objetivo que nos fijamos en el órgano de normalización nacional.

Cualquier otro resultado a largo plazo hubiese sido desastroso para las empresas que ya habían invertido en MoProSoft, pues habría otro estándar internacional con el mismo objetivo y dirigido al mismo sector, al que las empresas que quisieran un distintivo internacional tendrían que migrar.

Como buenos mexicanos, muchos se quejaron amargamente de que Jorge y yo hubiésemos asistido a la reunión en lugar de alguien mejor calificado y estoy de acuerdo, habían muchos colegas mejor calificados que nosotros para ir. Sin embargo creo que pocos nos hubieran ganado en entusiasmo y seguridad al llevar un producto de clase mundial, elementos que logramos transmitir en la presentación, logrando que nuestra norma fuera elegida como base para los trabajos del grupo, sobre otras que se habían analizado provenientes de diversas partes del mundo, logrando con ello un objetivo que nadie se atrevió a proponer, por parecer más bien un sueño guajiro.

Gracias a ello hoy, mientras otros países están conociendo, adoptando y preparando los entes de normatividad para comenzar a hacer las evaluaciones, en las listas del NYCE ya hay 5 empresas evaluadas, y más de 300 evaluaciones en MoProSoft que incluye casi en su totalidad la norma ISO/IEC 29110. Es hoy cuando estas empresas mexicanas pueden salir a buscar oportunidades con una referencia internacional de calidad, es hoy cuando tienen esa ventaja competitiva y me da un gusto enorme ver que algunas lo están haciendo, ya que en marzo pasado al menos una de ellas que vino a Montreal en busca de negocios con su evaluación MoProSoft bajo el brazo. Por una coincidencia providencial, sé de primera mano que esta semana va a ser contactada por una empresa canadiense que le va a proponer un negocio.

Esta PYME mexicana se ganó esta oportunidad seguramente gracias a muchos años de trabajo arduo, a su certificación pero sobre todo a su osadía de haber venido a buscar negocios al primer mundo sin complejos.

Ya sé lo que están pensando “China y la India tienen más evaluaciones”, y lo que al respecto yo les diría que la ventaja de estos países no está en sus evaluaciones de calidad si no en algunos aspectos de su cultura, misma que tuve oportunidad de conocer de cerca cuando un equipo de Indios me admitió en su equipo de trabajo en una de mis clases de maestría. La primera junta fue para persuadirme sobre las ventajas de trabajar realmente como un equipo, fue entonces cuando aprendí que en su lengua materna (una de tantas de aquel país) cuando se habla de trabajo y de gente 1 más 1 no es 2 si no 11.

¿Qué estamos haciendo el equipo México por la ISO/IEC 29110?

El ente relacionado directamente con la norma es la CANIETI en su calidad de comité espejo del grupo ISO/IEC JTC1, ahora es clave que la delegación mexicana, encabezada por Claudia González, siga contando con el apoyo necesario para seguir participando en las reuniones internacionales, para que los futuros perfiles de la ISO/IEC 29110 también sean hermanos gemelos de MoProSoft.

Hice una búsqueda rápida en internet en inglés sobre la norma, encontré información proveniente de Canadá, EEUU, Irlanda, Brasil, Perú, y Finlandia un país bastante lejano y diferente al nuestro. De México encontré un trabajo de la UNAM y un webinar de SG, ¡necesitamos más! si no queremos que Brasil nos “coma el mandado”, pues en esa misma búsqueda vi que son ellos quienes están capacitando evaluadores en Irlanda.

Irlanda fue uno de los países a los que la Secretaría de Economía pidió ayuda para comenzar a delinear la estrategia del programa PROSOFT, recuerdo claramente a un Irlandés, que con la amabilidad que los caracteriza, nos dijo que en su país para mejorar la industria de software habían trabajado en mejorar sus procesos. Paradójicamente después de unos años ellos mismos están adoptando la norma que generó México para seguir su recomendación, este hecho nos debe dar una perspectiva adecuada del avance que hemos logrado.

Como consultor de procesos de software, desde Canadá les digo que contrario a lo que se podría pensar, el conocimiento tengo sobre MoProSoft e ISO/ IEC 29110 es más exportable que el que tengo en CMMI pues de este modelo, a pesar de ser muy reconocido, hay muy pocas iniciativas de implantación, debido a que es muy caro para el entorno de este país.

Para concluir me gustaría ver los números de otra forma, alrededor de 300 empresas que ostentan una evaluación de procesos de software muy cercana a la norma internacional, con la posibilidad de utilizar dicha certificación para generar confianza en clientes y socios tanto en México como en el extranjero, así como una infraestructura funcionando para que las empresas que así lo deseen tenga los medios para obtener la certificación. Adicionalmente las empresas evaluadas tiene la posibilidad de integrarse para competir con empresas más grandes por proyectos que estarían fuera de sus capacidades, ya que MoProSoft facilita la integración a nivel operativo, porque tiene la virtud de ir más allá de una la lista de requerimientos. El futuro es hoy y hay que aprovecharlo.

Bio

Ana Vázquez actualmente estudia la maestría en Calidad en la Universidad de Concordia en Canadá, y es representante de
Praxis en el área de Quebec. Fue pionera en la adopción del PMBoK, revisora reconocida de su versión 2000, ha implantado
ISO 9000 y CMMI. Colaboró en la adopción de MoProSoft como norma nacional, y se desempeñó como jefa de la delegación
en las reuniones del comité ISO/IEC JTC.

Priorización de Atributos de Calidad en Sistemas Modulares Integrados

lasr21 — Fri, 17 Aug 2012 17:54:55 +0000

Priorización de Atributos de Calidad en Sistemas Modulares Integrados lasr21 Fri, 08/17/2012 - 12:54

Publicado en

SG #37

Calidad

La priorización de atributos de calidad es una práctica que contribuye a la reafirmación y consenso de las expectativas de calidad de los involucrados en la creación de un software, las cuales son fundamentales para construir y evaluar la arquitectura que lo soporta.

La tendencia actual del desarrollo de software gira en torno a varias corrientes arquitectónicas, dentro de las cuales ha tomado fuerza la construcción de sistemas modulares. Esta arquitectura favorece el mantenimiento y el futuro crecimiento de las aplicaciones. Un software modular permite desarrollar por partes un mismo sistema e integrar los módulos en la medida en que lo impongan las reglas de negocio.

En todo caso, cuando se quiere lograr que un software posea los índices de calidad exigidos por el cliente y sea de la aceptación de este, es fundamental prestarle mucha atención a la definición y priorización de atributos de calidad. Aunque la funcionalidad y otras cualidades están estrechamente relacionadas, lo que sucede en ocasiones es que en lograr la funcionalidad se centran todos los esfuerzos en el esquema de desarrollo.

Como muestra la Figura 1, la calidad integral de un sistema modular es difícil de determinar una vez que se integren módulos. Aunque un sistema posee un conjunto de requisitos no funcionales de atributos de calidad de manera general (que afectan a todo el sistema), también posee un conjunto de requisitos no funcionales a nivel de módulos, que hacen que la calidad integral del sistema varíe en la medida en que este vaya integrando sus partes.

Materiales y Métodos

Para la realización del presente trabajo se utilizaron los métodos científicos histórico-lógico, hipotético-deductivo y la observación. Se emplearon la Media aritmética y la Desviación estándar como métodos estadísticos para las bases teóricas de la propuesta. Además se contaron con materiales las metodologías y métodos asociados a la evaluación de la arquitectura del software que se describen a continuación.

Modelo ISO/IEC 9126

El estándar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software. Este estándar es una simplificación del Modelo de McCall e identifica seis características básicas de calidad que pueden estar presentes en cualquier producto de software. La Norma de calidad ISO/IEC 9126-1 tiene como puntos a favor que:

Es una normativa respaldada por una organización reconocida internacionalmente en la temática de estandarización de calidad de productos y con un alto prestigio en ese campo.
Ha sido acogida por Cuba como norma regulatoria en cuanto a calidad de productos de software.
Cuenta con una amplia y detallada definición de los elementos de calidad de un producto de software y además trae descrita una métrica en correspondencia para la determinación final de niveles de calidad.

Evaluación de arquitectura de software

A la arquitectura de un software se le atribuye la responsabilidad de lograr el cumplimiento de cualidades o características de calidad, más allá de lo meramente funcional. Las decisiones arquitectónicas que se tomen estarán entonces dirigidas a la complacencia de los requisitos funcionales y no funcionales que establezca cada cliente. Evaluar la arquitectura de un software es un medio para la obtención de indicadores de calidad del producto que bien pueden servir para:

Determinar si el software que se está construyendo respalda los requisitos funcionales y no funcionales que le fueron atribuidos.
Decidir la mejor opción entre arquitecturas candidatas.
Decidir cuál software, de varios posibles, respalda mejor los requisitos de un cliente.

Priorización de atributos de calidad

En la construcción y evaluación de la arquitectura es muy importante conocer las prioridades a las que debe responder la línea base del software. Cada decisión arquitectónica tomada en beneficio de algún requisito o atributo de calidad puede simultáneamente incidir positiva o negativamente en cualquier otro, de ahí que establecer prioridades contribuya a la obtención de aplicaciones con calidad. Para los efectos de la presente investigación se señalan tres corrientes fundamentales:

La determinación cualitativa de prioridades, tal como propone el método ATAM mediante la creación de un árbol de utilidad.
Los atributos de calidad que componen el sistema de “utilidad” son sacados, especificados hasta el nivel de los escenarios, anotados con el estímulo y la respuesta, y priorizados. En este paso se propone presentar a las partes interesadas un árbol de atributos, teniendo en cuenta su priorización), y en base a los resultados que se vayan obteniendo (inclusión o eliminación de atributos, cambio en priorización) entonces el equipo de arquitectos elabora el árbol de utilidad al nivel de escenarios.
La determinación cualitativa de prioridades enfocada a la arquitectura orientada a componentes, tal como propone el método MECABIC.
Este método proporciona un árbol de utilidad inicial específico para la arquitectura de software basada en componentes a partir del cual seleccionan un conjunto de escenarios de interés, el cual está basado en el modelo de calidad ISO 9126-1 para arquitecturas de software propuesto por Losavio.
La determinación cuantitativa de prioridades.
Asignaciones de valores numéricos y porcientos de cumplimiento para cálculos de índices arquitectónicos que permitan conocer el cubrimiento de la arquitectura respecto a sus atributos de calidad asociados.

Figura 1. Comportamiento de la calidad de un sistema y su descomposición en subsistemas (módulos).

Resultados y discusión

El primer paso en la búsqueda de un equilibrio de los atributos de calidad potenciados con las decisiones arquitectónicas, lo constituye la priorización de dichos atributos de manera que:

Posibilite la toma de decisiones arquitectónicas, para el logro del equilibrio de los factores de calidad, según su orden de prioridad.
Establezca un posible orden de prueba del cumplimiento de los atributos de calidad durante la evaluación, en función de prioridades.

Teniendo en cuenta estos elementos, se propone establecer un mecanismo cuantitativo para la priorización que combine los criterios de arquitectos e interesados.

Priorización de atributos por subsistemas

Para los efectos de esta investigación, la Importancia de lograr el requisito, es un concepto que va a estar sujeto a la posición de cada votante con respecto a la aplicación, la cual genera intereses diversos. Es por esta razón que, los criterios subjetivos de cada persona involucrada en la priorización, no son manejados sino el interés final de los mismos en el logro de cada requisito, en una escala sujeta a su nivel de importancia. El rango de valores admisibles para este criterio es:
5: Muy importante
4: Importante
3: Medianamente importante
2: Poco importante
1: No importante

Del desglose anterior se deduce que: a mayor valor, mayor importancia.

Una vez obtenidos los votos de cada uno de los interesados y los arquitectos, se tendría una priorización de lo que se pudiera denominar “hojas” en el contexto de un árbol de calidad tal y como lo representa la ISO/IEC 9126-1, dicho árbol estaría compuesto (en orden descendente) por: atributos, sub-atributos y RNF (Requisitos No Funcionales) de atributos de calidad con sus respectivas priorizaciones. Esto quedaría:

1. Funcionalidad
1.1. Seguridad
(5) El sistema concederá acceso a cada usuario autenticado solo a las funciones que le estén permitidas, de acuerdo a la configuración del sistema.
(5) El sistema manejará mecanismos de encriptación para las contraseñas de los usuarios. Interoperabilidad
(3) El sistema almacenará información proveniente del Sistema Mantenimiento Vehicular, al mismo tiempo que enviará información a este, todo de manera automática y transparente para el usuario final.
(4) El sistema permitirá importar información en los formatos Word y Excel.

Luego, se hace necesario conocer las prioridades, que se irán derivando de las atribuidas mediante votación, para el resto de los niveles del árbol. Para ello, en el caso del cálculo de prioridad de los sub-atributos se emplea el criterio de la media aritmética, expresado mediante la fórmula:
= (ΣXi * fi ) / fi
Siendo:
Xi: Valores de importancia.
fi: Cantidad de requisitos asociados a cada valor.

Siguiendo el ejemplo del árbol anterior, el cálculo quedaría como se muestra en la Tabla 1.

Tabla 1. Uso de la media aritmética para el cálculo de prioridad del sub-atributo Seguridad.

Tomando como Rango de Priorización los posibles valores que se encuentran en la priorización de todos los requisitos. Para el ejemplo mostrado en la Tabla 1 el cálculo de la prioridad del sub-atributo Seguridad quedaría:
= (ΣXi * fi ) / fi
= 10,00 / 2
= 5,00

Análogamente se calcula la media para el sub-atributo Interoperabilidad. Completando el árbol se tendría:
1. Funcionalidad
(5.00) Seguridad
(5) El sistema concederá acceso a cada usuario autenticado solo a las funciones que le estén permitidas, de acuerdo a la configuración del sistema.
(5) El sistema manejará mecanismos de encriptación para las contraseñas de los usuarios.
(3.50) Interoperabilidad
(3) El sistema permite importar información proveniente de sistemas externos para operar con ella, al mismo tiempo que permite exportar datos a sistemas externos.
(4) El sistema permitirá importar información en los formatos Word y Excel.

Para el cálculo de la prioridad de los atributos, como máximo nivel del árbol, se hace uso de la media aritmética, esta vez teniendo en cuenta las prioridades de todos los requisitos asociados a sus sub-atributos. Siguiendo la ejemplificación del árbol anterior, quedaría como en la Tabla 2.

Tabla 2. Uso de la media aritmética para el cálculo de prioridad del atributo Funcionalidad.

Tomando los datos de la Tabla 2, el cálculo de la prioridad del atributo Funcionalidad quedaría:= (ΣXi * fi ) / fi
= 17,00 / 4
= 4,25

Priorización a nivel de sistema

Una vez establecida la prioridad de los atributos de calidad por cada subsistema, es posible determinar la prioridad general del sistema, tomando para el cálculo de esta dos grupos de valores:

Los valores de prioridad calculados para cada subsistema.
Los valores de prioridad de atributos y sub-atributos en base a los requisitos no funcionales generales del sistema.

El segundo grupo de valores se calcula análogamente al proceso de cálculo de prioridades por subsistema, o sea, haciendo uso de la media aritmética.

Una vez calculados ambos grupos, los valores se agrupan como en la Tabla 3.

Tabla 3. Agrupación de valores para atributos.

La Tabla 3 muestra un ejemplo de la agrupación de valores para atributos, pero de esta misma manera habrá de hacerse para los sub-atributos. Para determinar la prioridad final del sistema, tanto de atributos y sub-atributos se emplea igualmente la media aritmética, teniéndose siempre en cuenta que, a mayor valor de media obtenido, mayor será la prioridad.

En aquellos casos en que los valores obtenidos coincidan para más de un indicador, se propone emplear la Desviación estándar, como criterio estadístico que permite acortar la brecha de variaciones entre los valores de prioridad para un mismo atributo a calcular. Haciendo uso de este criterio, será posible distinguir cuál de los indicadores con igual valor de media debe tener mayor prioridad, en este caso sería el de menor desviación de sus valores de origen.

La desviación estándar se utiliza cuando hay varios resultados posibles y estos están dispersos, lo cual acarrea inseguridad en el resultado final. Mientras más concentrados estén los resultados, habrá más confianza en el resultado.

Lo anterior se traduce: a menor valor calculado entre una serie de elementos con valores dispersos, mayor será la probabilidad de ocurrencia de ese elemento. Siendo la Desviación estándar igual a la raíz cuadrada positiva de la varianza, se calcula entonces el valor de la última mediante la fórmula:
S2 = Σn (Xi - Ẋ)2 / n, donde:
S2 = Varianza
Xi = Valor del atributo en cada caso.
Ẋ = Valor de la media del conjunto de valores asociados al sub-atributo/atributo.
n = cantidad total de valores analizados.

Si se toman los valores de muestra de la Tabla 3 y se calcula la Varianza para los atributos confiabilidad y usabilidad, quedaría:

Confiabilidad

S2 = ((3.3 – 3.7)2 + (3.9 – 3.7)2 + (3.9 – 3.7)2 + (3.7 – 3.7)2) / 4
S2 = (0.16 + 0.04 + 0.04 + 0) / 4 = 0.06
S = √ S2 = √ 0.06 = 0.24

Usabilidad

S2 = ((3.9 – 3.7)2 + (3.8 – 3.7)2 + (3.6 – 3.7)2 + (3.5 – 3.7)2) / 4
S2 = (0.04 + 0.01 + 0.01 + 0.04) / 4 = 0.025
S = √ S2 = √ 0.025 = 0.16

Los cálculos realizados arrojan un menor valor para el atributo Usabilidad, por lo cual la prioridad mayor en este caso deberá ser para ese indicador. La priorización entonces quedaría (recuérdese que a mayor valor, mayor prioridad):

6. Funcionalidad
5. Usabilidad
4. Confiabilidad
3. Eficiencia
2. Portabilidad
1. Mantenibilidad

Con esta propuesta, se armonizan las solicitudes y expectativas de calidad de arquitectos e interesados, con características de los grandes sistemas de software: modulares e integrados.

Sin embargo, no basta con eliminar los conflictos entre intereses y características de sistema, pues siguen quedando fuera de análisis los conflictos propios que se generan entre atributos.

Conclusiones

Los atributos de calidad son elementos claves a tener en cuenta para el desarrollo de una arquitectura sólida, por lo cual conocer sus prioridades es un elemento fundamental que permitirá discernir en el medio de los conflictos que generan las decisiones tomadas por los arquitectos para alcanzarlos. El empleo de criterios estadísticos en la priorización de atributos permite valorar todas las expectativas de calidad de los involucrados en la creación de un software, de manera que se tengan en cuenta todas las opiniones y las variaciones entre estas.

Referencias:
[1] Ambe, Mildred N. y Vizeacoumar, Frederick. Evaluation of two architectures using the Architecture Tradeoff Analysis Method (ATAM). [pdf] 29 de abril de 2002.
[2] Billy Reynoso, Carlos. (Marzo de 2004). Introducción a la Arquitectura de Software. Buenos Aires.
[3] Camacho, Erika, Cardeso, Fabio y Nuñez, Gabriel. Arquitecturas de software. Guía de estudio. abril de 2004.
[4] Collabera, V. Gnanasekaran. Evaluating Application Architecture, Quantitatively. [html] s.l. : The Architecture Journal, Marzo de 2010. Journal 24.
[5] Gómez, O. Evaluando la Arquitectura de Software. Parte 1. Panorama General. 40-41. México: Brainworx S.A. de C.V. Enero-febrero de 2007.
[6] González, Aleksander, y otros, y otros. Método de Evaluación de Arquitecturas de Software Basadas en Componentes (MECABIC). [pdf] Caracas : Laboratorio de Investigación en Sistemas de Información (LISI). Universidad Simón Bolívar, 2005.
[7] González Alvarez, Larisa y Leyet Hernández, Osmar. (2010). Modelo de evaluación de arquitectura de software del Proyecto ERP-Cuba. V Conferencia científica UCIENCIA. Febrero de 2010.
[8] Panovski, G. Product Software Quality. Master’s Thesis.Eindhoven. Febrero de 2008.

Bio

Larisa González Alvarez, Roberkys Martin Cruañes y Tahirí Rivero Alvarez son profesores en la Universidad de las Ciencias Informáticas en La Habana, Cuba.

Ingeniería de la Confiabilidad de Software

sg — Wed, 11 Jul 2007 17:58:34 +0000

Ingeniería de la Confiabilidad de Software

sg Wed, 07/11/2007 - 12:58

Publicado en

SG #12

Calidad

Autor

Las organizaciones que desarrollan productos basados en software requieren de prácticas efectivas que permitan mejorar la calidad del producto. La Ingeniería de la Confiabilidad de Software es una práctica cuantitativa que puede ser implementada en organizaciones de cualquier tamaño bajo distintos modelos de desarrollo.

Las organizaciones desarrolladoras de productos basados en software destinan grandes cantidades de recursos para mejorar la calidad de sus productos. Una parte de dichos recursos se utiliza para la adopción de mejores prácticas. Sin embargo, la dificultad de la adopción de dichas practicas no sólo reside en el costo y el tiempo requerido para institucionalizarlas, sino en cómo medir su impacto en la calidad del software, así como demostrar el retorno de dicha inversión. El grupo de Confiabilidad de Software y Sistemas (SoSYR) del Centro de Investigación en Matemáticas A.C., lleva a cabo investigación sobre prácticas industriales de bajo costo, con un alto impacto en la calidad de los productos de software y que sean aplicables a organizaciones de distintos tamaños.

En este artículo se introduce a la Ingeniería de la Confiabilidad de Software (ICS). La ICS es una práctica de bajo costo, independiente del modelo de desarrollo y de la plataforma tecnológica que permite caracterizar y controlar de manera cuantitativa la calidad del producto.

La calidad, las fallas y la confiabilidad de Software
La calidad es un atributo percibido por los usuarios o clientes de cualquier producto o servicio. En el caso de productos basados en software, la percepción de la calidad está en función de las fallas que el cliente percibe del mismo durante su operación.

La confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajo condiciones establecidas por un periodo de tiempo determinado. La confiabilidad es un atributo cuantitativo que ha sido ampliamente analizado, estudiado y usado en otras industrias para caracterizar la calidad de los productos o servicios. En su concepción más general, la confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajo condiciones establecidas por un periodo de tiempo determinado.

Una falla es la manifestación percibida por el cliente de que algo no funciona correctamente e impacta su percepción de la calidad. Un defecto es el problema en el producto de software que genera una falla.

¿Qué es la Ingeniería de Confiabilidad de Software?

La ICS es una práctica que permite planear y guiar el proceso de la prueba del software de manera cuantitativa. La ICS no es algo nuevo. Se origina en los años 70 con los trabajos de J. D. Musa, A. Iannino, y K. Okumoto[1]. Su efectividad ha hecho que muchas empresas incorporen esta práctica en sus proyectos, tales como AT&T, Alcatel, HP, IBM, Lockheed-Martin, Microsoft, Motorola, entre otras. El impacto de dicha práctica se ha visto en la aprobación de un estándar de la AIAA (en 1993) así como sus correspondientes versiones en los estándares de IEEE. Cabe mencionar que se han documento más de 60 artículos reportando los resultados de la aplicación de la ICS en distintos proyectos[2].

Dos elementos caracterizan la ICS: (1) el uso esperado relativo de las funcionalidades del sistema y (2) los requerimientos de calidad definidos por el cliente, que incluyen la confiabilidad, la fecha de liberación y costo del ciclo de vida del proyecto.

El primer elemento (1) se centra en caracterizar de manera cuantitativa el uso esperado del sistema mediante la definición del llamado perfil de operación del sistema. Esta caracterización cuantitativa permite optimizar el uso de los recursos en las funciones que tengan un mayor impacto y mayor uso esperado dentro
del sistema.

El perfil de operación de un sistema es la caracterización cuantitativa del uso que se espera de las funcionalidades principales del sistema. Por lo general se usan probabilidades para cuantificar dicho uso esperado.

El segundo elemento (2) se refiere al enfoque al cliente mediante el establecimiento de objetivos cuantitativos asociados a la calidad del producto (representados con base a las fallas del producto). La satisfacción de dichos objetivos permite establecer un balance entre los costos del producto, así como la satisfacción de las necesidades del cliente.

¿Por qué usar la ICS?

La ICS es independiente de la tecnología y de la plataforma de desarrollo. No requiere ningún cambio en arquitectura, diseño, o código, sino que puede sugerir los cambios que serían útiles. También, la ICS está altamente orientada al cliente y está altamente correlacionada con los niveles 4 y 5 del Modelo Integrado de Madurez de las Capacidades (CMM-I) del Instituto de Ingeniería de Software. Su alta orientación al cliente se debe a la naturaleza de la información requerida en el proceso de la ICS, lo que implica tener un contacto frecuente y cercano con los clientes. Esta interacción mejora la satisfacción del cliente y reduce riesgos de manera similar a lo propuesto en los métodos ágiles de desarrollo.

La alta correlación con los niveles de madurez 4 y 5 de CMM-I se debe a que dicha práctica satisface varios objetivos relacionados con la medición para la optimización del proceso de desarrollo. La ICS es una buena opción para alcanzar dicho objetivo. Comparado con las ventajas, el costo de aplicar la ICS es bajo de acuerdo a la experiencia de John D. Musa[3]. Hay un costo de inversión de no más de 3 días equivalentes del personal por persona en una organización, que incluye un entrenamiento de dos días para cada uno y la planeación con un número mucho más pequeño. Los gastos reflejados en el proyecto varían típicamente a partir 0.1 a 3.0 por ciento de costo total del proyecto[3]. Cabe mencionar que el componente más grande del costo es el asociado al desarrollo del perfil de operación.

El proceso de la ingeniería de confiabilidad de software

El proceso de la ICS puede verse como un conjunto de actividades adicionales y complementarias a las ya realizadas dentro de cualquier proceso de desarrollo. Seis actividades definen el marco de trabajo de la ICS que son mostradas en la Figura 1 y descritas a continuación.

1. Definir el Producto. Puede verse como un complemento del Análisis de Requerimientos y Diseño Arquitectónico. En esta actividad se define quiénes son los clientes, usuarios, proveedores y otros sistemas relacionados.

2. Desarrollar el Perfil de Operación. Se define el conjunto completo de operaciones (i.e., tareas o funcionalidades lógicas principales del sistema) con su correspondiente probabilidad de ocurrencia o uso esperado. En esta etapa, la administración de los recursos toma un nivel cuantitativo basado en la importancia de cada operación del sistema. La Tabla 1 muestra un ejemplo parcial de un perfil de operación para un producto para la navegación en el Web.

Figura 1. Proceso de la ICS[2]

Tabla 1. Ejemplo de un Perfil de Operación

3. Definir la Confiabilidad Adecuada. Se define lo que se considera como “falla” para el producto en desarrollo así como los medios para identificarla. Esta definición es crítica para el proceso y debe ser constante durante todo el ciclo de vida. La Tabla 2 muestra un ejemplo de clases de severidades de fallas y ejemplos de cada tipo de falla.

Tabla 2. Clases de Severidades de Fallas

En la segunda parte de esta actividad se definen las medidas de referencia con la que se cuantificarán las intensidades de falla, tales como el número de fallas por tiempo o número de fallas por unidad natural. Las unidades naturales representan la cantidad de proceso o trabajo realizado por el sistema (e.g., transacciones, páginas impresas, llamadas a funciones, accesos, etcétera).

En la tercera parte de la actividad se fijan las Intensidades de Falla Objetivo (IFO) para cada sistema asociado al producto. Las IFOs representan la calidad del producto en desarrollo y son definidas por el cliente.

En la cuarta parte se seleccionan las mejores estrategias de apoyo a la confiabilidad de software que ayuden a alcanzar los IFOs respectivos al menor costo. Las estrategias de apoyo a la confiabilidad de software son aquellas actividades y mecanismos dentro del proceso de desarrollo que reducen las intensidades de falla y afectan positivamente los costos y el tiempo de desarrollo. Ejemplos de dichas estrategias incluyen mecanismos de tolerancia a fallos, inspecciones, revisiones, distintos tipos de pruebas, etc.

La ICS proporciona pautas y cierta información cuantitativa para la determinación de la mezcla de estrategias. Sin embargo, los proyectos pueden mejorarse usando la información que es particular a su ambiente y al dominio propio del producto.

4. Preparar las Pruebas. Se definen los casos de prueba y los métodos de prueba a partir de la información de los perfiles operacionales y las estrategias de apoyo a la confiabilidad de software. Esta actividad puede integrarse con el proceso de pruebas del modelo de desarrollo que se tenga. Lo importante en esta etapa es la decisión de qué cosas se van a probar y qué datos se usaran en los casos de prueba.

5. Ejecutar las Pruebas. Se asignan los tiempos para las pruebas entre los sistemas, los tipos de prueba (i.e., características, carga y regresión) así como su ejecución.

6. Guiar las Pruebas. Se procesa la información obtenida en la ejecución de las pruebas para varios propósitos. El primero es monitorear el crecimiento de la confiabilidad del sistema (o la reducción de las intensidades de falla) mientras se van reparando los defectos encontrados que generaron las fallas. Otro propósito es el de poder determinar si es necesario seguir probando; finalmente, el tercero es el de dirigir la fase del liberación del producto. La Figura 2 muestra una grafica típica usada para monitorear la reducción de las intensidades de falla.

Figura 2. Gráfica para controlar las actividades de Prueba[3].

Algo muy importante dentro del proceso de ICS es la recolección de datos de campo (i.e., información sobre el uso y las fallas encontradas en la operación real del sistema). El proceso de ICS no está completo cuando se libera el producto dado que la información que usamos puede ser imprecisa. El recolectar dicha información permitirá evaluar con mayor detalle la satisfacción del cliente y la calidad del producto.

En esta breve descripción del proceso de la ICS se han omitido detalles relacionados con aspectos cuantitativos. Existen modelos estadísticos que permiten determinar el momento para detener las actividades de prueba basados en la información que se tiene de las fallas encontradas, objetivos de intensidades de falla y del número de casos de prueba ejecutados. Recomendamos al lector revisar [3, 4] para una mayor información.

Conclusión

Podemos decir que la efectividad que presenta la ICS reside en una idea ya mencionada por Tom de Marco: “No puedes controlar lo que no puedes medir.”. La bondad de la ICS reside en llevar dicha idea a elementos concretos con beneficios específicos:

La construcción del perfil de operación mejora el análisis de requerimientos dado que el proceso de cuantificar las probabilidades de uso de las operaciones del producto exige un proceso adicional de reflexión y trabajo con el cliente.
La definición de lo que se considera como “falla” para el producto involucra discutir con el cliente y usuarios los criterios de calidad del producto. Esta idea establece las bases para medir la calidad del producto reduciendo riesgos.
La determinación de qué estrategias de apoyo a la confiabilidad del software son usadas para la calidad deseada del producto provee de un medio cuantitativo para optimizar los recursos del proyecto.
El monitoreo cuantitativo de los resultados de las pruebas y del crecimiento de la confiabilidad permite administrar mejor el proyecto.

La ICS representa una práctica que puede ser usada con resultados positivos. Las micro y pequeñas industrias pueden incorporar dicha práctica dentro de sus procesos no sólo para mejorar la calidad de sus productos sino para sentar las bases que permitan definir el marco de medición de sus procesos en busca de niveles 4 y 5 de CMM-I.

Referencias
1. Musa, J., Iannino, Okumoto; Software Reliability: Measurement, Prediction, Application, ISBN 0-07-044093-X, McGraw-Hill, 1987.
2. User Experiences with Software Reliability Engineering. Available at: http://members.aol.com/JohnDMusa/users.htm
3. Musa, J., Software Reliability Engineering: More Reliable Software Faster and Cheaper, AuthorHouse, 2nd ed., 2004.
4. Lyu, M. (Editor), Handbook of Software Reliability Engineering, ISBN 0-07-039400-8, McGraw-Hill, 1996.

Bio

Gerardo Padilla Zárate es consultor en temas de Ingeniería de Software enfocados en la prueba de software, confiabilidad del software, calidad de la información, así como modelado y construcción de componentes de software. Actualmente es candidato a Doctor en Ciencias de la Computación por parte del Centro de Investigación en Matemáticas y forma parte del Grupo de Ingeniería de Software, así como del Grupo de Confiabilidad de Sistemas y Software.

Enrique Villa Diharce es investigador en el Departamento de Estadística y miembro de los grupos de Estadística Industrial y Confiabilidad en Software y Sistemas del CIMAT. Además, es instructor de cursos de licenciatura, maestría y doctorado, así como de cursos de capacitación de alto nivel en la industria, donde ha brindado asesoría a empresas como PEMEX, IMP, CFE, Mabe, e IG entre otras. Enrique recibió el grado de Doctor en Ciencias con especialidad en Probabilidad y Estadística del CIMAT en 1999.

Carlos Montes de Oca Vázquez se desempeña como profesor e investigador en el Departamento de Ciencias de la Computación en el CIMAT, donde es coordinador del grupo de Ingeniería de Software y miembro del grupo de Confiabilidad en Software y Sistemas. Además, tiene una amplia y reconocida trayectoria en áreas relacionadas con el enfoque de procesos, modelos de calidad, vinculación y transición de tecnologías a la industria. Recibió el grado de Doctor en Ciencias Computacionales de la Louisiana State University en 1999.