Tema 06: Agrupemos las normas ISO/IEC según la calidad y el

proceso de desarrollo del software

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

Conozcamos ahora las capacidades y actitudes a

desarrollar en este primer tema:
Capacidad

Analiza el las normas ISO / IEC de Calidad de

Software.
Aplica las normas ISO/IEC, IT MARK , SCRUM,
SQuaRE, CISQ

Actitudes

• Reflexiona sobre las normas de calidad de

software.
• Valora la importancia de las normas de calidad de
software.
• Critica de manera constructiva los procesos de
desarrollo de software en nuestro medio.
Mapa conceptual referido al tema
Observa detenidamente el siguiente esquema, en el encontrarás de un “vistazo” de manera sintetizada los principales concepto
de la temática que abordaremos. ¿Qué conceptos o categorías te llaman la atención?
 6.1 NORMAS ISO.

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.

• CLAUSULAS ESPECIFICAS DEL ISO 9000-3:

La ISO 9000-3 es una guía que está formada por una serie de cláusulas que indican como aplicar esta guía.

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)

• Categoría de procesos Principales. Contiene los siguientes grupos de procesos:

o Adquisición (ACQ). Son los procesos que realiza el cliente para la adquisición de un producto o servicio.
o Suministro (SPL). Abarca los procesos realizados por el proveedor tanto en la propuesta como en la entrega de un producto o servicio.
o Ingeniería (ENG). Agrupa a los procesos que directamente especifican, implementan o mantienen el producto software, su relación con el sistema y la
documentación del cliente.
o Operación (OPE). Describe los procesos directamente relacionados con la transición del producto o servicio al cliente, y se ocupan del correcto uso y
operación del mismo.
• Categoría de procesos de soporte. Formada por un único grupo de procesos:
o Soporte (SUP). Contiene los procesos que pueden ser utilizados por cualquiera de los otros procesos incluyendo a la vez otros procesos de soporte, en
determinadas partes o aspectos del ciclo de vida del software.
• Categoría de procesos de la organización. Agrupa los siguientes grupos de procesos:
o Gestión (MAN). Está formada por los procesos que contienen prácticas que pueden ser utilizadas por cualquiera que gestione cualquier tipo de proyecto o de
proceso del ciclo de vida del software.
o Mejora del proceso (PIM). Está formada por los procesos que establecen, definen, despliegan e implantan, evalúan y mejoran los procesos que se realizan
en la organización.
o Recursos e Infraestructura (RIN). Describe los procesos que se realizan para dotar a la organización tanto de los recursos humanos, como de la
infraestructura necesaria para que los otros procesos puedan realizarse de manera apropiada.
o Reutilización (REU). Contiene los procesos directamente relacionados con la realización de acciones destinadas a explotar las oportunidades de reutilización.
 6.1.6 ISO/IEC 15939

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

Aceptar los requisitos de medición.

Establecer y mantener el
compromiso de medición
Asignar recursos

Planificar el proceso de Obtener características de la organización

medición.

Identificar las necesidades de información.

Seleccionar las medidas.

Definir los procedimientos de recolección de datos,

análisis e informes.

Definir los criterios de evaluación de los productos

de información y el proceso de medición.

Revisar, aprobar y proporcionar recursos para las

tareas de medición

Adquirir y utilizar tecnología de apoyo

Realizar el proceso de medición. Integrar los procedimientos

Recoger los datos

 Analizar los datos y desarrollar productos de
información

Comunicar los resultados.

Evaluar la medición. Evaluar los productos de información y el proceso

de medición

Identificar las mejoras potenciales.

 6.1.7 ISO/IEC 14598

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)

o Parte 1. Descripción General

Brinda una idea general sobre las partes que constituyen la norma. Explica la relación que existe entre las normas ISO/IEC 14598 e ISO/IEC 9126.
Da definiciones de los términos que utiliza y brinda un marco para evaluar la calidad de todo tipo de producto de software y establece los requerimientos
para los métodos de medición y evaluación de dichos productos.
Esta norma está dirigida a Desarrolladores, Adquirientes y Evaluadores independientes, sobre todo aquellos que son responsables par a la evaluación del
producto de software.
Los resultados obtenidos de aplicar esta norma pueden ser utilizados por:
o Gerentes y Desarrolladores para medir el cumplimiento de los requerimientos y realizar mejoras si es necesario.
o Analistas para establecer relaciones entre métricas internas y externas.
o Personal a cargo de la mejora de procesos para determinar cómo mejorar los procesos a través del estudio de la información sobre la calidad de los
productos de software del proyecto.

o Parte 2. Planificación y Gerenciamiento.

Esta parte brinda detalles sobre la planificación y gestión de los requerimientos asociados con la evaluación del producto de software. Tiene como objetivo
explicar los requerimientos que deben ser brindados por una organización para asegurarse el éxito de la evaluación. Esta función de soporte puede ser
parte de la organización.
En otras palabras, describe los requerimientos, recomendaciones y guías para la función de soporte que es responsable de la gestión de la evaluación de
un producto de software, así como también de las tecnologías necesarias para llevarla a cabo.
El soporte está relacionado con la planificación y gestión del proceso de evaluación de software y actividades asociadas.
Esta parte de la norma, está dirigida a las personas que son responsables de:
o Administrar el uso de la tecnología para la evaluación
o Dar soporte en la Evaluación del Software
o Gestionar organizaciones de desarrollo de software
También para las personas que desempeñan tareas de Aseguramiento de la calidad.
El rol principal de la función de soporte es:
o adquirir estándares nacionales e internacionales
o desarrollar estándares apropiados y herramientas basándose en las necesidades de lao organización
o desarrollar criterios para determinar marcos para la evaluación
o colectar los resultados de la evaluación y difundirlos en la empresa
La función de soporte puede ser interna o externa a la organización. A su vez si es interna, puede estar o no dentro del departamento que realiza la
evaluación del producto.
La organización debe crear políticas y un plan para desarrollar todas las actividades de
evaluación. Esta norma brinda un template para documentar el Plan de Evaluación.

o Parte 3. Proceso para Desarrolladores

Debe ser utilizado por organizaciones que planean desarrollar un producto nuevo o mejorar uno existente, y quieren realizar evaluaciones de su producto,
utilizando los miembros de su propio personal técnico. Se hace hincapié en el uso de indicadores que pueden predecir la calidad de los productos finales,
midiendo los productos intermedios desarrollados a lo largo del ciclo de vida.

o Parte 4. Proceso para Adquirientes.

Debe ser utilizado por organizaciones que planean comprar o rehusar un producto de software existente o ya desarrollado. Puede aplicarse con el
propósito de decidir sobre la aceptación de un producto o para seleccionar un producto entre un conjunto de productos alternativos.

o Parte 5. Proceso para Evaluadores.

El estándar define el proceso con sus respectivas actividades y entregables. Este proceso apunta a ser utilizado por laboratorios evaluadores, los cuales
con este proceso podrían brindar servicios de evaluación a otras empresas. Empresas desarrolladoras de software, las que podrían tener un laboratorio de
evaluación propio, el cual manteniendo la suficiente independencia, podría lograr los mismos resultados. Adquirientes de software los cuales conociendo el
estándar podrían dado un producto que quieren adquirir, poder contratar una institución evaluadora que realice una evaluación, y así poder determinar en
base a su calidad si comprarlo o no, o decidir entre varios, cual comprar. Usuarios de un producto los cuales podrían dado un informe de evaluación, poder
determinar si la calidad del producto satisface sus requerimientos. Y en el caso de entidades certificadoras, podrían utilizar el estándar para realizar
normas de calidad de productos.

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)

Cada nivel dentro de esta

Escala Descripción escala está caracterizado por
unos atributos de proceso
Nivel 0 El proceso no existe o no se consigue su propósito. No pueden (PA,Process Attribute), cada
identificarse los productos o salidas del proceso. uno de los cuales valora un
Incompleto aspecto particular de la
capacidad del proceso.
Dependiendo de los valores
de estos atributos alcanzados
Nivel 1 Se alcanza el propósito del proceso en términos generales. El
por un proceso, éste se
personal de la organización reconoce que el proceso se realiza
Realizado encontrará en una u otra
cuando es necesario, pero no se hace de una forma
posición de la escala. La tabla
planificada ni se realiza ningún seguimiento. Las salidas del
que se muestra a continuación
proceso se identifican fácilmente y este hecho confirma que el
contiene los nueve atributos
proceso se realiza.
considerados por el estándar.
Estos atributos vienen
identificados por las siglas PA
seguidas de dos números que
Nivel 2 Se obtienen los productos del proceso, pero esta vez, de
indican el nivel de capacidad y
acuerdo con una planificación y realizándose un seguimiento.
Gestionado el número de atributo dentro
Estos productos se ajustan a unos estándares y a unas
de un mismo nivel,
especificaciones de requisitos prefijadas.
respectivamente. (Calafat,
También se tienen definidos plazos y recursos. La principal 2012)
diferencia con un proceso de nivel 1 es que, en este caso, se
Para determinar si un proceso
generan productos que cumplen completamente con los
cumple un determinado nivel
requisitos de calidad y lo hacen dentro de los plazos de tiempo
de capacidad es necesario
y con los recursos establecidos.
calcular el porcentaje de
cumplimiento de los atributos
que identifican el nivel
considerado. La escala de
Nivel 3 El proceso se realiza y se gestiona utilizando procedimientos valoración de los atributos se
definidos según los principios de la Ingeniería del Software. compone de cuatro valores tal
Establecido Cada implementación de un proceso se hace utilizando y como se muestra en la tabla
procedimientos creados según un estándar y debidamente que se muestra a
documentados. Además, se dispone de los recursos continuación. El estándar
necesarios para alcanzar los propósitos establecidos. obliga a evaluar empezando
desde el nivel 1 y, solamente
La principal diferencia con el nivel 2 es que se utiliza un
en el caso de que los atributos
proceso definido y con capacidad para alcanzar los resultados
de un determinado nivel sean
esperados.
ampliamente o
completamente alcanzados,
se permite la evaluación de un
nivel superior.
Nivel 4 La realización del proceso se gestiona de forma cuantitativa,
es decir, se recogen medidas detalladas del nivel de
Predecible realización del proceso y se analizan. Esto permite mantener el
 proceso dentro de unos límites predefinidos, así como disponer
de una mejor posición para poder cuantificar la capacidad del
proceso y predecir su comportamiento. La principal diferencia
con el nivel 3 es que ahora el proceso se lleva a término de
manera consistente dentro de unos límites predefinidos.

Nivel 5 La realización de un proceso se optimiza de forma continuada

para que contribuya a alcanzar los objetivos de negocio de la
En optimización organización. Se establecen objetivos cuantitativos de eficacia
y eficiencia en la realización de los procesos, basados en los
objetivos de negocio de la organización. Se lleva a cabo una
supervisión continua de los procesos y se analizan los datos
obtenidos. Esto permite que los procesos estándares definidos
dentro de la organización cambien dinámicamente, para
adaptarse de forma efectiva a los actuales y futuros objetivos
de la empresa. La principal diferencia con el nivel 4, es que
ahora los procesos, definidos y estandarizados, cambian de
manera dinámica, y se adaptan para satisfacer con eficacia los
objetivos actuales y futuros del negocio.

Dimensión de capacidad de ISO/IEC 15504

Nivel Atributo (PA) Descripción

0 No hay atributos en este nivel

1 Realización del proceso Representa la medida de cuánto se alcanza

el propósito de un proceso, transformando
(PA.1.1) los productos de entrada en productos de
salida.

2 Gestión de la Representa el grado de gestión de la

realización del proceso, para que se
realización obtengan productos que cumplan los
objetivos definidos.
(PA.2.1)

Gestión de los productos Representa el grado de gestión de los

resultantes productos resultantes producidos por los
procesos.
(PA.2.2)
3 Definición del proceso
(PA.3.1)
Representa el nivel de realización del
proceso, según el cual, el proceso utiliza
una definición de proceso basada en un
proceso estándar para conseguir sus
objetivos.

Implantación del proceso Representa el nivel de adecuación de la

implantación o despliegue efectivo del
(PA.3.2) proceso estándar.

4 Medida del proceso Representa el nivel en el que las medidas y

los objetivos de los productos y de los
(PA.4.1) procesos son utilizados para asegurar que
la realización del proceso soporte el alcance
de los objetivos definidos como apoyo a los
objetivos de negocio.

Control del proceso Representa el nivel de control del proceso a

través de la recopilación, análisis y uso de
(PA.4.2) medidas de proceso y de producto, para
corregir, en caso necesario, el rendimiento
del proceso para conseguir los objetivos de
proceso y de producto definidos.

5 Innovación del proceso Representa el nivel de control de los

cambios en la definición, gestión y
(PA.5.1) realización del proceso, con el fin de
alcanzar los objetivos de negocio fijados en
la organización.

Optimización del proceso Representa el nivel bajo el cual se

identifican e implantan los cambios en los
(PA.5.2) procesos, para conseguir una mejora
continua en el cumplimiento de los objetivos
de negocio de la organización.

Atributos de proceso asociados a los niveles de capacidad de ISO/IEC 15504

Situación para determinar el grado de

Valores posibles del Grado de alcance del atributo
atributo cumplimiento

N No alcanzado 0% - 15% Indica una poca o nula evidencia de

que se ha alcanzado este atributo en
el proceso evaluado.

P Parcialmente 16% - 50% Se evidencia una aproximación

sistemática del alcance del atributo,
alcanzado pero algunas de sus características
no se dan.

L Ampliamente 51% - 85% Hay bastantes evidencias de que se

alcanza el atributo, pero la realización
alcanzado del proceso diverge en alguna área.

F Completamente 86% - 100% Hay evidencia de que el atributo se

alcanza plenamente y de manera
alcanzado sistemática en el proceso evaluado y
no hay debilidades importantes en la
unidad organizacional en la que se
ubica el proceso.

Escala de valoración de los atributos de proceso según ISO/IEC 15504

 6.2 IT Mark

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

Extremadamente difícil de llegar a dominar

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.

Reunión de Planificación del Sprint (Sprint Planning Meeting)

Scrum Diario (Daily Scrum)

Revisión del Sprint (Sprint Review)

Retrospectiva del Sprint (Sprint Retrospective)

El Equipo Scrum (Scrum Team) (ScrumInc, 2015)

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 (Product Owner) (ScrumInc, 2015)

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:

Expresar claramente los elementos de la Lista del Producto;

Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera
posible;

Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo;

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 (Development Team) (ScrumInc, 2015)

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.

Los Equipos de Desarrollo tienen las siguientes características:

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 (ScrumInc, 2015)

El Scrum Master es el responsable de asegurar que Scrum es entendido y adoptado. Los Scrum Masters hacen
esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum.

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.

Eventos de Scrum (ScrumInc, 2015)

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.

Reunión de Planificación de Sprint (Sprint Planning Meeting) (ScrumInc, 2015)

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.

La Reunión de Planificación de Sprint responde a las siguientes preguntas:

¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?

¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?

 5.2.2 Metodología

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.

(Guitamar Soluciones,2012) conceptualiza cada fase del TSP como:

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)

• ISO/IEC 2500n – División de Gestión de Calidad (ISO.ORG, 2015)

Las normas que forman este apartado definen todos los modelos, términos y definiciones comunes referenciados
por todas las otras normas de la familia 25000. Actualmente esta división se encuentra formada por:
ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la arquitectura de SQuaRE, la terminología de la familia,
un resumen de las partes, los usuarios previstos y las partes asociadas, así como los modelos de referencia.
ISO/IEC 25001 - Planning and Management: establece los requisitos y orientaciones para gestionar la evaluación y
especificación de los requisitos del producto software.

• ISO/IEC 2501n – División de Modelo de Calidad

Las normas de este apartado presentan modelos de calidad detallados incluyendo características para calidad
interna, externa y en uso del producto software. Actualmente esta división se encuentra formada por:
ISO/IEC 25010 - System and software quality models: describe el modelo de calidad para el producto software y
para la calidad en uso. Esta Norma presenta las características y subcaracterísticas de calidad frente a las cuales
evaluar el producto software.
ISO/IEC 25012 - Data Quality model: define un modelo general para la calidad de los datos, aplicable a aquellos
datos que se encuentran almacenados de manera estructurada y forman parte de un Sistema de Información.

• ISO/IEC 2502n – División de Medición de Calidad

Estas normas incluyen un modelo de referencia de la medición de la calidad del producto, definiciones de medidas
de calidad (interna, externa y en uso) y guías prácticas para su aplicación. Actualmente esta división se encuentra
formada por:
ISO/IEC 25020 - Measurement reference model and guide: presenta una explicación introductoria y un modelo de
referencia común a los elementos de medición de la calidad. También proporciona una guía para que los usuarios
seleccionen o desarrollen y apliquen medidas propuestas por normas ISO.
ISO/IEC 25021 - Quality measure elements: define y especifica un conjunto recomendado de métricas base y
derivadas que puedan ser usadas a lo largo de todo el ciclo de vida del desarrollo software.
ISO/IEC 25022 - Measurement of quality in use: define específicamente las métricas para realizar la medición de
la calidad en uso del producto.
ISO/IEC 25023 - Measurement of system and software product quality: define específicamente las métricas para
realizar la medición de la calidad de productos y sistemas software.
ISO/IEC 25024 - Measurement of data quality: define específicamente las métricas para realizar la medición de la
calidad de datos.
• ISO/IEC 2503n – División de Requisitos de Calidad
Las normas que forman este apartado ayudan a especificar requisitos de calidad que pueden ser utilizados en el
proceso de elicitación de requisitos de calidad del producto software a desarrollar o como entrada del proceso de
evaluación. Para ello, este apartado se compone de:
ISO/IEC 25030 - Quality requirements: provee de un conjunto de recomendaciones para realizar la especificación
de los requisitos de calidad del producto software.

• ISO/IEC 2504n – División de Evaluación de Calidad

Este apartado incluye normas que proporcionan requisitos, recomendaciones y guías para llevar a cabo el proceso
de evaluación del producto software. Esta división se encuentra formada por:
ISO/IEC 25040 - Evaluation reference model and guide: propone un modelo de referencia general para la
evaluación, que considera las entradas al proceso de evaluación, las restricciones y los recursos necesarios para
obtener las correspondientes salidas.
ISO/IEC 25041 - Evaluation guide for developers, acquirers and independent evaluators: describe los requisitos y
recomendaciones para la implementación práctica de la evaluación del producto software desde el punto de vista de
los desarrolladores, de los adquirentes y de los evaluadores independientes.
ISO/IEC 25042 - Evaluation modules: define lo que la Norma considera un módulo de evaluación y la
documentación, estructura y contenido que se debe utilizar a la hora de definir uno de estos módulos.
ISO/IEC 25045 - Evaluation module for recoverability: define un módulo para la evaluación de la subcaracterística
Recuperabilidad (Recoverability).

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?

¿Por qué recomendaría el uso de estándares ISO/IEC en la industria de Software?

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.

Calafat, A. L. (2012). Un Modelo para Facilitar la

Integración de Estándares de Gestión de TI en
Entornos Maduros. Palma: Universitat de les Illes
Balears.

Figueroa, M. A. (2013). Calidad en la Industria del

Software. La Norma ISO-9126. Instituto Tecnológico y
de Estudios Superiores de Monterrey.

ISO.ORG. (10 de setiembre de 2015).

http://www.iso.org/iso/home/about.htm. Obtenido de
http://www.iso.org/iso/home/about.htm:
http://www.iso.org/iso/home/about.htm

ISO/IEC 14598. (s.f.). Norma ISO/IEC 14598.

ISO/IEC. (2012). Systems and software engineering —Software life cycle processes. Std 12207-2008.

iso25000. (10 de Setiembre de 2015). http://iso25000.com/. Obtenido de http://iso25000.com/: http://iso25000.com/

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.

ScrumInc, ©. S. (11 de setiembre de 2015). ©2014 Scrum.Org and ScrumInc. Obtenido de

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf

VALENCIA, L. S., VILLA, P. A., & OCAMPO, C. A. (2009). Model of software quality. DIALNET, 172-176.

www.inlac.org. (21 de marzo de 2015). www.inlac.org. Obtenido de www.inlac.org

 Lecturas recomendadas

Documento 2: Revisión Sistemática sobre la Certificación del Producto Software

URL: http://search.ebscohost.com/login.aspx?direct=true&db=iih&AN=82744619&lang=es&site=ehost-live
Breve descripción:
Éste documento nos muestra la revisión sistemática tiene que por objetivo identificar las iniciativas existentes sobre
la certificación de los productos software, las características que presentan y el estado de madurez en su
aplicación..

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

Scrumm y otras formas de desarrollo ágil alienado a un

adecuado modelo de calidad de producto de software son
de gran importancia para la obtención de resultados
alentadores relacionados con la calidad.

La normatividad es una herramienta que debemos usar a

cabalidad para obtener productos de software de calidad.
Metacognición

Las siguientes preguntas te ayudarán a reflexionar sobre

tus propios aprendizajes, es un ejerció recomendado para
razonar e identificar nuestro esfuerzo intelectual, la
finalidad es regular nuestras acciones y procesos
mentales

¿Qué consideraciones podrías tener para lograr que las

microempresas desarrolladoras de software usen
estándares de calidad?
¿Conoce alguna otra normatividad que hable a cerca de
la calidad de software?
¿Usted qué acciones tomaría para implementar una
determinada norma de calidad de software en su
empresa?