Capítulo IX

Gestión de Calidad

176

Gestión de calidad Tabla de contenido

1.- Concepto de error en sistemas............................................................. 177 2.- Concepto de calidad en sistemas ......................................................... 178 3.- Los atributos de calidad ...................................................................... 180 4.- Calidad y estándares............................................................................ 182 5.- Promoción o control de calidad ........................................................... 182 6.- El rol de aseguramiento de calidad en sistemas .................................. 182 7.- Detección temprana de errores ............................................................ 183 8.- Prerrequisitos para las técnicas de calidad .......................................... 185 9.- La técnica de walkthrough .................................................................. 186 10.- La técnica de inspecciones ............................................................. 188 11.- Las revisiones de calidad ................................................................ 190 12.- Pasos del procedimiento de revisión .............................................. 193 13.- Notas del PMBOK ......................................................................... 196

177

Gestión de calidad

1.- Concepto de error en sistemas El autor Glenford J. Myers, en su libro Software Reliability Principles

& Practices, ilustra con un ejemplo lo que es un error de software; para ello, nos refiere la historia del “Ballistic Missile Early Warning System”. Dicho sistema fue diseñado para controlar los objetos que se mueven hacia el espacio aéreo de los Estados Unidos e iniciar una serie de procedimientos defensivos, que van desde hacer contacto con el objeto, hasta la retaliación, si éste no se identifica. Al referirnos a que el sistema, en sus primeras versiones, identificó la luna como un avión enemigo, Myers nos hace reflexionar acerca de si ello es un error. Desde el punto de vista del analista/programador el sistema procede de acuerdo con las especificaciones, luego no hay error; sin embargo, todos sabemos que se trata de un error, la luna no es un avión enemigo.

Muchos autores, junto con Myers, han intentado definir lo que es un error de software, todos ellos lo han logrado hacer con éxito parcial. Algunos sostienen que un error de software ocurre cuando éste no se desempeña de acuerdo con sus especificaciones. Otros añaden que el hecho de que un sistema no se desempeñe de acuerdo a las especificaciones, puede ser considerado como un error de software, siempre y cuando el mismo esté siendo usado dentro de las limitaciones de su diseño. Finalmente, otros afirman que un error de software se presenta cuando éste no hace lo que el usuario razonablemente espera que haga.

Cada persona en la industria podría darnos una buena definición de lo que es un error de software. Sin lugar a dudas, todas incluirán el componente “requerimientos del usuario”, el componente “razonable” y “elemento humano” que, en todo sistema, debe ser tomado en cuenta como fuente de problemas para su operación y funcionamiento.

178

2.- Concepto de calidad en sistemas Así como todos tenemos una idea intuitiva de lo que es un error,

también la tenemos de lo que es calidad en un sistema o en un componente de software. Sin embargo, desde el punto de vista de calidad en sistemas de información, definir lo que es un buen sistema -o por lo menos establecer lo que está bien, para diferenciarlo de lo que está mal- requiere de una definición precisa, pues no estamos frente a un problema meramente académico, estamos frente a un verdadero reto que la práctica diaria nos presenta y una exigencia creciente por parte de los usuarios de sistemas de información.

Presentaremos cuatro definiciones relacionadas con calidad en sistemas y sobre ellas basaremos el desarrollo de nuestras discusiones acerca de calidad en sistemas de información. La primera definición fue expresada por William E. Perry en su obra Effective Methods of EDP Quality Assurance, la segunda por el IEEE (Institute of Electrical and Electronic Engineers - Computer Society), la tercera por G. J. Myers en la obra que ya citamos al comienzo del capítulo y, por supuesto, la definición que propone el PMI en su PMBOK. W. E. Perry:

Calidad se define en el diccionario como un atributo o característica asociada a algo, así pues, calidad no puede ser definida de manera universal, sino que, por el contrario, debe ser definida para ese algo en cuestión. Calidad viene a ser una lista que expresa una serie de características y atributos. Calidad en el ambiente de procesamiento de datos debe ser definida por la organización. La definición de calidad hecha por una organización puede ser diferente a la hecha por otra. Para una organización, un FORD MODELO T bien construido es calidad, mientras que, para otra, calidad es un CADILLAC FULL EQUIPO. La calidad no puede ser incorporada a un producto o ser medida hasta tanto no se defina. La gran mayoría de las instalaciones de procesamiento de datos apenas han comenzado a definir lo que es calidad en las aplicaciones computarizadas.

La definición de Perry nos dice, principalmente, que la calidad no debe ser concebida en términos generales o abstractos y que cada organización debe identificar lo que para ella significa un sistema de calidad, con el fin de establecer los patrones y las vías necesarias para lograrla.

179

IEEE - Computer Society - Estándar P730: Software Quality Assurance (SQA) es un patrón planeado y sistemático de todas las acciones necesarias, para proveer suficiente confianza de que el software se construye conforme a los requerimientos técnicos preestablecidos.

A pesar de que la definición de IEEE - Computer Society está orientada hacia la función de calidad en sistemas, al definir las responsabilidades de SQA describe varios aspectos importantes relacionados con la calidad de los sistemas:

1. La calidad de un sistema requiere de la participación de todos, no es algo que atañe exclusivamente a un grupo de SQA, incluye “todas las acciones necesarias”.

2. La calidad de un sistema es fruto de una cuidadosa planificación; no es algo que se logra de manera fortuita o improvisada.

3. La noción de calidad es relativa a especificaciones técnicas preestablecidas.

4. El propósito de SQA no es el de garantizar 100% de confiabilidad, es aumentar la confianza de que se han dado todos los pasos necesarios para limpiar de errores el software que se desarrolla.

G. J. Myers: La confiabilidad del software es la probabilidad de que este se ejecute por un cierto período de tiempo sin fallas, ponderada por el costo que representa para el usuario cada falla encontrada.

La definición de Myers tiene dos elementos importantes: 1. Probabilidad de que se presente una falla; esto es, nunca

existe la absoluta certeza de que un software esté totalmente limpio de errores.

2. Costo de la falla; es decir, cuando hablamos de calidad en un sistema nos preocupa principalmente las fallas costosas, aquellas que impactan negativamente la operación del negocio.

El PMBOK del PMI: Calidad es la totalidad de las características de una entidad que tienen inherencia en su capacidad de satisfacer necesidades explícitas o implícitas.

180

El PMBOK también enfatiza que la administración de la calidad de un proyecto deberá dirigirse tanto al proceso, como al producto del proyecto.

3.- Los atributos de calidad Si bien es difícil poder escribir una

definición totalmente satisfactoria y general de calidad en sistemas, cada uno de nosotros puede, de manera intuitiva, definir cuáles son las “cosas” que caracterizan a un sistema de calidad o, en otras palabras, definir cuáles son los atributos que nos permiten decidir si un determinado sistema es de alta, mediana o baja calidad.

La experiencia nos señala los siguientes atributos:

1. Adecuación al negocio Es el grado en que un sistema cumple con sus especificaciones, requerimientos y objetivos funcionales.

2. Confiabilidad Es el grado de precisión con que un sistema realiza sus operaciones.

3. Eficiencia Es la relación que guardan la cantidad y complejidad de las funciones que un sistema realiza para sus usuarios, y la cantidad de recursos requeridos para realizarlas.

4. Facilidad de operación Es una medida del esfuerzo requerido para operar un sistema, preparar sus datos de entrada e interpretar los resultados que produce. Normalmente, esta cualidad se asocia con la “amigabilidad” del sistema.

5. Facilidad de entrenamiento Es una medida del esfuerzo requerido para aprender a operar y a interpretar los resultados que produce un sistema.

181

6. Integración Es la capacidad que tiene un sistema para integrarse con los restantes sistemas de la empresa, intercambiando y compartiendo datos con otras aplicaciones o usuarios.

7. Disponibilidad Es una medida de la facilidad con que el usuario puede tener acceso a las aplicaciones y la información procesada por ellas. Normalmente, la disponibilidad de un sistema se asocia con los niveles de servicio o con la continuidad del servicio prestado por el sistema.

8. Seguridad Es el grado de dificultad que encuentran las personas no autorizadas al tratar de tener acceso a las funciones, los componentes o los datos de un sistema.

9. Integridad Es el grado de dificultad establecido para evitar que algún evento o persona, autorizada o no, pueda dañar, en forma voluntaria o accidental, los componentes o la información manejada por el sistema.

10. Mantenibilidad Es una medida del esfuerzo requerido para localizar y corregir la fuente de error en un sistema.

11. Flexibilidad Es una medida del esfuerzo requerido para mejorar o ampliar las funciones que realizan los componentes de un sistema.

12. Facilidad de prueba Es una medida del esfuerzo requerido para probar un sistema y, de esa forma, asegurar que está libre de errores y cumple con sus especificaciones.

13. Reusabilidad Es la capacidad de adaptación de los componentes de un sistema para ser utilizados en otras aplicaciones.

14. Portabilidad Es una medida del esfuerzo requerido para transferir un sistema, desde una plataforma de hardware o software a otra.

182

4.- Calidad y estándares La definición de las características que debe cumplir cada producto

que conforma un sistema -programas, documentación, formatos de pantalla, diseño de bases de datos, etc.- constituye lo que denominamos los estándares. Expresándolo en otros términos, podemos decir que, dentro de una empresa dada, los estándares que se definen para cada producto establecen el nivel de calidad que debe cumplir ese producto.

Diremos que un producto “no está bien” si no cumple con los estándares. Por ejemplo, supongamos que hemos hecho el diseño de una base de datos; por muy bien hecho que esté el diseño, si no se cumplen los estándares de nomenclatura establecidos para las tablas y los datos, tendremos que decir que el diseño no está bien. Así pues, además de los 14 atributos -antes citados- que caracterizan la calidad de un sistema, está el atributo que podemos denominar cumplimiento de los estándares.

5.- Promoción o control de calidad El término inglés Software Quality Assurance (SQA) se traduce

comúnmente como Control de Calidad en Sistemas. Esta traducción deja bastante que desear; pues no sólo es pobre, sino que le imprime a la función un sentido “policíaco” que no tiene. La tarea de una unidad de SQA es principalmente motivar y promover la calidad; aunque, no negaremos que debe incluir también la de controlar, pero ella no es su función única y ni siquiera su función primordial.

Haciendo estas consideraciones, hemos creído más conveniente utilizar el término “Calidad en Sistemas de Información (CSI)” para denominar a la función que, dentro de informática, se encarga de velar por la calidad de los sistemas.

6.- El rol de aseguramiento de calidad en sistemas En la década de los 80, los éxitos de la industria japonesa hicieron que

todas las empresas prestaran mucha mayor atención a la calidad de sus productos y servicios. La experiencia japonesa demostró que el camino hacia la excelencia comienza con la definición de los estándares de calidad -calidad del producto- y los métodos utilizados para obtener el producto -calidad del proceso-. Prosigue con el establecimiento de los mecanismos necesarios para asegurar que el nivel de calidad deseado se alcanza -control de calidad- y no finaliza allí, sino que sigue en forma continua con un cuestionamiento permanente de los métodos, los

183

procesos y los productos, con el fin de alcanzar niveles de calidad superiores.

Dentro de la organización de informática, la función de Calidad en Sistemas de Información (CSI) es, precisamente, motorizar este proceso de florecimiento continuo de la calidad. Para ello, echa mano de la metodología, ya que ésta le permite establecer métodos -calidad del proceso- y estándares -calidad del producto-, sobre los cuales se puede definir y evaluar la calidad de un sistema de información. Asimismo, permite adoptar técnicas de revisión o control de calidad que ayudan a verificar la calidad del “producto final”. Dicho de otra forma, la creación de la función de Calidad en Sistemas de Información no tiene sentido si se considera como algo separado de la metodología de desarrollo, pues no tendría ninguna utilidad crear una función de este tipo en un departamento de informática que no esté considerando seriamente adoptar una metodología para el análisis, diseño, construcción e implantación de sistemas.

La unidad responsable de CSI debe asumir el rol de “padrino de la metodología y los estándares” dentro de la organización de TI; aunque, su misión central no es simplemente “velar por el fiel cumplimiento de la metodología y los estándares”, pues aquellos no son más que los vehículos para “alcanzar” la calidad. Su función primaria es la de ayudar a cada líder de proyecto a utilizar correcta y racionalmente todos los componentes de la metodología, con el fin de que estos líderes puedan desarrollar y mantener sistemas dentro de un ambiente de calidad y productividad creciente.

CSI es el organismo que ayuda a la gerencia de proyectos a enfrentar las dificultades y retos que ofrece el logro de la calidad:

Soporte a la metodología. Definición de guías y estándares. Evaluación y selección de herramientas. Desarrollo de un ambiente de calidad y productividad.

7.- Detección temprana de errores Generar o mantener sistemas de calidad no es responsabilidad

exclusiva de la función de CSI, es una responsabilidad colectiva; tanto de los gerentes, como de analistas, programadores y usuarios. Para poder cumplir con esa responsabilidad colectiva -generar o mantener sistemas con un alto nivel de calidad- es necesario: primero, definir el nivel de

184

calidad deseado y, segundo, mantener una actitud de vigilancia continua que permita identificar cualquier desviación.

¿Por qué es importante mantener una actitud de vigilancia que permita detectar cualquier desviación o error lo más pronto posible? Porque el “costo de corregir un error” aumenta a medida que transcurre el tiempo. Veamos:

Un error de sintaxis en un programa es un error que se detecta con facilidad, el compilador lo señala y puede corregirse con facilidad.

Un error de “lógica” en un programa -por ejemplo, un cálculo mal desarrollado- es más difícil de detectar y su proceso de corrección puede ser costoso en algunos casos, especialmente si el sistema ya está operacional.

Un error en la definición de los requerimientos funcionales de una aplicación puede ser muy fácil de corregir, si sólo se han escrito sus especificaciones. Sin embargo, será más costoso corregirlo si los programas ya han sido desarrollados y, será mucho más difícil y costoso de corregir si la aplicación está lista para ser puesta en producción.

El impacto de un error varía en el tiempo, pues el costo de corregir un

error será mayor en la medida en que pase inadvertido a las siguientes fases del proyecto. Costará más corregir un error de diseño cuando el sistema esté en operación, que cuando esté en prueba o cuando esté

185

siendo diseñado. Un error causado por deficiencias en la definición de los requerimientos funcionales puede tener consecuencias devastadoras para el éxito de un sistema, especialmente si pasa inadvertido desde la etapa de definición de requerimientos a las etapas de diseño, construcción o implantación.

Cualquier metodología de desarrollo que se adopte debe incluir conceptos, criterios, técnicas, herramientas y procedimientos de control de calidad, que faciliten la detección temprana de errores. De tal forma, se reduce la cantidad de errores que, durante el desarrollo de un sistema, puedan pasar inadvertidamente de una etapa a otra.

Las siguientes secciones de este capítulo las hemos dedicado a discutir algunas técnicas, que pueden ser adoptadas para mantener una vigilancia estrecha sobre la calidad de los productos y hacer realidad la “detección temprana de errores”.

8.- Prerrequisitos para las técnicas de calidad Toda técnica para estimular y controlar la calidad de los sistemas que

se desarrollan o mantienen, debe ser adoptada de manera apropiada dentro de un ambiente receptivo. Para ello, es necesario que exista tanto el compromiso de la gerencia, como los estándares y la metodología de desarrollo. 8.1.- Orientación a los productos

Calidad y orientación a los productos van de la mano. Si no existe una buena definición de los productos -estándares- no es posible definir el nivel de calidad esperado y, obviamente, no será posible establecer formalmente si los productos generados por un proyecto satisfacen los atributos de calidad requeridos por la empresa. 8.2.- Compromiso

Ciertamente, uno de los factores claves para la utilización de técnicas de control de calidad es, el compromiso por parte de todos los integrantes del staff de informática a adoptar y cumplir con la disciplina que imponen tales técnicas. Además de ese compromiso de carácter general, la utilización de las técnicas requiere que, tanto la gerencia, como todos los representantes funcionales, analistas y programadores acepten las exigencias que impone una disciplina de control de calidad, a saber:

Compromiso de obtener la aprobación de los productos, antes de darlos por concluidos.

186

Inversión de tiempo por parte de los integrantes del proyecto en la realización de revisiones de calidad.

Compromiso de parte del proyecto a implantar las correcciones necesarias.

Sin el decidido apoyo de la gerencia, las técnicas de control de calidad no producirán buenos resultados y, simplemente, se convertirán en un requisito o dificultad más que los analistas y programadores tienen que vencer para poder adelantar su trabajo. Con el debido respaldo y entusiasmo de la gerencia, los procesos de control de calidad pueden ir refinándose hasta adaptarse al ambiente de la empresa y convertirse en una herramienta valiosa que estimule la creación de productos de calidad. 8.3.- Formalidad

Cualquier proceso de control de calidad debe ser cuidadosamente planificado. Su oportunidad, sus participantes y su objetivo deben estar bien definidos de antemano. Improvisar los procesos de revisión llevará a que los miembros de los equipos de proyecto los vean más como un trámite, que como una ayuda para asegurar que los productos generados sean de alta calidad.

9.- La técnica de walkthrough Una de las técnicas más populares para Control de Calidad es la

técnica de walkthrough. Esta técnica, creada en los años 70, alcanzó gran popularidad junto con diferentes técnicas de productividad, como la Programación Estructurada y el Chief Programmer Team. Hoy en día, la técnica de walkthrough ha sido adoptada, prácticamente, por todas las instalaciones de procesamiento de datos, bien sea de manera informal o en forma muy estructurada.

Walkthrough significa “caminar a través” de algo y en eso, precisamente, consiste la técnica, en recorrer un programa o una pieza de documentación; con el fin de identificar inconsistencias, detectar errores o áreas de mejora. Un walktrought, como su significado lo sugiere, es una sesión de revisión que se lleva a cabo para evaluar algún producto tangible generado por un proyecto, un analista o un programador: programa, procedimiento, especificación de diseño, diseño de base de datos, instructivo, etc. Esta revisión la realizan diversas personas invitadas, a las que, previo a la reunión de walkthrough, se les ha entregado el material; con el objeto de que tengan la oportunidad de analizarlo con el debido cuidado.

187

En la reunión de walkthrough los evaluadores invitados le hacen al autor, o autores, los comentarios y las observaciones que tengan, en relación con el material revisado. El autor del material escucha y toma notas de tales comentarios, con el fin de mejorar el trabajo realizado.

La técnica original de walkthrough no establece un procedimiento formal de revisión, aunque en muchas empresas se le da un carácter muy formal. En estas empresas los procedimientos de desarrollo de sistemas establecen que cada proyecto de desarrollo o mantenimiento de sistemas, al terminar cada fase o etapa, debe convocar las sesiones de walkthrough necesarias para que el producto de esa fase o etapa sea evaluado a fondo, antes de que el proyecto pueda continuar adelante. Es decir, en muchas empresas el walkthrough es obligatorio y recibe todo el apoyo de la gerencia, hasta el punto de otorgarle a los resultados poder de veto.

En la mayoría de las empresas, sin embargo, el walkthroug tiene un carácter más informal y se realiza, principalmente, a instancias del autor o del líder del proyecto, con el fin de oír opiniones autorizadas y, de esta forma, tener la seguridad de que se está generando un producto de buena calidad. 9.1.- El procedimiento de walkthrough

En líneas generales, el procedimiento utilizado para la realización de sesiones de walkthrough contiene los siguientes elementos:

Revisores Usualmente los participantes de un walkthrough son personas que están al mismo nivel del autor del material y que, dados sus conocimientos y experiencia, son invitados a emitir una opinión sobre el trabajo realizado.

Preparación El material a ser evaluado debe ser entregado a los revisores con suficiente anticipación, de tal manera que la sesión de walkthrough no se haga innecesariamente larga.

Conducción de la sesión de walkthrough Normalmente la coordinación de todo el ejercicio de revisión la realiza el propio autor y es él mismo quien toma nota acerca de las observaciones recibidas. En aquellas empresas donde el walkthrough tiene un carácter más formal, las sesiones son dirigidas por un moderador y existe un escribiente cuya función es tomar las minutas de la sesión.

188

Observaciones y seguimiento En los walkthrough formales el moderador prepara un resumen de las observaciones presentadas por los revisores y el seguimiento queda a cargo de la gerencia del proyecto o del departamento. En la mayoría de las empresas, sin embargo, las observaciones son recopiladas por el mismo autor y no existe un procedimiento de seguimiento a las observaciones hechas.

9.2.- Puntos débiles de la técnica La práctica de muchos años ha demostrado que el walkthrough es una

excelente herramienta de control de calidad, sin embargo, su valor depende mucho, tal vez demasiado, de las personas que participan y de la actitud que ellas tomen en las sesiones. Una actitud excesivamente defensiva por parte del autor puede convertir un ejercicio de walkthrough en una reunión más, en la que no se obtenga provecho de la experiencia y los conocimientos de los revisores. La literatura que existe acerca de la técnica enfatiza que el éxito de un walkthrough depende mucho de una actitud positiva por parte del autor, que lo ayude a poner de lado el ego y a olvidar que el trabajo en discusión es fruto de su creación.

De la misma forma, si los revisores no mantienen una actitud abierta, es posible que hagan observaciones que se refieran más al estilo utilizado por el autor que a los posibles errores o verdaderos problemas. Es bien conocido que existen muchas formas de hacer una misma cosa y si el revisor no reconoce este hecho, las observaciones que haga no necesariamente mostrarán puntos a mejorar, sino simples discrepancias de estilo.

Es importante señalar, finalmente, que las reuniones de walkthrough tienen el permanente riesgo de alargarse innecesaria e improductivamente, si no se sigue una adecuada disciplina de discusión. Y es posible que, en lugar de centrar el interés de la reunión en identificar todos los problemas y dejar al criterio profesional del autor la forma de resolverlos, se invierta mucho tiempo en discusiones acerca de cómo debe ser corregido un determinado problema.

10.- La técnica de inspecciones La técnica de inspecciones fue diseñada por el doctor Mike Fagan, de

IBM, durante la década de los 70. Y es, hoy en día, junto al walkthrough, una herramienta de control de calidad de uso común, tanto en IBM como en muchas empresas que desarrollan software.

189

10.1.- ¿Qué es una inspección? Una inspección es un procedimiento de revisión y corrección, que se

sigue con el objeto de eliminar errores durante las diferentes fases de desarrollo o mantenimiento de un sistema. Una inspección puede ser practicada sobre cualquier producto tangible generado en alguna de las fases de desarrollo o mantenimiento. Como herramienta de control de calidad, las inspecciones deben realizarse en momentos claves del desarrollo o mantenimiento de un sistema.

Una inspección es bastante similar a un walkthrough, pero se diferencian de éste en la formalidad de sus procedimientos, ya que cada inspección representa un punto de revisión que debe ser pasado exitosamente por un sistema o componente, antes de que su desarrollo pueda seguir adelante. 10.2.- Componentes de una inspección

La técnica de inspecciones se compone de herramientas -criterios para la aceptación de productos, listas de chequeo y estadísticas- y de un procedimiento -planificación, sesión introductoria, preparación, inspección, corrección y seguimiento-. En cada paso del procedimiento de inspección intervienen diferentes personajes -coordinador, moderador, autor e inspectores- encargados de llevar a cabo la inspección de los productos -como se denomina al objeto de la inspección- y producir unos resultados escritos, que son, básicamente, un reporte de inspección, un plan de corrección y datos para actualizar las estadísticas de inspección. 10.3.- El procedimiento de inspección

Durante el desarrollo de un sistema, cada vez que se planifican las tareas a cumplir en algunas de sus fases, el coordinador del programa de inspecciones y el líder del proyecto establecen qué tipo de inspecciones serán llevadas a cabo y en qué oportunidades se realizarán. Para la planificación de las inspecciones se utilizan las estadísticas que el coordinador ha acumulado y se establecen, tanto los criterios para la aceptación de productos, como las listas de chequeo, de acuerdo a los estándares de la instalación y a las particularidades del proyecto.

Para realizar cada una de las inspecciones planificadas, primero, se efectúa una sesión introductoria, en la cual el autor presenta al equipo de inspección los productos que deberán ser inspeccionados. En esta sesión participan, además del moderador y de los inspectores, cualquier observador que haya sido invitado. Una vez cumplida la sesión introductoria, cada inspector, por separado, revisa el producto recibido;

190

con el fin de identificar errores y preparar las observaciones que presentará durante la siguiente reunión, denominada sesión de inspección. Para llevar a cabo la revisión, los inspectores siguen la guía establecida en las listas de chequeo que, de antemano, fueron preparadas por el líder del proyecto y el coordinador. Después de cumplida la revisión individual, se lleva a cabo la sesión de inspección. Los inspectores presentan y discuten sus hallazgos y observaciones, no con el fin de identificar soluciones, sino con el propósito de preparar una lista de problemas identificados que formarán parte del reporte de inspección. El moderador registrará los puntos discutidos y, junto con el autor y el líder del proyecto, establecerá un plan de correcciones, al cual le hará el seguimiento necesario, para asegurar que los errores reportados sean corregidos convenientemente.

11.- Las revisiones de calidad Dado que la preparación de listas de chequeo es una tarea ardua y

costosa, dentro del presente volumen hemos incluido una técnica de revisión que no requiere de listas de chequeo y que combina aspectos de las dos técnicas: walkthrough e inspecciones. Esta técnica la hemos denominado revisiones de calidad.

Una revisión de calidad sigue un procedimiento formal, como en una inspección, se cumple en varias etapas y en ella participan evaluadores invitados. El procedimiento enfatiza la necesidad de identificar y eliminar errores durante las diferentes fases de desarrollo o mantenimiento de un sistema, con el fin de minimizar la cantidad de errores que puedan pasar de una fase a otra.

Las revisiones de calidad deben practicarse dentro de cada fase, cada vez que se complete algún producto o grupo de éstos. Cada proceso de revisión tendrá como objetivo evaluar ese producto. Por ejemplo, dentro de la fase de análisis/diseño se realizarán varias actividades de revisión, con el fin de evaluar productos como: modelo de utilización de los datos, modelo de funcionamiento, estructura general del sistema y, definición y alcance de cada aplicación. 11.1.- Coordinador del programa de revisiones

El coordinador del programa de revisiones es la persona que forma parte del grupo de “Calidad en Sistemas de Información” (Software Quality Assurance) de la organización y ha sido asignado para coordinar todas las revisiones que se realicen para el proyecto. Dentro de los roles presentados en el capítulo de organización de proyectos se señala el de

191

consultor especialista en calidad. Este consultor, para los efectos del programa de revisiones, será el encargado de cumplir las siguientes responsabilidades:

1. Planificación Colabora con el líder del proyecto en la planificación de cada una de las actividades de revisión, que deberán ser realizadas en el transcurso de cada fase.

2. Selección del equipo de revisión Colabora con el líder del proyecto en la identificación de los consultores/evaluadores que deberán integrar los equipos de revisión y obtiene, de los supervisores de éstos, la autorización para que participen.

3. Entrenamiento Dicta charlas y seminarios a aquellas personas que hayan sido escogidas como miembros de un equipo de revisión y que aún no conozcan el procedimiento.

4. Publicación de calendarios Prepara un calendario de revisiones donde se detalla qué, cuándo, dónde y quiénes. Se encarga de publicarlo y distribuirlo a todas las personas involucradas.

5. Arreglos Reserva salas de reunión y materiales necesarios para llevar a cabo las revisiones.

6. Rol de moderador Actúa como moderador en las diferentes sesiones de revisión.

11.2.- Selección del equipo de revisión La experiencia recomienda que los evaluadores sean seleccionados

entre personas que, de alguna forma, en un futuro cercano se verán involucradas en el proyecto o entre personas que posean algún conocimiento del área de discusión. Dependiendo del tipo de revisión que va a ser realizada, será conveniente tener solamente personal técnico -en revisiones de diseño o construcción-, o una combinación de personal técnico y personal de la función -en revisiones de plan de sistemas, requerimientos, especificaciones funcionales, casos de prueba, plan de pruebas, plan de conversión-. No deben invitarse más de dos o tres evaluadores, ya que un grupo de revisión reducido trabajará con mayor eficacia que un grupo numeroso.

192

11.3.- El moderador El papel del moderador en el proceso de revisiones, a pesar de que no

consiste en identificar errores, es de gran importancia, puesto que de él depende la marcha ágil de las sesiones. En general, puede decirse que el moderador tiene a su cargo las siguientes responsabilidades:

Centrar la atención del equipo en encontrar errores. Evitar discusiones acerca de cómo resolver los problemas

encontrados. Mantener cada participante -autor, evaluador, observador-

dentro de su papel. Mantener las sesiones en movimiento, no permitir que se

invierta demasiado tiempo en un mismo punto. Estimular la participación de todos. Suavizar problemas de “ego”, evitando que se inicien

discusiones entre el equipo de trabajo y los evaluadores. Elaborar el reporte de revisión. Detener cualquier discusión, si es necesario, con el fin de

registrar convenientemente los problemas encontrados por los evaluadores.

Normalmente el papel de moderador será desempeñado por el consultor especialista en calidad. Sin embargo, es posible que, en algunas oportunidades, las limitaciones de tiempo no le permitan cumplir esa función en todas las revisiones y sea necesario que otra persona asuma su rol. En tal caso, la persona que se seleccione para desempeñarse como moderador de una revisión debe poseer las credenciales y la influencia sobre el personal, que le permitan dirigir con autoridad las sesiones de revisión. Además, deberá tenerse el cuidado de adiestrarla para que pueda cumplir a cabalidad sus funciones. 11.4.- Aceptación de productos

Dependiendo del tipo de producto que se evalúa, los evaluadores recibirán una documentación que describe, ilustra y especifica el producto a ser revisado. Por ejemplo, el material que se entregará a los evaluadores en una revisión de programas, puede estar conformado por el listado de compilación, los diseños de entrada y salid, y las especificaciones del programa. Antes de dar inicio a un proceso de revisión, el consultor especialista en calidad revisará si el material está

193

completo, de acuerdo a la metodología y los ajustes que hayan sido hechos, dadas las características especiales que pueda tener el proyecto.

12.- Pasos del procedimiento de revisión 12.1.- Sesión introductoria

El propósito de la sesión introductoria es familiarizar a los miembros del equipo de revisión con el producto que será evaluado. En esta sesión, bajo la coordinación del moderador, el equipo de trabajo describe, para los evaluadores y los observadores invitados, el trabajo que se ha realizado y expone las razones que llevaron a adoptar algún enfoque o a seguir alguna alternativa en el diseño del sistema o componente.

Durante la sesión introductoria, con el fin de aclarar dudas sobre el sistema y el producto que se presenta, el equipo de trabajo responderá cualquier pregunta hecha por los evaluadores u observadores invitados. El moderador mantendrá el control de la reunión, asignando el derecho de palabra y rechazando preguntas que no se relacionen con el objetivo de la revisión.

La presencia de observadores en la sesión introductoria puede perseguir varios objetivos, tales como: permitir que diferentes personas, tanto de informática como de la función, conozcan acerca del progreso del proyecto; permitir que personas con conocimiento de la materia hagan observaciones y preguntas que enriquezcan la presentación del equipo de trabajo e informar a diferentes personas, que no teniendo ninguna relación con el proyecto, puedan beneficiarse de los conceptos discutidos. 12.2.- Período de revisión

El período de revisión tiene como objeto permitir que los evaluadores estudien la documentación recibida, con el fin de identificar áreas de mejora o los errores que puedan existir. Esta preparación debe ser llevada a cabo en forma individual por los evaluadores, con el fin de asegurar una evaluación amplia del material y de evitar que prive un solo criterio o un solo punto de vista. Durante el período de revisión, los evaluadores anotarán comentarios y preguntas que vengan a su mente, con el fin de plantearlos en la sesión de revisión.

Para la revisión de los productos se enfatizará a los evaluadores que sigan la disciplina propuesta por el doctor M. Fagan, creador de la técnica de inspecciones, para formular preguntas de evaluación. Él la denominó “identificación del faltante-incorrecto-innecesario” (the missing-wrong-extra breakdown). Este criterio recomienda que cada área del problema sea revisada bajo tres puntos de vista:

194

¿Qué falta? ¿Qué está incorrecto? ¿Qué sobra?

12.3.- Sesión de revisión El objetivo de la sesión de revisión es identificar áreas de mejora o

errores, y registrarlos en el reporte de revisión. En esta sesión se discutirán los problemas identificados por cada uno de los evaluadores, quienes harán preguntas al equipo de trabajo, con el fin de aclarar cualquier duda. La participación de dicho equipo, en esta sesión, se limitará a contestar las preguntas que le sean hechas o a hacer alguna observación que, de acuerdo con el moderador, sea pertinente o de utilidad para aclarar el sentido de algún segmento específico del material. Durante la sesión de revisión, el moderador irá tomando nota de los problemas identificados y, al final de la misma, los sumarizará en el reporte de revisión.

Además de las tareas administrativas, el moderador deberá cumplir una función básica para el funcionamiento eficaz de la revisión: evitar la discusión de soluciones y, mantener la discusión en un tono profesional y productivo. Es posible que también asistan observadores a la sesión de revisión, aunque en este caso, normalmente, no se les da derecho a intervenir. 12.4.- Revisiones en escritorio

En el caso de reevaluaciones o de revisiones sobre productos simples, en lugar de una sesión de revisión, se acostumbra realizar una revisión en escritorio. Para ello, no se lleva a cabo ninguna reunión, sino que los evaluadores entregan al moderador los comentarios y las observaciones desarrolladas durante el período de preparación. El moderador, en estos casos, reúne los reportes de los evaluadores y los consolida en uno solo. 12.5.- Corrección y seguimiento

Una vez concluida la sesión de revisión, el moderador presenta y discute el reporte de revisión con el equipo de trabajo y el líder del proyecto, y juntos acuerdan un plan de acción para aplicar las correcciones. Una vez acordado este plan, el equipo de trabajo procederá a corregir el material, y el moderador, de acuerdo con las fechas acordadas, verificará que las mismas hayan sido hechas antes de presentar el reporte final al líder del proyecto y al coordinador del programa de revisiones.

195

En aquellos casos en que se haya encontrado un gran número de errores, es recomendable revisar de nuevo el producto, antes de darlo por terminado. Para esto, el plan de acción contemplará otra sesión de revisión, que será llevada a cabo una vez que las correcciones hayan sido hechas.

El paso de corrección y seguimiento es, sin duda alguna, el más importante de todo el procedimiento. No tendría ningún valor cumplir todos los pasos previos, si al final no hubiese seguridad de que los errores detectados han sido corregidos. Por esta razón, para el coordinador del programa de revisiones el seguimiento del plan de acción no puede quedar como una mera formalidad y no debe dudar en convocar cualquier sesión de reevaluación que pueda considerar necesaria.

Pasos del procedimiento de revisión

196

13.- Notas del PMBOK La Administración de la calidad de un proyecto incluye los procesos

necesarios para asegurar que la calidad de los resultados va a satisfacer las necesidades para el cual fue organizado.

Incluye todas las actividades relacionadas con los siguientes subprocesos:

1. Planificación de la Calidad Incluye todas las actividades destinadas a definir los estándares de calidad para el proyecto y determinar la forma de satisfacerlos.

2. Aseguramiento de la Calidad Incluye todas las actividades destinadas a evaluar el desempeño general del proyecto, con la finalidad de establecer suficiente confianza de que los resultados del proyecto van a cumplir con los estándares de calidad.

3. Control de Calidad Incluye todas las actividades destinadas a monitorizar resultados específicos del proyecto, con el fin de verificar que cumplen con los estándares e identificar las vías para eliminar las causas de desempeño insatisfactorio.

La forma como el PMBOK presenta la administración de calidad tiene la intención de ser compatible con las especificaciones de la Organización Internacional para la Estandarización –International Standards Organization (ISO)- detalladas en los estándares ISO 9000 y 10000.

Los enfoques del PMBOK también son compatibles con: Enfoques particulares como las recomendaciones de Deming,

Juran, Crosby, y otros. Enfoques como Administración Total de la Calidad –Total

Quality Assurance (TQM)-, Mejoramiento Continuo de Calidad, y otros.

La administración de la calidad de un proyecto deberá dirigirse tanto a la administración del proyecto, como al producto del proyecto.

El PMBOK establece que la calidad es “la totalidad de las características de una entidad que tienen inherencia en su capacidad de satisfacer necesidades explícitas o implícitas”.

197

El equipo administrativo del proyecto deberá estar consciente también de que la administración moderna de la calidad es un complemento de la administración moderna de proyectos. Por ejemplo, las dos disciplinas reconocen la importancia de:

La satisfacción del cliente Entender y satisfacer las necesidades de tal manera que las expectativas del cliente se cumplan o se excedan. Eso requiere una combinación de cumplimiento de las especificaciones -el proyecto tiene que producir lo que se dijo que produciría- y de utilidad -el producto o servicio producido tiene que satisfacer necesidades reales-.

Prevención sobre inspección El costo de evitar errores siempre es menor que el costo de corregirlos.

Responsabilidad administrativa La calidad requiere la participación de todos los miembros del equipo, aunque sea responsabilidad de la administración proveer los recursos necesarios para ser exitosos.

Procesos dentro de fases El ciclo repetitivo de planificar-hacer-revisar-actuar descrito por Deming y otros es muy similar a la combinación de fases y procedimientos discutidas en el capitulo del PMBOK dedicado a los Procesos de Administración de Proyectos.

Adicionalmente, las iniciativas de mejora de la calidad que emprenda la organización ejecutora –i.e., TQM, Mejoramiento Continuo, etc.- pueden mejorar la calidad de la administración del proyecto como también la calidad del producto del proyecto. 13.1.- Planificación de la calidad

La planificación de la calidad involucra identificar los estándares de calidad que son relevantes para el proyecto y determinar cómo satisfacerlos.

El equipo administrativo de un proyecto debe tener siempre presente uno de los dogmas de la administración moderna de la calidad: la calidad se incorpora planificando, la calidad no se incorpora inspeccionando.

Entre los elementos que se utilizan para planificar la calidad están los siguientes:

1. Declaración del alcance

198

2. Descripción del producto 3. Estándares y regulaciones

13.2.- Aseguramiento de calidad El subproceso de aseguramiento de la calidad incluye todas las

actividades planificadas y cumplidas para crear la confianza de que el proyecto va a satisfacer los estándares de calidad.

El subproceso de aseguramiento de la calidad se cumple muchas veces por medio de un Departamento de Aseguramiento de la Calidad u organización de título similar, aunque ello no es indispensable. 13.3.- Control de Calidad

El subproceso de control de calidad incluye todas las actividades que se cumplen para monitorizar resultados específicos del proyecto, con el fin de determinar si estos cumplen con los estándares e identificar las formas de eliminar las causas de los resultados insatisfactorios. Se deberá ejecutar a través de todo el proyecto. Los resultados de proyecto incluyen tanto resultados entregables, como resultados administrativos –i.e., desempeño de costos y programación-.

El subproceso de control de calidad lo desempeña muchas un Departamento de Control de Calidad u organización de título similar, aunque ello no es indispensable.

Algunas herramientas y técnicas para el control de calidad son: 1. Inspección 2. Tablas de control - gráficos comparativos de resultados 3. Diagramas de Pareto -ligados a la Ley de Pareto, que sostiene

que un número relativamente pequeño de causas van a causar típicamente la gran mayoría de los problemas o defectos.

4. Muestreo estadístico 5. Flujogramas 6. Análisis de tendencias