Bienvenida
Bienvenidos a la sexta semana del curso de Calidad del Software, en la que estudiaremos las normas ISO/IEC, IT
Mark, SCRUM, SQuaRE. Con estos estándares lograremos organizar, enriquecer y unificar las series que cubren
los procesos principales: Especificación de requisitos de calidad de software y la evaluación de calidad del software,
soportada por el proceso de medición de la calidad del software, las características y medición de la calidad son
útiles para la evaluación de un proyecto de software así como para la definición de los requerimientos de la calidad.
Introducción al tema
A medida
que
aumenta
el uso de
la
Tecnología de la Información, aumenta también el número de sistemas de computación que son críticos, en los
cuales un error puede traer consecuencias graves. Ejemplos de estos sistemas los encontramos en áreas tales
como la salud, el ámbito financiero o la seguridad.
La mejora en la calidad del software es un objetivo importante. Una falla en estos sistemas puede implicar serias
consecuencias. En el caso de un sistema de salud, un error puede producir la perdida de una vida. En el caso del
área financiera, un error en una transferencia puede poner en dificultades dicha institución, ya que se ve
perjudicada, entre otros, la idea que tienen los clientes de realizar operaciones seguras. Por estas razones, surge la
necesidad de poder evaluar la calidad de un producto de software, tanto para su adquisición como para el desarrollo
de dicho producto.
La importancia que se le dará a las diferentes características de calidad del software va a depender de los objetivos
que deba alcanzar el sistema del cual forma parte.
Puesto que la calidad del software es un elemento crucial que impacta en la seguridad y entre otros aspectos
importantes de las empresas en los costes finales de una organización, evaluarla y controlarla es cada vez más
importante, especialmente si se hace directamente en base a evidencias sobre atributos del propio producto
software.
La calidad del producto, junto con la calidad del proceso, es uno de los aspectos más importantes actualmente en el
desarrollo de Software. Relacionada con la calidad del producto, recientemente ha aparecido la familia de normas
ISO/IEC 25000, que proporciona una guía para el uso de la nueva serie de estándares internacionales llamada
Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE - System and Software Quality
Requirements and Evaluation).
ISO/IEC 25000 constituye una serie de normas basadas en ISO/IEC 9126 y en ISO/IEC 14598 cuyo objetivo
principal es guiar el desarrollo de los productos de software mediante la especificación de requisitos y evaluación de
características de calidad. (iso25000, 2015)
Aprendizajes esperados
Actitudes
La Organización Internacional de Normalización o ISO, creada después de la Segunda Guerra Mundial (23 de
febrero de 1947), es el organismo encargado de promover el desarrollo de normas internacionales de fabricación
(tanto de productos como de servicios), comercio y comunicación para todas las ramas industriales. Su función
principal es la de buscar la estandarización de normas de productos y seguridad para las empresas u
organizaciones (públicas o privadas) a nivel internacional.
La ISO es una red de los institutos de normas nacionales de 163 países, sobre la base de un miembro por país, con
una Secretaría Central en Ginebra (Suiza) que coordina el sistema. Está compuesta por delegaciones
gubernamentales y no gubernamentales subdivididos en una serie de subcomités encargados de desarrollar las
guías que contribuirán al mejoramiento.
Las normas desarrolladas por ISO son voluntarias, comprendiendo que ISO es un organismo no gubernamental y
no depende de ningún otro organismo internacional, por lo tanto, no tiene autoridad para imponer sus normas a
ningún país. El contenido de los estándares está protegido por derechos de copyright y para acceder a ellos el
público corriente debe comprar cada documento. (ISO.ORG, 2015)
ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and Evaluation), es una
familia de normas que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad del
producto software.
La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores, especialmente de las normas
ISO/IEC 9126, que describe las particularidades de un modelo de calidad del producto software, e ISO/IEC 14598,
que abordaba el proceso de evaluación de productos software. Esta familia de normas ISO/IEC 25000 se encuentra
compuesta por cinco divisiones. (iso25000, 2015)
5.1.1 Introducción:
El creciente interés de las empresas de desarrollo de software en mejorar sus procesos internos ha impulsado
diferentes iniciativas para el desarrollo de modelos de integración o aplicación simultánea de estándares de calidad
de software. Entre las normas y estándares internacionales relacionados con la calidad del software más
demandados por las empresas de este sector, destacan los modelos de calidad de procesos de software, los
modelos de gestión de servicios de Tecnologías de la Información (TI) y los modelos de gestión de seguridad de la
información.
La mayoría de los modelos anteriores estructuran sus recomendaciones, directrices, requisitos o mejores prácticas
bajo un enfoque basado en procesos. Gracias a este mismo enfoque, existen una gran cantidad de relaciones entre
los diferentes modelos, así como muchos elementos y aspectos en común. Así pues, se pueden aprovechar estas
relaciones y elementos comunes a la hora de implantar diferentes estándares de calidad, evitando duplicidades y
reduciendo los esfuerzos y recursos necesarios para su implantación. (Figueroa, 2013)
Desde el año 2000, uno de los principales intereses de nuestro grupo de investigación,
MiProSoft, ha sido promover la Mejora de los Procesos de Software (SPI, del inglés Software Process Improvement)
en las empresas de desarrollo de software de nuestro entorno. Con este objetivo, desde el año 2002, nuestro grupo
ha liderado diferentes programas de SPI en pequeñas y medianas empresas de las Islas Baleares a través del
proyecto QuaSAR (Qualitat del Software baleAR) (Amengual and Mas 2003; Amengual and Mas 2007; Mas and
Amengual 2003; Mas and Amengual 2004, Mas and Amengual
2005).
Estos programas de SPI han posibilitado, por una parte, el análisis del sector de desarrollo de software en las Islas
Baleares y, por otra parte, la provisión de unas directrices para estas empresas para la mejora de sus procesos de
software.
El proyecto QuaSAR fue un proyecto pionero a nivel regional puesto que en el año
2002 todavía no había ninguna empresa de desarrollo de software en nuestra comunidad con una certificación de
calidad ISO 9001, pero también a nivel nacional, pues supuso la primera experiencia de implantación simultánea de
las normas ISO 9001 e ISO/IEC 15504. Las 8 organizaciones participantes en este proyecto, además de obtener la
certificación de calidad ISO 9001, iniciaron un programa de mejora de procesos según el estándar internacional
ISO/IEC 15504 que en la actualidad todavía sigue vigente en alguna de ellas (Mas et al. 2009).
Dado que la tendencia actual en las organizaciones se dirige también hacia nuevos dominios de interés, como
pueden ser la gestión de servicios de TI o la gestión de la seguridad de la información, se plantea la necesidad de
crear un modelo integrado de los estándares de gestión de TI más demandados por las empresas del sector de
desarrollo de software.
6.1.2 ISO 9001
La ISO 9001 es una norma internacional que se aplica a los sistemas de gestión de calidad (SGC) y que se centra
en todos los elementos de administración de calidad con los que una empresa debe contar para tener un sistema
efectivo que le permita administrar y mejorar la calidad de sus productos o servicios. (ISO.ORG, 2015)
Desde junio del 2012 se inició la revisión de la versión actual de la norma; ciertamente la intención es hacer una
renovación mas grande mayor. Se busca que con el uso y certificación de esta norma las empresas sean más
competitivas para el año 2020. Según el INLAC la norma cambiará en un 30%, respecto a la versión 2008; teniendo
una estructura de alto nivel, incorporando dos nuevos requisitos quedando su estructura de la siguiente manera:
(www.inlac.org, 2015)
1. Alcance
2. Referencias Normativas
3. Términos y Definiciones
4. Contexto de la Organización
5. Liderazgo
6. Planificación
7. Soporte
8. Operación
9. Evaluación del Desempeño
10. Mejora
El proceso de revisión de la norma ISO 9001 inicia su fase final, después de que el pasado 3 de junio se publicara
el borrador de la ISO 9001:2015, elaborado por el comité técnico ISO/TC 176 responsable de elaborar las normas
de ISO 9000 y complementarias. Siguiendo la planificación prevista, el FDIS (borrador final) se publicará en
noviembre de 2014 para poder publicar definitivamente la nueva versión de la norma en el otoño del año 2015.
6.1.3 ISO 9000-3
La norma ISO 9000-3 son los estándares utilizados para el desarrollo, suministro y mantenimiento del software.
Con la norma se busca dar orientaciones en situaciones en las que se exija la demostración de la capacidad de un
proveedor para desarrollar, suministrar y mantener productos de software. La norma sugiere clases de control y
métodos para la producción de software que satisfaga los requisitos establecidos.
Las ideas básicas del estándar ISO 9000-3 según son las siguientes: (A., A., C, & J.C., 2012)
• El control de calidad debe ser aplicado a todas las fases de la producción de software, incluido el mantenimiento y
tareas posteriores a su implantación.
• Debe existir una estricta colaboración entre la organización que adquiere el software y el proveedor del mismo.
• El proveedor del software debe definir su sistema de calidad y asegurarse que toda la organización ponga en
práctica este sistema.
Es importante resaltar que en la ISO 9000-3 trata el concepto de ciclo de vida, pero en ningún momento no desea
imponer la utilización de un determinado ciclo como puede ser el ciclo en espiral de Boeh. Pero a parte del ciclo de
vida que elijamos, el ISO 9000-3 introduce otras actividades que tienen lugar de forma independiente a las fases del
ciclo y que son las actividades referentes a la configuración y distingue entre la verificación y validación.
Además el ISO 9000-3 puede ser utilizado en relaciones contractuales cuando comprador y proveedor establecen
que algunos elementos de calidad deben formar parte del sistema de calidad que proporciona el proveedor y que
este se compromete a seguir los principios de calidad definidos en el estándar.
A continuación se describe
NUMERO CLAUSULA las cláusulas más
importantes:
4.1 Administración de la Responsabilidad
• Administración de la
Responsabilidad: Esta
4.2 Sistema de Calidad cláusula permite organizar la
estructura del sistema de
4.3 Auditorías Internas del Sistema de Calidad calidad, abordando la
estrategia y organización
como requerimientos para
4.4 Acción Correctora
verificar y revisar la calidad.
La ISO 10013 proporciona
5.1 General una orientación
complementaria.
5.2 Revisión del Contrato • Sistema de Calidad:
Requiere una planificación y
documentación del sistema
5.3 Especificación de los requerimientos de la Organización
de calidad, requisito
conocido como ‘Plan de
5.4 Planificación del desarrollo Garantía de Calidad del
Software’ o SQAP utilizado
5.5 Planificación de la Calidad en el estándar IEEE 730.
• Acción correctora: No
existe una receta para el
5.6 Diseño e Implementación proceso de acciones
correctoras, pero el estándar
5.7 Testeo y Validación IEEE 1044 nos puede ser
5.8 Aceptación útil, para clasificar los tipos
de anomalías que pueden
ser encontradas en un
5.9 Generación, Entrega e Instalación
sistema semejante al que
estamos tratando.
5.10 Mantenimiento • Revisión del contrato: Esta
cláusula, aunque
6.1 Administración de la Configuración aparentemente parece
obvia, insiste en la
necesidad de que el
6.2 Documentos de Control
proveedor examine los
contratos referidos al
6.3 Calidad de los Archivos sistema de calidad.
• Especificación de los
6.4 Medidas requerimientos de la
Organización: Se establece
la premisa de la mutua
6.5 Reglas y Convenciones
colaboración entre el
proveedor y la organización
6.6 Herramientas y Técnicas que adquiere el producto
software.
• Planificación del desarrollo:
6.7 Compra
Esta cláusula sitúa los
requerimientos en un plan
6.8 Productos de software incluidos de desarrollo.
Particularmente exige la
6.9 Formación definición de un proceso
disciplinado o metodología
que incluye: fases de desarrollo, entradas, salidas y procesos de verificación. El estándar IEEE 1074, Procesos del
Ciclo de Vida del Desarrollo de Software, podría resultarnos particularmente útil para satisfacer estos
requerimientos.
• Planificación de la Calidad: La metodología de medidas de Calidad descrita en el estándar IEEE 1061, puede
sernos útil para establecer los objetivos de calidad.
• Diseño e Implementación / Testeo y Validación: Estas dos cláusulas se centran en las actividades centrales del
proceso de desarrollo de software.
• Aceptación: Estas pruebas son más bien generales, dado que en los estándares del IEEE no hay definido un
homólogo
• Generación, Entrega e Instalación: Los requerimientos de pruebas y medios de control existentes en el IEEE 730,
pueden ser de utilidad pero no son suficientes, para abordar los contenidos de esta cláusula.
• Mantenimiento: Esta cláusula proporciona una extensa lista de requerimientos de calidad, para la fase de
mantenimiento del ciclo de vida. El estándar IEEE 1219 proporciona unos requerimientos detallados e importantes
para llevar a cabo un proceso de mantenimiento adecuado.
Las cláusulas restantes proporcionan requerimientos para las actividades de soporte, es decir aquellas que no son
específicas de ninguna fase en concreto, del ciclo de vida.
• Administración de la Configuración/ Documentos de Control: Las actividades que detallan estos requerimientos, se
encuentran en los llamados Planes de Gestión de la Configuración del Software, los cuales quedan descritos en el
estándar IEEE 828.
• Medidas / Reglas y Convenciones / Herramientas y Técnicas: Estas cláusulas nos hablan del uso de
procedimientos y herramientas apropiados para implementar el sistema de calidad. Nos podemos encontrar con
algunos ejemplos en el IEEE 730.
• Compra / Productos de software incluidos: Los requerimientos que rigen las compras del proveedor de los
vendedores se encuentran en estas dos cláusulas.
• Formación: La única mención que se realiza en los estándares del IEEE, se encuentra en el estándar 730.
6.1.4 ISO/IEC 9126
ISO/IEC 9126 define 6 características para la calidad interna y la externa, Funcionalidad, Fiabilidad, Usabilidad, Eficiencia,
Mantenibilidad y portabilidad, cada una de estas características está dividida en sub características que nuevamente son útiles
para la calidad interna y externa.
En base a la ISO 9126 existe un paralelismo total entre las características de la calidad interna y externa por lo que se asume las
influencias son de uno a uno (Muñoz, Velthuis, & Rubia, 2010).
Esta norma no obstante, no define el mismo nivel de paralelismo entre calidad externa y calidad en uso por lo que solo define 4
características para la calidad en Uso: Efectividad, productividad, seguridad y satisfacción y éstas no se subdividen.
Para establecer las relaciones entre calidad externa y calidad en uso es necesario tener en cuenta el significado de ambas. De
acuerdo con ISO/ IEC ,2001, la calidad externa, sus características y sub características y la calidad en uso junto con sus
características se definen de la siguiente manera: (Figueroa, 2013)
• Funcionalidad: En este grupo se conjunta una serie de atributos que permiten calificar si un producto de software maneja en
forma adecuada el conjunto de funciones que satisfagan las necesidades para las cuales fue diseñado. Para este propósito se
establecen los siguientes atributos:
o Idoneidad. Se enfoca a evaluar si el software cuenta con un conjunto de funciones apropiadas para efectuar las tareas que
fueron especificadas en su definición.
o Exactitud. Este atributo permite evaluar si el software presenta resultados o efectos acordes a las necesidades para las cuales
fue creado.
o Interoperabilidad. Permite evaluar la habilidad del software de interactuar con otros sistemas previamente especificados.
o Conformidad. Evalúa si el software se adhiere a estándares, convenciones o regulaciones en leyes y prescripciones similares.
o Seguridad. Se refiere a la habilidad de prevenir el acceso no autorizado, ya sea accidental o premeditado, a los programas y
datos
• Confiabilidad. Aquí se agrupan un conjunto de atributos que se refieren a la capacidad del software de mantener su nivel de
ejecución bajo condiciones normales en un periodo de tiempo establecido. Las subcaracterísticas que el estándar sugiere son:
o Nivel de Madurez. Permite medir la frecuencia de falla por errores en el software.
o Tolerancia a fallas. Se refiere a la habilidad de mantener un nivel específico de funcionamiento en caso de fallas del software o
de cometer infracciones de su interfaz específica.
o Recuperación. Se refiere a la capacidad de restablecer el nivel de operación y recobrar los datos que hayan sido afectados
directamente por una falla, así como al tiempo y el esfuerzo necesarios para lograrlo.
o Conformidad. Evalúa si el software se adhiere a estándares, convenciones o regulaciones en leyes y prescripciones referidas a
la confiabilidad.
• Usabilidad. Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario que deberá invertir el usuario para
utilizar el sistema
o Entendibilidad. Se refiere al esfuerzo requerido por los usuarios para reconocer la estructura lógica del sistema y los conceptos
relativos a la aplicación del software.
o Facilidad de Aprendizaje. Establece atributos del software relativos al esfuerzo que los usuarios deben hacer para aprender a
usar la aplicación.
o Operabilidad. Agrupa los conceptos que evalúan la operación y el control del sistema.
o Atractivo: Capacidad del software para atraer al usuario.
o Conformidad. Evalúa si el software se adhiere a estándares, convenciones o regulaciones en leyes y prescripciones referidas a
la usabilidad.
• Eficiencia. Esta característica permite evaluar la relación entre el nivel de funcionamiento del software y la cantidad de recursos
usados. Los aspectos a evaluar son:
o Comportamiento con respecto al Tiempo. Atributos del software relativos a los tiempos de respuesta y de procesamiento de los
datos.
o Comportamiento con respecto a Recursos. Atributos del software relativos a la cantidad de recursos usados y la duración de su
uso en la realización de sus funciones.
o Conformidad. Evalúa si el software se adhiere a estándares, convenciones o regulaciones en leyes y prescripciones referidas a
la eficiencia.
• Mantenibilidad. Se refiere a los atributos que permiten medir el esfuerzo necesario para realizar modificaciones al software, ya
sea por la corrección de errores o por el incremento de funcionalidad. En este caso, se tienen los siguientes factores:
o Capacidad de análisis. Relativo al esfuerzo necesario para diagnosticar las deficiencias o causas de fallas, o para identificar las
partes que deberán ser modificadas.
o Capacidad de modificación. Mide el esfuerzo necesario para modificar aspectos del software, remover fallas o adaptar el
software para que funcione en un ambiente diferente.
o Estabilidad. Permite evaluar los riesgos de efectos inesperados debidos a las modificaciones realizadas al software.
o Facilidad de Prueba. Se refiere al esfuerzo necesario para validar el software una vez que fue modificado.
o Conformidad. Evalúa si el software se adhiere a estándares, convenciones o regulaciones en leyes y prescripciones referidas a
la mantenibilidad.
• Portatilidad. En este caso, se refiere a la habilidad del software de ser transferido de un ambiente a otro, y considera los
siguientes aspectos:
o Adaptabilidad. Evalúa la oportunidad para adaptar el software a diferentes ambientes sin necesidad de aplicarle modificaciones.
o Facilidad de Instalación. Es el esfuerzo necesario para instalar el software en un ambiente determinado.
o Conformidad. Permite evaluar si el software se adhiere a estándares o convenciones relativas a portabilidad.
o Capacidad de reemplazo. Se refiere a la oportunidad y el esfuerzo usado en sustituir el software por otro producto con
funciones similares.
o Conformidad. Evalúa si el software se adhiere a estándares, convenciones o regulaciones en leyes y prescripciones referidas a
la portabilidad.
Por su parte la calidad en uso es la capacidad del producto de software para permitir que los usuarios consigan los objetivos
especificados en eficiencia, productividad, seguridad y satisfacción.
• Eficiencia. La capacidad de producto de software para permitir a los usuarios a conseguir los objetivos establecidos con
precisión y completitud en un contexto de uso especificado.
• Productividad. La capacidad de producto de software para permitir a los usuarios gastar cantidades de recursos apropiados en
relación a la eficiencia conseguida en un contexto de uso específico.
• Seguridad (de uso). La capacidad de producto de software de conseguir niveles aceptables de riesgos de dañar a personas,
software, equipamiento, o al entorno en un contexto determinado.
• Satisfacción. La capacidad de producto de software de satisfacer a los usuarios en un contexto determinado.
6.1.5 ISO/IEC 12207
La norma ISO/IEC 12207 implanta un marco común para los procesos de ciclo de vida de software, estableciendo dentro de estos procesos terminologías bien
definidas que hacen referencia a la industria del software.
Está conformada por procesos, actividades y tareas que se deben aplicar durante la adquisición, suministro, desarrollo, operación, mantenimiento y eliminación
de productos o servicios de software.
La estructura del estándar ha sido concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use. Para conseguirlo, el estándar se
basa en dos principios fundamentales: Modularidad y responsabilidad. Con la modularidad se pretende conseguir procesos con un mínimo acoplamiento y una
máxima cohesión. En cuanto a la responsabilidad, se busca establecer un responsable para cada proceso, facilitando la aplicación del estándar en proyectos
en los que pueden existir distintas personas u organizaciones involucradas, no importando el uso que se le dé a este. (ISO/IEC, 2012)
Los procesos se clasifican en tres tipos: Procesos principales, procesos de soporte y procesos de la organización. Los procesos de soporte y de organización
deben existir independientemente de la organización y del proyecto ejecutado. Los procesos principales se instancian de acuerdo con la situación particular.
La norma ISO/IEC 12207 define 48 procesos del ciclo de vida del software, agrupados en nueve grupos de procesos. La figura 2.3 muestra los procesos
considerados por la norma ISO/IEC 12207, y que son los que utiliza la norma ISO/IEC 15504-5.
Este modelo de procesos agrupa los procesos que se realizan durante el ciclo de vida del software en tres categorías que, a su vez, están compuestas por
grupos de procesos tal y como se describe a continuación: (Calafat, 2012)
xxxxxxxxxxxxxxxxxx
Este estándar internacional establece las actividades y tareas necesarias para identificar, definir, seleccionar, aplicar y mejorar de manera exitosa la
medición de software dentro de un proyecto general o de la estructura de medición de una empresa.
ACTIVIDAD TAREAS
Establecer y mantener el
compromiso de medición
Asignar recursos
La Norma ISO-14598 proporciona un marco de trabajo para evaluar la calidad de todos los tipos de software, indicando los requisitos que serán medidos,
y analizados en este proceso. Implementar estándares que garanticen una correcta evaluación al software y mitigar los errores que pueda presentar cundo
se esté ejecutando. (ISO/IEC 14598)
Como ya hemos visto anteriormente la norma ISO/IEC 9126 define un modelo de calidad de propósito general, describe un conjunto de características de
calidad y brinda ejemplos de métricas. Mientras que la norma ISO/IEC 14598 da una descripción general de los procesos para la evaluación de productos
de software así como también guías y requerimientos para la evaluación. Por esta razón se recomienda su uso conjunto.
A continuación se incluye un esquema que describe la forma en que las diferentes de estas dos normas se podrán utilizar.
Según la norma ISO/IEC 14598, los componentes fundamentales en la evaluación de la calidad del software son:
• Modelo de calidad
• Método de evaluación
• Medidas de software
• Herramientas de soporte
Para el desarrollo de un producto de software correcto, deben especificarse los requerimientos de calidad para poder medirlos de alguna forma. Además
se debe planear, implementar, y controlar el proceso para el aseguramiento de la calidad. Se deberán evaluar tanto los productos intermedios como los
finales.
Dependiendo de la etapa en el ciclo de vida que nos encontremos, y el propósito de la evaluación, se determinarán que productos (intermedios o finales)
serán evaluados.
La serie de estándares ISO/IEC 14598 brinda un conjunto de métodos para la medición y evaluación de la calidad de un producto de software.
Es importante tener en cuenta que no describe métodos para la evaluación de los procesos de desarrollo del software ni métodos para la predicción de
costos. Para ello se pueden utilizar las mediciones de la calidad del software
Esta norma está compuesta de las siguientes partes con el título “Tecnología de la Información – Evaluación de Productos de Software” (ISO/IEC 14598)
Dicho proceso a través de todas sus etapas, promueve las siguientes características de proceso:
o Repetible: Que el proceso bajo las mismas circunstancias, la misma configuración de las herramientas utilizadas, el mismo producto y el mismo
evaluador, la evaluación obtenga el mismo resultado.
o Reproducible: Es muy parecido a repetible pero no es lo mismo, ya que en este caso deben mantenerse todas las condiciones iguales, salvo que el
evaluador sea otro y en este caso también se debe obtener el mismo resultado.
o Imparcial: La evaluación debe resultar de los estudios realizados en esa instancia y no deben estar influídos por resultados anteriores obtenidos para
realizar la misma evaluación.
o Objetivo: El evaluador no debe influenciarse por sentimientos propios o prejuicios sobre el producto u similares.
El proceso consta de 5 etapas:
1. Establecimiento de los Requerimientos
2. Especificación de la Evaluación
3. Diseño de la Evaluación
4. Ejecución de la Evaluación
5. Conclusión de la Evaluación
6.1.8 ISO/IEC 15504-SPICE
ISO/IEC 15504 Information technology – Process assessment, también denominado SPICE (Software Process
Improvement and Capability dEtermination), es un estándar internacional que es aplicable a cualquier organización
que quiera conocer y mejorar la capacidad de sus procesos, independientemente del tipo de organización. Su
modelo bidimensional, caracterizado por una dimensión de procesos y una dimensión de capacidad, ofrece una
base para la evaluación de la capacidad de los procesos y permite reflejar los resultados obtenidos sobre una
escala común, que puede usarse tanto para comprobar la evolución de una organización en el tiempo como para
definir estrategias de mejora continua.
ISO/IEC 15504 no pretende fijar la manera de realizar los procesos en una organización, sino que valora su
capacidad y ayuda a proponer medidas para aumentarla.
Este estándar no indica en ningún momento en qué orden y de qué forma deben llevarse a cabo los procesos, se
limita a definirlos y a caracterizarlos.
En el estándar ISO/IEC 15504, la dimensión de procesos viene representada por un Modelo de Referencia de
Procesos (PRM, Process Reference Model) externo que define un conjunto de procesos caracterizados según su
propósito y las salidas que generan. Para realizar una evaluación de procesos conforme con la norma ISO/IEC
15504-2 (parte normativa), se debe definir un Modelo de Evaluación de Procesos (PAM, Process
Assessment Model) basado en un determinado PRM, que satisfaga los requisitos definidos en esta parte.
Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Define que todo modelo
de evaluación de procesos debe definir: - la dimensión de procesos: el modelo de procesos de referencia
(dimensión de las abscisas) - la dimensión de la capacidad: niveles de capacidad y atributos de los procesos. Los
niveles de capacidad para todo modelo de evaluación de procesos pueden tener desde el 0 y al menos hasta el
nivel 1 de los siguientes niveles de capacidad estándar:
o Nivel 0: Incompleto
o Nivel 1: Realizado
o Nivel 2: Gestionado
o Nivel 3: Establecido
o Nivel 4: Predecible
o Nivel 5: En optimización
Para cada nivel existen unos atributos de procesos estándar que ayudan a evaluar los niveles de capacidad.
6.1.8.1 La dimensión de capacidad
La dimensión de capacidad define una escala de valoración para medir la capacidad de los procesos que consta de
seis niveles, desde el nivel 0 hasta el nivel 5, y que se muestran en la tabla. (Calafat, 2012)
Asegurar y reproducir calidad de forma fiable requiere de procesos bien definidos cuya aplicabilidad posterior debe,
además, quedar garantizada. Hoy en día, la satisfacción del cliente y la productividad requieren agilidad, es decir,
que en el transcurso de un proyecto se puedan incorporar nuevas conclusiones o requerimientos para potenciar la
usabilidad hacia el cliente. Combinando control y libertad en su justa medida, se puede aplicar lo primero sin perder
lo segundo. El objeto de este artículo es mostrarle precisamente eso: cómo combinar ambos enfoques en la
implantación de su Sistema de Control de Calidad para crear un valor añadido, tanto para el cliente, como para sí
mismo. La calidad del software, cómo producirla y garantizarla, es una cuestión tan importante como compleja.
Podemos hallar la respuesta a dicha duda en varios niveles. (Jenni, Perriard, & Wandfluh, 2014)
No es fácil desarrollar con éxito sistemas de software para clientes si se tiene en cuenta el hecho de que, al
comienzo del proyecto ni el fabricante, ni el cliente saben cómo debe quedar el producto final. Dado que al
implementar un nuevo sistema de software a menudo también cambian los procesos, aumenta el riesgo de crear un
sistema que no cumple con las expectativas.
Una posible solución a esta problemática se ha formulado en el Manifiesto por el Desarrollo Ágil Este sistema de
valores pone énfasis en las personas y en su colaboración, en software que funcione y en las necesidades del
cliente, aunque éstas cambien. Pronto uno se da cuenta de que se trata de algo más que ser amable con el otro y
desarrollar software conjuntamente. Para emplear efectivamente esta ideología se han elaborado diversos modelos
de procedimiento ágiles, y uno de ellos es Scrum.
Scrum aborda las dificultades antes mencionadas con tan solo unas pocas y sencillas reglas, define unos pocos
roles repartiendo las tareas de manera clara y describe algunos artefactos que se cumplimentan, además del
trabajo en equipo, ya sea en reuniones o ad hoc. Para una descripción detallada de Scrum.
Scrum es un marco de trabajo por el cual las personas pueden acometer problemas complejos adaptativos, a la vez
que entregar productos del máximo valor posible productiva y creativamente. Scrum es:
Ligero
Fácil de entender
Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de productos complejos
desde principios de los años 90. Scrum no es un proceso o una técnica para construir productos; en lugar de eso,
es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos. Scrum muestra la eficacia
relativa de las prácticas de gestión de producto y las prácticas de desarrollo, de modo que podamos mejorar.
El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos, artefactos y reglas asociadas. Cada
componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y para
su uso.
Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las relaciones e interacciones entre
ellos.
Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento
procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque
iterativo e incremental para optimizar la predictibilidad y el control del riesgo.
Tres pilares soportan toda la implementación del control de procesos empírico: transparencia, inspección y
adaptación. (ScrumInc, 2015)
Transparencia: Los aspectos significativos del proceso deben ser visibles para aquellos que son
responsables del resultado. La transparencia requiere que dichos aspectos sean definidos por un estándar
común, de tal modo que los observadores compartan un entendimiento común de lo que se está viendo.
Inspección: os usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso
hacia un objetivo, para detectar variaciones. Su inspección no debe ser tan frecuente como para que
interfiera en el trabajo. Las inspecciones son más beneficiosas cuando se realizan de forma diligente por
inspectores expertos, en el mismo lugar de trabajo.
Adaptación: Si un inspector determina que uno o más aspectos de un proceso se desvían de límites
aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo
procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones
mayores.
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación, tal y como
se describen en la sección Eventos de Scrum del presente documento.
El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo (Development Team)
y un Scrum Master. Los Equipos Scrum son autoorganizados y multifuncionales. Los equipos autoorganizados
eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. Los equipos
multifuncionales tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras
personas que no son parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la
creatividad y la productividad.
Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener
retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible
una versión potencialmente útil y funcional del producto.
El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.
El cómo se lleva a cabo esto podría variar ampliamente entre distintas organizaciones, Equipos Scrum e individuos.
El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog). La
gestión de la Lista del Producto incluye:
Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera
posible;
Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que muestra aquello en lo
que el equipo trabajará a continuación; y,
Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
El Dueño de Producto podría hacer el trabajo anterior, o delegarlo en el Equipo de Desarrollo. Sin embargo, en
ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo.
El Dueño de Producto es una única persona, no un comité. El Dueño de Producto podría representar los deseos de
un comité en la Lista del Producto, pero aquellos que quieran cambiar la prioridad de un elemento de la Lista deben
hacerlo a través del Dueño de Producto.
Para que el Dueño de Producto pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones. Las
decisiones del Dueño de Producto se reflejan en el contenido y en la priorización de la Lista del Producto. No está
permitido que nadie pida al Equipo de Desarrollo que trabaje con base en un conjunto diferente de requerimientos, y
el Equipo de Desarrollo no debe actuar con base en lo que diga cualquier otra persona.
El Equipo de Desarrollo consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de
producto “Terminado”, que potencialmente se pueda poner en producción, al final de cada Sprint. Solo los miembros
del Equipo de Desarrollo participan en la creación del Incremento.
Los Equipos de Desarrollo son estructurados y empoderados por la organización para organizar y gestionar su
propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del Equipo de Desarrollo.
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir
elementos de la Lista del Producto en Incrementos de funcionalidad potencialmente desplegables;
Los Equipos de Desarrollo son multifuncionales, contando como equipo con todas las habilidades necesarias
para crear un Incremento de producto;
Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores,
independientemente del trabajo que realice cada persona; no hay excepciones a esta regla;
Scrum no reconoce sub-equipos en los equipos de desarrollo, no importan los dominios particulares que
requieran ser tenidos en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla; y,
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las
que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo.
El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas
al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum
Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no
definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen una
duración máxima. Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás
eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad
apropiada de tiempo sin permitir desperdicio en el proceso.
Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de Scrum constituye
una oportunidad formal para la inspección y adaptación de algún aspecto. Estos eventos están diseñados
específicamente para habilitar las vitales transparencia e inspección. La falta de alguno de estos eventos da como
resultado una reducción de la transparencia y constituye una oportunidad perdida para inspeccionar y adaptarse.
El trabajo a realizar durante el Sprint se planifica en la Reunión de Planificación de Sprint. Este plan se crea
mediante el trabajo colaborativo del Equipo Scrum completo.
La Reunión de Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un mes. Para
Sprints más cortos, el evento es usualmente más corto. El Scrum Master se asegura de que el evento se lleve a
cabo y que los asistentes entiendan su propósito. El Scrum Master enseña al Equipo Scrum a mantenerse dentro
del bloque de tiempo.
Como toda metodología que busca la continua mejora de procesos; al igual que el PSP, el TSP posee fases que
nos ayudarán a mejorar la planificación, gestión y calidad de nuestro proyecto.
Lanzamiento
En esta etapa se establecen las metas a seguir por parte del equipo, se evalúan los objetivos y se dictan los roles y
responsabilidades por parte de cada uno de los miembros del equipo. Además se toman en cuenta los
requerimientos por parte del cliente y se arma la estrategia a seguir para la culminación del proyecto.
Estrategia
En esta etapa se crea un modelo conceptual de lo que se requiere para brindar la solución más óptima,
estableciendo el desarrollo a seguir, así como las estimaciones de esfuerzo y de riesgos.
Planeación
Una vez desarrollada la estrategia y teniendo en cuenta los procedimientos a seguir y el modelo de la solución del
producto, se procede a brindar los roles y las tareas a cada miembro del grupo. En esta etapa se establece el
cronograma para la gestión del tiempo y de las tareas que deben de realizarse.
Requerimientos
Para la gestión de los requerimientos se establecen entrevistas con el cliente a fin de delimitar lo que realmente es
necesario producir. Los requerimientos son inspeccionados, con el fin de desarrollar un plan de pruebas para el
producto terminado.
Diseño
Dentro de las tareas de la etapa de diseño, se establece la elaboración de un diseño de alto nivel, especificando
todo los detalles acera de todos los procesos del producto. En esta fase se desarrolla un plan de pruebas de
integración.
Implementación
Esta es la fase en la cual el diseño se pasa a nivel de código, se analiza y se hace una revisión exhaustiva en busca
de errores. Se compilan y se ejecutan los módulos y unidades, al tiempo que se analiza la calidad de estos.
Pruebas
En esta etapa el producto ya casi está terminado, solo falta la integración de los módulos y la documentación para
el usuario final, como lo son los manuales de uso. En esta etapa e presentan las diferentes pruebas al sistema con
el fin de asegurar su calidad y evaluar el desempeño del equipo de trabajo.
Postmorten
Se evalúan los análisis de los resultados de las diferentes pruebas y del desempeño del equipo. Se escribe con
detalles el reporte del ciclo de vida del proyecto.
6.4 SQuaRE
La calidad del producto, junto con la calidad del proceso, es uno de los aspectos más importantes actualmente en el
desarrollo de Software. Relacionada con la calidad del producto, recientemente ha aparecido la familia de normas
ISO/IEC 25000, que proporciona una guía para el uso de la nueva serie de estándares internacionales llamada
Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE - System and Software Quality
Requirements and Evaluation).
ISO/IEC 25000 constituye una serie de normas basadas en ISO/IEC 9126 y en ISO/IEC 14598 cuyo objetivo
principal es guiar el desarrollo de los productos de software mediante la especificación de requisitos y evaluación de
características de calidad (ISO.ORG, 2015)
ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and Evaluation), es una
familia de normas que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad del
producto software.
La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores, especialmente de las normas
ISO/IEC 9126, que describe las particularidades de un modelo de calidad del producto software, e ISO/IEC 14598,
que abordaba el proceso de evaluación de productos software. Esta familia de normas ISO/IEC 25000 se encuentra
compuesta por cinco divisiones (ISO.ORG, 2015)
Conociendo estas limitaciones, el ingeniero y físico Watts S. Humprey creó esta metodología con el fin de sufragar
los aspectos que quedaban inconclusos por parte de otras metodologías en la evaluación y mejora de procesos. El
TSP acopla los principios de los equipos de producto integrados con los métodos de PSP y el modelo CMM, con el
fin de producir equipos efectivos de trabajo. (GuitaMar Soluciones, 2012)
Como se mencionó anteriormente, el TSP trabaja en base a la conformación de equipos de trabajo, pero esta forma
de laborar no debe de ser tomada a la ligera. Se necesita una planificación de los equipos de trabajo para
establecer los roles y las responsabilidades, ya que muchos de los proyectos fallan debido a que los grupos de
trabajo se concentran en resolver problemas de manejo de equipos y no en las tareas fundamentales del proyecto.
Para ello el TSP se sustenta en el PSP para crear profesionales con cualidades actas para la realización de
proyectos muy grandes, dentro de este marco se incluyen los aspectos de generar planes detallados, reunir y usar
datos de procesos, medir y gestionar la calidad del producto y definir y usar procesos operacionales. (GuitaMar
Soluciones, 2012)
Preguntas de análisis
Después de haber leído los contenidos explicados anteriormente, quizás te estas preguntando
lo siguiente:
¿Considera importante el estándar ISO/IEC para obtener una mejor calidad de software?
1. ¿Cuál es su opinión con respecto al uso de estándares en las empresas de desarrollo de software
nacionales?
Al respecto para conocer un poco más sobre este tema, y dar respuesta a las preguntas planteadas a continuación
te invitamos a leer analíticamente la siguiente lectura.
h p://dis.unal.edu.co/~icasta/consejero/psp.pdf
Bibliografía
A., F., A., F., C, M., & J.C., D. (2012). Software Process:
Principals, Methodology and Technology.
ISO/IEC. (2012). Systems and software engineering —Software life cycle processes. Std 12207-2008.
Jenni, J., Perriard, M., & Wandfluh, S. (2014). Compatibilidad entre Scrum y CMMI: con agilidad hacia el nivel 5 de
CMMI. mimacom, 1-5.
MORENO, J. J., BOLAÑOS, L. P., & NAVIA, M. A. (2010). Exploración de Modelos y Estándares de Calidad Para el
Producto Software. UIS Ingenierías, 39-53.
Muñoz, C. C., Velthuis, M. G., & Rubia, M. Á. (2010). Calidad del producto y proceso software. Madrid: RAMA.
VALENCIA, L. S., VILLA, P. A., & OCAMPO, C. A. (2009). Model of software quality. DIALNET, 172-176.
Documento 3: A model for assessing information technology effectiveness in the business environment
URL: http://search.proquest.com/docview/1677615487?accountid=39560
Breve descripción:
Éste documento nos proporciona como resultado, en primer lugar, lineamientos necesarios para identificar el grado
de efectividad de la TI en el entorno empresarial, y en segundo lugar, estrategias fundamentales dentro del proceso
de innovación tecnológica que coexiste en el momento empresarial; además este estudio se fundamenta en
normativas como: ISO 9126, ISO 9001, ISO 15939, ISO 25000 y estándares como el Cobit, CMM, entre otros.
Conclusiones