El enfoque de calidad de PSP

El proceso personal del software (PSP) es un proceso de auto mejora diseñado para

ayudar a controlar y mejorar la forma en que se trabaja, se concentra en las prácticas de

trabajo de un ingeniero de manera individual, se aplica a programas pequeños de menos de

10000 líneas de código y sirve para producir software de calidad, donde cada ingeniero

debe trabajar en la necesidad de realizar trabajo de calidad.

Un proceso de calidad debería producir software de calidad de pocos defectos que

cumple con las necesidades del usuario.

Permite a los desarrolladores encontrar defectos en fases tempranas. Al encontrarlos

pronto, PSP reduce la cantidad de tiempo gastado en fases posteriores como la fase de

pruebas. Se exhorta a los ingenieros de software a realizar revisiones personales para cada

fase del desarrollo, incluye dos fases de revisión: revisión de diseño y revisión de código.

PSP se basa en algunos principios de calidad como:

o Cada ingeniero es diferente para ser el más eficaz los ingenieros deben

planificar su trabajo y deben basar sus proyectos en sus propios datos

personales.

o Para la mejora de su funcionamiento cada ingeniero debe usar procesos bien

definidos.

o Para producir productos de calidad, el ingeniero debe sentirse personalmente

responsable de la calidad de su producto.

o Es menos costoso encontrar defectos antes que en un proceso que más tarde.

o Es más eficiente prevenir defectos que encontrarlos durante el desarrollo.

 o El camino correcto es siempre el modo más rápido y más barato para hacer

un trabajo. [1]

Para hacer un trabajo de ingeniería de software de la manera correcta, los ingenieros

deben planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un

proceso bien definido para realizar de la mejor manera la planeación del trabajo.

Para que los desarrolladores lleguen a entender su funcionamiento de manera

personal, deben medir el tiempo que pasan en cada proceso, los defectos que inyectan y

remueven de cada proyecto y finalmente medir los diferentes tamaños de los productos que

llegan a producir.

Para producir constantemente productos de calidad, los ingenieros deben planear,

medir y rastrear constantemente la calidad del producto y deben centrarse en la calidad

desde el principio de un trabajo.

Finalmente, deben analizar los resultados de cada trabajo y utilizar estos resultados

para mejorar sus procesos personales. [2]

El enfoque principal que tiene la medición de la calidad en PSP está en los defectos.

Para administrar los defectos, los desarrolladores necesitan los datos completos sobre los

defectos que inyectan, las fases en las cuales las inyectaron, las fases en las cuales los

encontraron y arreglaron y cuánto tiempo tomó para arreglarlos. Con el PSP, los

desarrolladores registran los datos sobre cada defecto encontrado en cada fase, incluyendo

las revisiones, las inspecciones, compilaciones y finalmente en la fase de pruebas [3]

El costo de la calidad

El coste de la calidad se define, como lo que le cuesta a la organización desarrollar

la función de la calidad, es decir, lo que gasta produciendo con calidad (evitando,

previniendo o detectando los errores, inspeccionando los procesos, etc.), y también lo que

cuestan los errores producidos.

Se dice que la calidad es total, porque comprende todos y cada uno de los aspectos

de la organización, porque involucra y compromete a todas y cada una de las personas de la

organización. La calidad tradicional trataba de arreglar la calidad después de cometer

errores; pero la Calidad Total se centra en conseguir que las cosas se hagan bien a la

primera. Japón ha hecho de la Calidad Total, uno de los pilares de su renacimiento

industrial, definiéndola en función del cliente. [4]

La meta de PSP es ayudar a los desarrolladores a producir productos de calidad con

cero defectos y en la fecha propuesta. El costo de esta certificación es de: $263,916.00 La

duración de esta certificación es de 64 horas repartidas en 10 días. [5]

El costo total de la calidad se puede dividir en cuatro áreas clave:

Total Cost of Quality

Cost of Poor Quality Cost of Good Quality

External Failures Appraisal

Internal Failures Prevention

Tabla 1 Áreas clave del costo de calidad. Recuperado de:

https://www.qad.com/documents/portlet_file_entry/204544310/Cost+of+quality.gif/8b604268-dc88-7ba0-984a-
66912ee1718c?&imagePreview=1

Elementos del coste de calidad

Costes de la prevención.- Se obtienen a partir de la suma del coste de todas las

actividades que tienden específicamente a evitar una calidad deficiente de servicios.

 Costes de evaluación.- Están relacionados con la medición, evaluación o auditoría

de servicios para asegurar que se adaptan a las normas de calidad y a los requisitos de

comportamiento establecido.

Costes de errores internos.- Son los originados por los servicios que no se adaptan a

los requisitos o a las necesidades del cliente, cuando se detectan antes de la prestación del

servicio.

Costes de errores externos.- Son los originados por los servicios que no se adaptan a

los requisitos o a las necesidades del cliente cuando se detectan o mientras se presta el

servicio (o una vez prestado). [4]

Desafortunadamente, eso no lo cubre todo. También existen costos ocultos de la

calidad en todas las organizaciones. Éstos pueden ser costos cuantificables que se

consideran costos estándar y simplemente se absorben. O pueden ser costos blandos que

son difíciles de cuantificar pero que tienen un gran impacto en el desempeño de la

Tabla 2 Ejemplos de costo oculto de la calidad: Recuperado de:

https://www.qad.com/documents/portlet_file_entry/204544310/calidad.gif/8915c92c-50d1-3133-4b7b-8dfc0ace2667?
&imagePreview=1
organización. Estos costos también se pueden atribuir a cada uno de los cuatro tipos de

costos de calidad. [6]

La estrategia de calidad

El término calidad de software se refiere al grado de desempeño de las principales

características con las que debe cumplir un sistema computacional durante su ciclo de vida,

dichas características de cierta manera garantizan que el cliente cuente con un sistema

confiable, lo cual aumenta su satisfacción frente a la funcionalidad y eficiencia del sistema

construido.

El concepto de calidad de software, se asocia a la "concordancia con los requisitos

funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo

plenamente documentados y con las características implícitas que se espera de todo

software desarrollado profesionalmente" [7], con base en los requisitos funcionales y no

funcionales identificados en la etapa de análisis del sistema, insumo principal para

implementar dichos requisitos con los atributos mínimos de calidad, fomentando la

aplicación de procesos estandarizados y criterios necesarios en cada una de sus etapas, así

se fomenta que el avance en el ciclo de vida del software minimice el riesgo de fracaso del

proyecto. Por su parte, el Instituto de Ingenieros Eléctricos y Electrónicos define calidad de

software como "el grado con el que un sistema, componente o proceso cumple los

requerimientos especificados y las necesidades o expectativas del cliente o usuario",

denotando que el énfasis radica en los requisitos específicos del sistema y en la búsqueda

de la satisfacción del cliente.

 Para garantizar la calidad de software es importante implementar algún modelo o

estándar de calidad que permita la gestión de atributos en el proceso de construcción de

software, teniendo en cuenta que la concordancia de los requisitos y su construcción son la

base de las medidas de calidad establecidas.

Los modelos de calidad de software se clasifican de acuerdo con el enfoque de

evaluación, ya sea a nivel de proceso, producto o calidad en uso.

Calidad a nivel de proceso

La calidad de un sistema software debe ser programada desde el inicio del proyecto,

y posteriormente en cada etapa del proceso de desarrollo se debe llevar a cabo el control y

seguimiento de los aspectos de calidad, para minimizar los riesgos y ofrecer soporte

continuo, se garantiza así un óptimo nivel de cumplimiento de los factores de calidad,

teniendo en cuenta que si en alguna de las etapas se deja de lado la verificación de los

factores y criterios es posible que se presente deficiencia en alguno de éstos y disminuirá el

nivel de calidad no solo del proceso, sino también del producto en desarrollo.

Calidad a nivel de producto

La principal finalidad del modelo de calidad de producto es especificar y evaluar el

cumplimiento de criterios del producto, para lo cual se aplican medidas internas y/o

medidas externas [8]. Por esta razón, algunas normas y estándares han definido la calidad a

nivel de producto en tres tipos: interna, externa y en uso [9]. Este enfoque está orientado a

verificar el cumplimiento de las características que permitan alcanzar la satisfacción del

cliente en cuanto a los requisitos definidos en las etapas iniciales del proceso de desarrollo.

Calidad en uso

Es importante resaltar que aunque en diferentes escenarios se utilizan los términos

usabilidad y calidad en uso, con el mismo propósito y de forma intercambiable tienen

significados distintos, principalmente porque el concepto de calidad en uso es más amplio y

abarca más elementos que la usabilidad [10], y esta última es una de las características de

calidad de un producto software. La calidad en uso se define como el "conjunto de atributos

relacionados con la aceptación por parte del usuario final y seguridad", y está basada en la

eficacia, productividad, seguridad y satisfacción, según ISO/IEC 9126.

Modelos a nivel de proceso

Con base en la información recopilada se presenta en la ilustración 1, en la que se

muestra la línea de tiempo de algunos modelos a nivel de proceso.

Ilustración 1 Línea de tiempo de modelos a nivel de proceso: Recuperado de:

https://www.redalyc.org/journal/2654/265452747018/1900-3803-entra-13-01-00236-gf2.png

ITIL: Desarrollado en el Reino Unido, con el fin de fortalecer la gestión

gubernamental, a partir de cinco elementos fundamentales: la perspectiva del negocio,

entrega del servicio, soporte del servicio, manejo de la infraestructura y manejo de

aplicaciones, con el propósito de ofrecer una estructura integral para prestar a la

organización un servicio completo, cubriendo necesidades de apoyo de instalación,

adecuación de redes, comunicaciones, hardware, servidores, sistema operativo, y software

necesarios.
 ISO/IEC 15504: Permite adaptar la evaluación para procesos en pequeñas y

medianas empresas (pymes) y grupos de desarrollo pequeños, mediante la estructuración en

seis niveles de madurez: Nivel 0- Organización inmadura, Nivel 1- Organización básica,

Nivel 2- Organización gestionada, Nivel 3- Organización establecida, Nivel 4-

Organización predecible y Nivel 5- Organización optimizando. Su objetivo es llegar a que

la organización logre ser madura, lo cual conlleva que la organización tenga procesos

definidos, responsabilidades definidas, predicción de resultados, productos entregados con

calidad, que las entregas se den en los tiempos pactados, incrementar la productividad,

clientes satisfechos, y empleados felices [11].

Bootstrap: Metodología de evaluación que permite la mejora de procesos a partir de

seis actividades básicas: Examinar la necesidad, Iniciar proceso de mejora, preparación y

dirección de la evaluación, análisis de resultados, implantación y finalización de mejoras

[12].

Dromey: Es un modelo adaptable a evaluar varias etapas del proceso de desarrollo

como levantamiento de requisitos, diseño e implementación. Se estructura con

características y sub-características de calidad; propone tres modelos distintos para cada

etapa de construcción del producto: modelo de requerimientos, modelo de diseño y modelo

de calidad de la implementación, a partir de la evaluación establecida en cinco etapas, para

características como: eficiencia, confiabilidad, mantenibilidad, portabilidad, facilidad de

uso y funcionalidad [13].

Personal Software Process (PSP): Este modelo está enfocado al desarrollo

profesional del ingeniero, fomentando una adecuada administración de calidad de los

proyectos de desarrollo, reducción de defectos del producto, estimación y planeación del

trabajo.
 Team Software Process (TSP): TSP es la fase posterior de PSP, está diseñado para

el trabajo de equipos de desarrollo de software autodirigidos, que se orienta al desarrollo de

productos con el mínimo de defectos en tiempo y costos estimados. Cuenta con planes

detallados y procesos como revisiones personales, inspecciones e índices de desempeño de

calidad, y el fomento de la integración del equipo.

IEEE / EIA 12207: Este estándar establece un marco de trabajo común para el ciclo

de vida del desarrollo de software, a partir del planteamiento de procesos, actividades y

tareas que pueden ser aplicadas durante la adquisición, suministro, desarrollo, operación,

mantenimiento y/o despliegue de un producto software.

Cobit 4.0: Se caracteriza por ser orientado a negocios y proceso, además de ser

basado en controles, trabaja con siete criterios de información que son definidos como

requerimientos de control del negocio: efectividad, eficiencia, confidencialidad, integridad,

disponibilidad, cumplimiento y confiabilidad.

ISO 90003: Conjunto de estándares utilizados para el desarrollo, suministro y

soporte del software, cuyo propósito es ofrecer una guía de aplicación de la norma 9001

que pretende ser utilizada para demostrar o soportar que la entidad está en capacidad de

desarrollar software con criterios de calidad.

CMMI (Capability Maturity Model Integration):

Es de los modelos más utilizados en las empresas de construcción de software, con

el propósito de verificar el cumplimiento de estándares de calidad a partir de la medición

con niveles de madurez. Este modelo se representa de dos maneras: escalonada y continua,

donde el modelo escalonado está dirigido al software y permite clasificar las organizaciones

en cinco tipos de nivel establecidos: Inicial, gestionado, definido, gestionado

cuantitativamente y en optimización; y por su parte el modelo continuo se enfoca al análisis

de la capacidad de cada proceso inmerso en las áreas de la ingeniería de sistemas y lo

clasifica en uno de los siguientes seis niveles: Incompleto (0), ejecutado (1), gestionado (2),

definido (3), cuantitativamente gestionado (4) y en optimización (5).

ISO/IEC 20000: El objetivo principal de esta norma es el de avalar que la prestación

de servicios gestionados de TI de una empresa cuentan con la calidad necesaria para brindar

dichos servicios a los clientes. Se subdivide en dos partes: "Especificaciones", publicada

como ISO 200001:2005, y "Código de buenas prácticas" publicada como ISO 20000-

2:2005.

Modelos a nivel de producto

McCall: Uno de los modelos pioneros en la evaluación de la calidad de software,

tiene tres etapas definidas: factores, criterios y métricas. Los once criterios base, son:

Exactitud, confiabilidad, eficiencia, integridad, usabilidad, mantenibili-dad, testeabilidad,

flexibilidad, portabilidad, reusabilidad e interoperabilidad.

GQM o Goal Question Metric: Se enfoca a proporcionar una forma que permita

definir métricas para medir el avance como los resultados de algún proyecto, a partir de la

aplicación de unas preguntas relacionadas con el proyecto, que permitan alcanzar unas

metas previamente planteadas, el modelo trabaja sobre metas, preguntas y métricas.

Boehm: Es un modelo incremental, dividido en regiones de tareas y estas a su vez

en conjuntos de tareas, las cuales se ajustan a la cantidad de iteraciones que el equipo

defina, y cada iteración se divide en cuatro sectores: planeación, análisis de riesgo,

ingeniería y evaluación.
 FURPS: Modelo desarrollado por Hewlett-Packard, cuyo nombre proviene de los

criterios que evalúa: Funcionalidad, usabilidad, confiabilidad (reliability), desempeño

(performance) y soportabilidad.

GILB: Modelo de calidad que orienta la evaluación de software a partir de los

atributos: Capacidad de trabajo, adaptabilidad, disponibilidad y utilizabilidad, los cuales se

dividen en subatributos, de tal manera que sirva de apoyo a la gestión de proyectos, y

proporcione una guía para solucionar problemas y detectar riesgos.

ISO 9126: Estándar basado en el modelo de McCall, dirigido a desarrolladores,

aseguradores de calidad, evaluadores, analistas y cualquier otro involucrado en el proceso

de construcción de software. Está dividido en cuatro partes: modelo de calidad, métricas

externas, métricas internas y calidad de métricas en uso; elementos en torno a seis

características (funcionalidad, Habilidad, usabilidad, eficiencia, mantenibilidad y

portabilidad) y subcaracterísticas asociadas.

SQAE o Software Quality Assessment Exercise: Este modelo, basado en Boehm,

McCall, Dromey e ISO 9126, está orientado principalmente a realizar evaluación por

terceros que no están directamente involucrados con el desarrollo, siguiendo tres capas:

área, factor y atributo de calidad, que permiten orientar la evaluación jerárquicamente.

WebQEM: es una metodología de evaluación de calidad de sitios Web (Web-site

Quality Evaluation method), diseñada para la evaluación siguiendo seis fases: planificación

y programación de la evaluación de calidad, definición y especificación de requerimientos

de calidad, definición e implementación de la evaluación elemental, definición e

implementación de la evaluación global, análisis de resultados, conclusión y

documentación, validación de métricas.

 ISO 25000: También llamadas como SQuaRE, cuyo propósito es guiar el desarrollo

con los requisitos y la evaluación de atributos de calidad, principalmente: la adecuación

funcional, eficiencia de desempeño, compatibilidad, capacidad de uso, Habilidad,

seguridad, mantenibilidad y portabilidad.

CMMI

El modelo CMMI es uno de los modelos de mayor acogida para la evaluación de

grandes empresas, como por ejemplo empresas desarrolladoras de software, la cuales

necesitan cumplir con cierto de nivel de madurez de los que propone el modelo,

certificando así que el producto software cumple con criterios de calidad.

Bootstrap

Este modelo se ha implementado principalmente en empresas europeas, dentro de la

revisión bibliográfica es escasa la documentación encontrada con respecto a su

implementación.

PSP Personal Software Process

PSP (Personal Software Process), es un modelo enfocado al personal involucrado en

el proceso, este modelo se ha implementado en ámbitos académicos, desarrollo de software

y mejora de procesos empresariales, uno de los casos de estudio que se revisaron es el de

una organización desarrollo-laboral de productos de software ERP, CRM, Educativos y

otros productos especiales donde se encontró una integración de metodologías ágiles

(SCRUM) con PSP, identificando que el porcentaje de error cada vez era más bajo para la

mayoría de desarrolladores, favoreciendo así el proceso de estimación, y mejorando el

proceso de desarrollo. [14]

5.4 Proceso de comparación

El análisis comparativo es el proceso mediante el cual se analiza el uso de

determinadas herramientas de software bajo criterios de evaluación con la finalidad de

determinar cuál es la más adecuada para el contexto seleccionado. Dicho análisis requiere

modelos y sus elementos (procedimientos, prácticas, técnicas y herramientas, entre otros)

bajo los cuales debe ser llevado a cabo para obtener los mejores resultados sobre el objeto

de estudio. [15]

La prueba de comparación se refiere a un tipo de prueba en la que la fuerza y la

debilidad del software desarrollado actualmente se compara con los productos de software

ya existentes en el mercado. Ayuda a evaluar el rendimiento del producto de software

actual frente a la competencia del mercado; además, las pruebas de comparación ayudan al

desarrollo de un producto de software de alta calidad con rendimiento y funcionalidad

mejorados.

En realidad, las pruebas de comparación permiten descubrir las lagunas del producto

de software existente y obliga a superar las lagunas para estar a la cabeza en la

competencia. Pero crear un mercado competitivo no es el objetivo de las pruebas

comparativas, sino que se centra en crear productos de software mejorados de vez en

cuando. Se puede considerar cualquier parte de la aplicación de software para realizar

pruebas de comparación. Puede ser Interfaz de usuario, Número de funciones, Velocidad,

Base de datos, Seguridad y muchos más. Principalmente, estos criterios de prueba se

deciden en función del tipo de aplicación de software que se está probando y los casos de

uso específicos de los requisitos comerciales.

No hay una fase específica para las pruebas de comparación, tampoco hay una guía

específica para realizar las pruebas de comparación y no hay una fase particular del
desarrollo de software. Se puede realizar de forma individual o con otro tipo de pruebas de

software. Pero generalmente se realiza en tres etapas del desarrollo de software, es decir

 Etapa inicial del proceso de desarrollo de software

 Etapa intermedia del proceso de desarrollo de software

 Última etapa del proceso de desarrollo de software

Cuando hay confusión con respecto a los criterios de prueba, se someten a dos fases

de comparación diferentes, es decir

 Compare la aplicación de software con estándares o puntos de referencia conocidos.

 Compare la aplicación de software con características específicas de otros productos

de software existentes.

Ventajas de las pruebas comparativas:

 Puede indicar las debilidades y fortalezas de su aplicación.

 Ayuda a evaluar la calidad del producto de software.

 Le dice a su producto cuán competitivo y útil.

 Indica si el proyecto de software es comercializable o no.

 Dice que el software tiene una oportunidad justa de ser rentable o no.

 Ayuda a verificar todas las características importantes del software antes de su

lanzamiento comercial.

 Ayuda a comprender la estructura interna del diseño.

 Ayuda a que el producto sea lo suficientemente competitivo como para funcionar

bien en el mercado.

Desventajas de las pruebas de comparación:

  Se vuelve muy difícil volver a modificar algo o cambiar algo ya que ya ha pasado

una serie de fases de desarrollo.

 A veces, los clientes crean una mentalidad en contra después de conocer las

deficiencias o debilidades de su producto. [16]

Estrategias de remoción de defectos

Los defectos son una de las principales causas de disminución de la calidad del

software y aumento del costo general debido al costo adicional requerido para resolver los

defectos. Por lo tanto, identificar y resolver defectos es el enfoque principal de cualquier

equipo de desarrollo que ayudará a evitar que los productos de software vuelvan a ocurrir.

[16]

Existen dos tipos de defectos.

 Los que se encuentran en un solo modulo: se eliminaran teniendo un alto

rendimiento en PSP.

 Los que implican interacciones entre los modulos:

o Muchas interacciones y no se pueden visualizar

o Estrategia para abordar el problema

 Esfuerzo para desarrollar modulos de calidad.

 Inspecciones de las interfaces de cada modulo.

 Prueba de integración global.

 Hacer pruebas de unidad exhaustivas.

 Inspección en los requisitos para asegurar que funcione

correctamente.

 Inspección en el sistema y el diseño del programa.

El proceso de desarrollo debe encontrar y corregir los defectos.

Los defectos en los grandes sistemas están en los modulos que lo construyen. [17]

Estrategias de prevención de defectos

Para implantar un proceso de pruebas basado en la prevención de defectos es

necesario definir qué parámetros van a servir para decidir si un defecto debe ser analizado o

no. Partiendo de la base de que los recursos son limitados, no es viable analizar la causa

raíz de todos los defectos, sino sólo de aquellos que por su tipología merecen ese esfuerzo.

Los parámetros que habitualmente se utilizan son: el daño potencial del defecto (económico

o de imagen), frecuencia de ocurrencia, el coste que supone solucionarlo y el impacto del

defecto en el conjunto de la aplicación.

Por otra parte, es necesario disponer de técnicas, mecanismos, herramientas y

formación para que el análisis de la causa raíz de los defectos pueda llevarse a cabo de

forma sistemática y formalizada. Diagramas de Ishikawa, diagramas de causa-efecto,

esquemas de clasificación de defectos o la técnica de los 5 porqués, son algunos ejemplos

de técnicas que permiten analizar cuál es la causa raíz de un defecto.

Con los parámetros y mecanismos de prevención implantados se estará en

disposición de incorporar esta práctica al proceso de pruebas. Lo habitual es que al final de

cada uno de los niveles de pruebas definidos en la organización se seleccionen, en base a

los parámetros establecidos, los defectos a analizar. Para su análisis se aplicarán las

técnicas definidas hasta llegar a identificar la causa raíz que ha provocado el defecto. Una

vez conocida dicha causa, el siguiente paso será definir una o varias acciones correctivas

que puedan evitar que un defecto similar ocurra. Como es lógico, las acciones correctivas

se focalizan en las etapas anteriores al punto del ciclo de vida en la que se detectó el

defecto, ya sea fase de requisitos, análisis, diseño o construcción. [18]

El proceso de diseño

El diseño establece un enfoque preliminar de diseño y los nombres de los objetos

esperados y sus funciones.

No consiste en realizar el diseño completo, sino determinar los objetos que se

necesitan y las funciones que van a realizar.

La medida de tamaño del proxy debería estar relacionada con el esfuerzo necesario

para desarrollar el producto.

El contenido de un proxy de un producto debe poderse contar automáticamente.

El proxy debe de ser fácil de visualizar al principio del proyecto.

El proxy debe de ser adaptable a las necesidades concretas de cada organización •El

proxy debe de ser sensible a las variaciones de implementación que afectan al coste o

esfuerzo de desarrollo.

Requisitos iniciales

 Recopilar datos de los requisitos del usuario

 Analizar los requisitos

 Concebir un diseño de alto nivel

 Refinar y documentar el diseño

 Diseño completo.

 Validar el diseño contra los requisitos a todos menos azules.

 Obtener respuestas a las preguntas de requisitos (igual).

Normalmente se empieza un diseño definiendo el objetivo del producto, recopilando

datos relevantes, produciendo un diseño general y rellenando los detalles. Estos pasos no

son secuenciales, sin embargo, son actividades paralelas y cooperativas. Normalmente el

diseño implica invención y normalmente requiere saltos de abstracción de unos niveles a

otros. [19]