TesisRUP ISORita

Propuesta de Implantación del Sistema de Gestión ISO-9001:2000 para el proceso de Desarrollo del Software usando la
metodología del RUP.
Tesis para la obtención del grado de Maestro en Ingeniería de Calidad
Rita Maria Culebro Gómez
Título :
Propuesta de Implantación del Sistema de Gestión ISO-
9001:2000 para el proceso de Desarrollo de Software usando la
0
Ing. Rita Ma. Culebro Gómez
INTRODUCCIÓN..............................................................................................................................................2
CAPÍTULO I. LA IMPORTANCIA DE LOS SISTEMAS EN LA GERENCIA DE INFORMÁTICA DE
LA D.G.O.B.C. EN BANCO DE MÉXICO....................................................................................................12
EL BANCO DE MÉXICO............................................................................................................................12
1.1 Historia...............................................................................................................................................12
1.2 Organigrama del Banco de México....................................................................................................14
1.3 Importancia de los sistemas en la Dirección General de Operaciones de Banca Central
(D.G.O.B.C.).............................................................................................................................................17
CAPÍTULO II. LA CALIDAD Y EL PROCESO DE DESARROLLO DE SOFTWARE CON RUP.....20
EL PROCESO DE DESARROLLO DE SOFTWARE.................................................................................20
2.1 Definiciones de Calidad.....................................................................................................................20
2.2 Los sistemas informáticos en el Banco de México.............................................................................21
2.3 El desarrollo de sistemas de forma general.......................................................................................22
2.4 Problemáticas y aspectos relevantes de los sistemas de software usados en el Banco de México....23
2.5 Tendencias actuales en el proceso de desarrollo de software. El proceso unificado.........................24
2.6 El proceso de desarrollo de software en la Gerencia de Informática................................................31
CAPÍTULO III. NORMAS, VOLUNTARIA Y OBLIGATORIA................................................................87
ISO 9000........................................................................................................................................................87
3.1 Antecedentes de ISO 9000..................................................................................................................87
3.2 La norma ISO 9001:2000...................................................................................................................88
3.3 Requisitos Generales........................................................................................................................101
3.4 Estructura documental del sistema de gestión de la calidad...........................................................104
CAPÍTULO IV. DIAGNÓSTICO DE LA SITUACIÓN ACTUAL...........................................................107
DIAGNÓSTICO DEL ÁREA DE ACUERDO A LA NORMA..................................................................107
4.1 Presentación del caso.......................................................................................................................107
4.2 Diagnóstico del área de acuerdo a los cinco criterios.....................................................................109
CAPÍTULO V. PROPUESTA DE IMPLANTACIÓN DEL SISTEMA DE GESTIÓN ISO-9001:2000
PARA EL PROCESO DE DESARROLLO DE SOFTWARE...................................................................150
LA CALIDAD Y EL DESARROLLO DE SOFTWARE............................................................................150
5.1 Implantación del sistema..................................................................................................................150
5.2 Estrategia de implementación propuesta.........................................................................................151
5.3 Propuesta de implementación..........................................................................................................151
5.4 Recomendaciones de ISO 9000-3 para el proceso de desarrollo de software.................................161
5.5 Propuesta de algunos documentos requeridos por ISO 9001:2000.................................................171
CONCLUSIONES Y RECOMENDACIONES...........................................................................................238
ANEXOS.........................................................................................................................................................240
ANEXO 1.........................................................................................................................................................241
REFERENCIAS..........................................................................................................................................241
ANEXO 2.........................................................................................................................................................243
Glosario de términos....................................................................................................................................243
1
INTRODUCCIÓN
2
Antecedentes y Justificación
La tendencia de las empresas a implantar lo que se considera “calidad” en los productos,
ha alcanzado a la industria del software, esto se basa principalmente en la idea de que la
obtención de productos de mejor calidad, se asegura si los procesos de producción y
mantenimiento de los mismos la presentan.
Por lo que, también en software surge la necesidad de estandarizar esa «calidad», para
poder «medirla»; así que surgen normativas que permiten certificar el cumplimiento de
tales características en procesos y productos. De tal forma que hoy en día es imperativo
que el software se realice bajo ciertos estándares que ayuden a generar más y mejores
desarrollos, ya que el desarrollo de sistemas está bajo un enfoque de arte el cual no
permite una medición precisa del tiempo que tomará desarrollar un sistema así como el
costo que éste tendrá.
En el Banco de México los sistemas son un aspecto muy importante que deberá ser
generado y mantenido para su buen funcionamiento.
Lo anterior va de la mano con el Plan Estratégico en Materia de Información y Tecnologías
de Información en Banco de México 2002-2004, el cual, en un apartado, reafirma que:
La información y las tecnologías de información son dos aspectos muy importantes en el

funcionamiento cotidiano del Banco, y en el futuro previsible lo serán aún más. Sin
embargo, no dejan de ser aspectos accesorios cuyo desarrollo debe estar supeditado, y
alineado, al cumplimiento de los objetivos primordiales del Banco.
Por ello, el punto de partida del ejercicio de planeación estratégica para el Banco de
México debe ser la misión que la Ley le asigna. En particular, el Artículo 2 de la Ley
establece:
El Banco de México tendrá por finalidad proveer a la economía del país de moneda
nacional. En la consecución de esta finalidad tendrá como objetivo prioritario procurar la
estabilidad del poder adquisitivo de dicha moneda. Serán también finalidades del Banco
promover el sano desarrollo del sistema financiero y propiciar el buen funcionamiento de
los sistemas de pagos.
Desde esta perspectiva, todas las actividades desarrolladas en la Institución deben poder
clasificarse en aquellas que se llevan a cabo para la consecución directa de lo establecido
en el Artículo 2 de la Ley del Banco y aquellas que se realizan como soporte o apoyo a
estas actividades. Si alguna actividad no pudiera clasificarse con estos criterios,
convendría hacer una revisión minuciosa para determinar si es necesario que continúe
realizándose.
Así, el conjunto de actividades desarrolladas en el Banco puede esquematizarse como

sigue: Derivadas
de la Ley
Proveer a la economía del país de Promover el sano Propiciar el buen
moneda nacional desarrollo del funcionamiento
De
Soporte 3
Procurar la estabilidad del poder sistema de los sistemas de

adquisitivo de la moneda financiero pagos
Tecnologías de información
Recursos humanos
Recursos materiales
Control contable y presupuestal
Servicios jurídicos
Seguridad
Contraloría
Relaciones externas
Tabla 1. Plan Estratégico en Materia de Información y Tecnologías de Información en Banco de México 2002-
2004
Tecnologías de Información, es una actividad propia de soporte del Banco de México, y es

de suma importancia para su buen funcionamiento; ya que, para poder proveer al país de
moneda nacional se requiere de un área que tenga la capacidad para soportar, tanto los
sistemas de pagos, como los sistemas que éstos a su vez requieren, para mantener la
operación.
Es por ello que, dentro de la dirección General de Operaciones de Banca Central, se
encuentra la Dirección de Sistemas Operativos y de Pagos, y a su vez la Gerencia de
Informática, en donde enfocaremos este trabajo y lugar de “residencia” de los sistemas que
soportan la economía del país, razón por la cual, éstos sistemas de los que hablamos son
muy importantes en Banco de México.
La Gerencia de Informática se encarga de mantener y desarrollar sistemas que apoyen el

cumplimiento de la misión del Banco; éste proceso de desarrollo, no es sencillo dada la
naturaleza de los sistemas (cabe mencionar que existen diferentes tipos de metodologías
para el desarrollo de software, para este trabajo nos enfocaremos únicamente a la que hace
uso del RUP-Rational Unified Process, la bibliografía a este respecto se detalla en el
Anexo “1” ), de acuerdo a la experiencia de algunos programadores del Banco, cada
sistema es complejo y único, pero más complejo y caro es el proceso de mantenimiento de
sistemas, y, para sistemas con una larga vida, este costo se multiplica.
Por éstas y otras razones que se expondrán con mayor detalle en el Capítulo II, se ha
vuelto necesario implantar un modelo de calidad que permita centrar a la empresa sobre el
problema de producir con calidad y estandarizar de alguna manera el proceso de desarrollo
de software.
Dentro de las normativas mayormente conocidas, que se pueden enfocar al proceso de

desarrollo de software, encontramos a ISO-9000 y un Modelo de Madurez de las
Capacidades (CMM, Capability Maturity Model, la bibliografía a este respecto se detalla en
el Anexo “1”), ambos obedecen a la necesidad de realizar sistemas que satisfagan las
necesidades de quienes los demandan, así como proveer una certificación que avala el
estado de prácticas, técnicas, tecnologías y administración que permitan prever un cierto
nivel de calidad solicitado en el producto resultante, en este caso particular, nos
enfocaremos a la norma europea ISO-9001:2000, apoyándonos en las directrices que marca
ISO-9000-3.
Dada la relevancia de los sistemas usados en el Banco, y la necesidad de un proceso de

administración que permita al la Gerencia de Informática entrar a un proceso de mejora
continua, se pensó en proponer el sistema de gestión ISO 9001:2000 para el proceso de
desarrollo de software, por lo que se consideró importante conocer qué tan alineado se
encuentra el proceso de desarrollo de software en el Banco de acuerdo a la norma ISO
9000; para lo cual, se realizó un diagnóstico de manera general sobre los 8 principios de
4
calidad básicos, en los cuales está fundada la norma, para así encontrar los focos rojos,
obteniendo los siguientes resultados:
SE OBSERVAN EN EL
PUNTOS PRINCIPALES CONTRIBUCIÓN AL PROCESO DE DESARROLLO DE SOFTWARE: PROCESO
SÍ NO PARCIAL
Es necesario enfocar nuestros procesos al cliente. X
Debemos adquirir la cultura de servicio, orientando nuestro proceso de
desarrollo a la optimización de tiempos. Para lo cual es necesario controlar
Organización
los requerimientos de nuestros clientes, generando formatos que
enfocada al cliente.
especifiquen de manera clara y concreta el desarrollo requerido y nos
permitan determinar el tiempo de promesa de entrega. Lo cual no se
observa completamente en el proceso.
Es necesario que el personal adquiera el compromiso del cliente y se torne X
en un elemento especializado.
Liderazgo.
Es necesario esclarecer la misión, metas y objetivos del área, y que se
conviertan en las del personal.
Para poder lograr el punto anterior, debemos hacer que el personal se X
sienta parte del proyecto, que sea consciente del beneficio que trae
Involucramiento del
consigo llevar el control de los proyectos.
personal
Se deberán establecer las habilidades del personal en beneficio del
desarrollo de software.
Con el fin de obtener un control mayor del desarrollo de software., se X
deberá evaluar y dado el caso rediseñar la metodología de desarrollo de
Enfoque al proceso sistemas, de tal forma que los recursos y actividades se relacionen de la
manera más sencilla, adoptando la metodología del R.U.P. en toda la
Gerencia.
Es orientar el sistema a la administración (aprovechamiento de recursos), X
para lo cual debemos identificar los procesos que se relacionan con el
Enfoque de sistema para
proceso de desarrollo de sistemas, de tal forma que entendamos cómo
la gestión
operan y se relacionan los procesos.
Debemos gestionar los resultados, es decir, hacer que realmente se logren
los resultados. Actualmente no se observa en el proceso.
Es necesario generar reportes que reflejen la satisfacción de nuestros X
Mejora Continua clientes para que en base a ellos podamos ir organizando el ciclo de
mejora continua.
Es necesario basarnos en hechos para la toma de decisiones, por lo que es X
requisito indispensable contar con un sistema que nos proporcione
Enfoque Objetivo para la información confiable sobre las actividades del personal involucrado en el
toma de decisiones desarrollo de sistemas.
Se deberá dar seguimiento a los proyectos con la finalidad de contar con
información actualizada.
Se deberá crear una relación de ganar-ganar con proveedores de tal forma X
que tanto los desarrolladores como los clientes ganen en el proceso del
Relaciones benéficas con desarrollo de sistemas.
proveedores Programadores: Menos tiempos de retrabajos por falta de especificaciones
a detalle.
Clientes: Tiempos de promesa de entrega verídicos.
Tabla 2. Diagnóstico general del proceso de desarrollo de software sobre los 8 principios de calidad.
Como se observa en la tabla de arriba, en la Gerencia se cumplen de forma parcial o no los

ocho principios de calidad, en los cuales se basa la norma ISO 9001:2000.
¿Por qué usar un estándar de calidad como ISO-9001:2000 en el proceso de desarrollo de
software? Porque provee una forma clara de estructurar la operación facultando a la gente,
reduce el papeleo y la burocracia, te soporta en la búsqueda de la satisfacción de tu cliente,
y a largo plazo te ayuda en la sobre vivencia de tu negocio; y digo sobre vivencia, porque
se tiene una situación preocupante en la industria del software para la cual, la Gerencia
debe prepararse, ya que se menciona que:
A medida que los costos de hardware disminuyen, el ritmo de la demanda por aplicaciones
de software comienza a incrementarse rápidamente. El repertorio actual de software
continúa creciendo, y el esfuerzo por darle mantenimiento también. Simultáneamente,
existe una considerable escasez de profesionistas de software calificados. Aunado a esto,
el desarrollo actual de software se ve caracterizado por:
5
 Planes de trabajo estimado y de costos que son muy pocos certeros.

 Productos de calidad muy baja.
 Un ritmo de producción incrementándose de manera más lenta que la demanda.
Se ha hecho referencia a esta situación en repetidas ocasiones como la “crisis del

software”. Según Everald Mills, especialista en métricas de software del Software
Engineering Institute (S.E.I.).
1
Por otro lado, hay un punto importante, que es “satisfacer las necesidades del cliente”, las
cuales son necesidades implícitas y explícitas; en otras palabras no importa solo lo que
nosotros pensemos, si no lo que tu cliente piensa, y ese es un reto que la industria del
software debe enfrentar.
Dado que las exigencias y necesidades del cliente son continuamente variantes, y
mayormente demandantes de mejores productos y servicios, está en nosotros asegurarnos
que la organización sea lo suficientemente rápida y flexible para responder a los retos
presentados por los clientes cuya sofisticación aumenta diariamente y más aún en el ámbito
de la informática.
Es simple, si no satisfacemos a nuestros clientes, nos quedamos sin negocio. Actualmente,

las empresas tanto de la iniciativa privada, como de la pública han iniciado una labor de
certificación, por lo que se propone iniciar esta labor para el proceso de desarrollo de
software en Banco de México enfocándonos en la norma ISO-9001:2000.
Lo anterior, obedece por un lado a orientación del mercado hacia la Calidad y por otro, al
beneficio real que se obtiene de esto, sobre todo porque se trata con el difícil proceso de
desarrollo de software, ya que se sostiene de seres humanos, no de máquinas que puedan
ser programadas y obtener resultados en un tiempo determinado pudiendo así generar
indicadores exactos y realizar los ajustes necesarios dado el caso; es por ello que en la
actualidad no existen muchas empresas que hayan certificado este proceso ya sea bajo la
norma ISO 9000 u otra aplicable.
Es un hecho que el trabajar para obtener una certificación, optimiza cualquier proceso por
más difícil que parezca, y éste no puede ser la excepción, por lo que en el Banco de
México, se propone trabajar para obtener esta certificación, de tal forma que camino hacia
esta meta, se regularice el proceso y se cumpla con las especificaciones y necesidades de
los clientes tanto internos (Áreas del mismo Banco de México) como externos (Bancos del
país entre otras instituciones).
Objetivo General:
Desarrollar una propuesta para el proceso de desarrollo del software (que hace uso de la
metodología RUP), que cumpla con los requerimientos que le sean aplicables de la norma
ISO 9001:2000 en la Gerencia de Informática del Banco de México.
Objetivos Específicos:
a) Iniciar una labor de investigación sobre el proceso de desarrollo de software que
hace uso de la metodología del RUP en el Banco de México
1
MILLS, EVERALD E., Software Metrics, Software Engineering Institute, SEI-CM-12-1.1 (1998).
6
b) Realizar un ejercicio de auditoria sobre el proceso de desarrollo de software con el

objetivo de encontrar los puntos de incumplimiento, de acuerdo a la norma ISO
9001:2000
c) Enfocar la norma ISO-9001:2000 al proceso de desarrollo de software, explicando
cómo los estándares pueden ser usados en el proceso de manejo de calidad
d) Introducir los conceptos esenciales del manejo de calidad y los estándares ISO-
9000
e) Apoyar el trabajo en las directrices que se marcan en el documento ISO-9000-3, el
cual, se emitió en 1997 para ayudar a las organizaciones a aplicar la ISO 9001:1994;
para el desarrollo, suministro, instalación y mantenimiento de software, aquí,
únicamente, se enfoca en algunas partes al software.
f) Proponer un plan de trabajo para la implantación de la norma.
Alcance y Trascendencia:
En el presente trabajo, revisaremos la norma, enfocándonos al proceso de desarrollo de
Software que usa la metodología del RUP.
Se espera que la propuesta de implantación de este sistema de calidad se oriente a

la reducción de fallos durante el proceso, pero principalmente a la detección de errores y
mejora del proceso, propiciando una mejor comunicación con el cliente en vías de aumentar
su confianza y satisfacción, ayudando así a que otras empresas en donde se desarrolle
software, ya sean públicas o no, puedan encontrar material para apoyarse en el proceso de
implantación de la norma, de tal forma que este trabajo les sirva de guía o referencia.
Planteamiento del Problema:

El Banco de México tiene dentro de sus Direcciones la Dirección General de Operaciones
de Banca Central, pertenece a ella la Dirección de Sistemas Operativos y de Pagos, dentro
de esta Dirección, está entre otras Gerencias, la Gerencia de Informática, y una de sus
funciones es el desarrollo y mantenimiento de sistemas.
Estos sistemas, son los que soportan la operación de las transacciones principales del
sistema financiero mexicano, por lo que su correcta y oportuna operación es de vital
importancia para el país. Esto requiere de sistemas bien diseñados y creados en la
Gerencia, y el origen de esta situación radica en el proceso de desarrollo de software, es
por ello, que, para asegurar el buen y continuo funcionamiento de los sistemas se propone
asegurar el proceso bajo un modelo de calidad.
Es importante proveer de un entendimiento básico de la norma ISO 9000:2000, sus

beneficios y como aplicar la norma al proceso de desarrollo de software, sugerir lo que se
requiere para satisfacerla. Las series ISO 9000 se consideran una excelente guía, que
proveen principios de administración de la calidad y prácticas a partir de las cuales se
puedan construir sistemas de calidad, así como, proveen la base a partir de la cual se
puedan alinear procesos para el desarrollo de productos o servicios con calidad, es decir,
es un catalizador hacia la calidad, dado que permite conocer las necesidades de los clientes
y eso, es de suma importancia para todos los desarrolladores de sistemas, ya que es la
base de su trabajo.
Las organizaciones que han implementado de manera conciente y profunda sistemas de

administración de la calidad en el software, han quedado estáticas por los resultados
logrados. Los beneficios directos que esperaban se han logrado y los indirectos, tales como
incremento en la motivación del personal y la reducción de la frustración por parte de la
7
administración son ejemplos de bonos anticipados. Las organizaciones que se encuentran

certificadas reportan que han ganando más trabajo con menos esfuerzo y por consiguiente
una mayor credibilidad en el mercado. Los clientes encuentran mayores beneficios al hacer
negocios con empresas certificadas, por lo que este proceso se vuelve repetitivo. El
certificar el proceso bajo un estándar internacional, da a la organización mayor credibilidad
a los ojos de los administradores, clientes y personal. La reputación de la empresa crece,
así como la percepción de la calidad en la comunidad.
Por lo anterior, se decidió enfocar nuestros esfuerzos a desarrollar una propuesta para el
proceso de desarrollo del software (que hace uso de la metodología RUP), que cumpla con
los requerimientos que le sean aplicables de la norma ISO9000:2000 en la Gerencia de
Informática del Banco de México.
Hipótesis:
La implementación de un sistema de calidad en el proceso de desarrollo de software que
hace uso de la metodología del RUP, promueve la disminución de errores, así como
retrasos en la entrega de los sistemas de software.
Metodología:
En el presente trabajo, se revisó la norma, considerando los antecedentes del Banco de
México y del proceso de desarrollo de Software.
El trabajo se estructura apoyándose en las directrices impartidas por la norma ISO-9000-3
como guía para la propuesta de aplicación de la norma ISO-9001:2000 orientándola al
desarrollo, suministro y mantenimiento de "software", especialmente a actividades propias
de un ambiente de producción de software.
Una acotación inicial es que si bien ISO 9000 tiene vinculación con situaciones donde se
desarrolla "software" específico como parte de un contrato, los conceptos descritos por
ella son aplicables a situaciones no formalmente contractuales como pueden ser el sector
informático de una empresa con sus clientes internos.
De manera general, la estrategia seguida dada la situación mostrada en la Tabla 2, fue:

 Investigación del proceso de desarrollo de software en el Banco de México,
que hace uso de la metodología de RUP.
 Búsqueda de fuentes bibliográficas y en internet, que explicaban la
metodología RUP, así como la norma ISO:9001:2000 y las directrices
marcadas en la ISO:9000-3
 Explicación del proceso de desarrollo de software, de una forma sencilla y
entendible.
 Análisis de la norma ISO-9001:2000 para aplicarla en el proceso de
desarrollo.
 Realización de una auditoria en base a los requerimientos que marca la
norma ISO 9000:2000, al proceso que usa la metodología RUP para el
 Evaluación mediante un cheklist, de los resultados obtenidos de la auditoria
(Ver Anexo 2).
8
 Planeación de las actividades a realizar con base a los resultados obtenidos

de la auditoria.
 Realización de la propuesta de implementación de la norma, es decir,
señalización de las acciones a seguir para alinear el proceso hacia la
certificación, o bien las recomendaciones, según sea el caso.
Este trabajo aborda en el Capítulo I, La importancia de los sistemas en la Gerencia de

informática de la Dirección General de Operaciones de Banca Central en Banco de México,
desde el foco de la historia que ha tenido el Banco, su razón de ser y cómo está
estructurado, para remarcar la importancia de los sistemas que se generan y mantienen en
esta área. Para después seguir en el Capítulo II con, La calidad y el proceso de desarrollo
de software con RUP, que es la metodología de desarrollo usada en la Gerencia de
Informática, esta metodología se explicará en este capítulo con mayor detalle, así como las
problemáticas encontradas en el desarrollo de software; en el Capítulo III se presenta la
Propuesta de implantación del sistema de gestión ISO 9001:2000 para el proceso de
desarrollo de software, en donde se presenta el caso y los requisitos de la norma; los
Resultados de esta propuesta se presentan el Capítulo IV, y finalmente las Conclusiones y
Recomendaciones en el Capítulo V.
9
CAPÍTULO I
LA IMPORTANCIA DE LOS SISTEMAS
10
Capítulo I. LA IMPORTANCIA DE LOS SISTEMAS
1.3 Importancia de los sistemas
1.4 Comentarios.
En este capítulo pudimos observar que la historia del Banco ha sido además de interesante,
enriquecedora, y decisiva para el establecimiento actual de los objetivos a cumplir en el
Banco.
11
Propuesta de Implantación del Sistema de Gestión ISO-9001:2000 para el proceso de Desarrollo del Software usando la metodología del
RUP.
CAPÍTULO II
LA CALIDAD Y EL PROCESO DE DESARROLLO DE SOFTWARE CON RUP.
12
RUP.
Capítulo II. LA CALIDAD Y EL PROCESO DE DESARROLLO DE SOFTWARE CON RUP.
Este capítulo trata la definición de calidad para empezar a situarnos en este tema, por otro lado
se expone la realidad del desarrollo del software en la industria y posteriormente se especifica
para el Banco, particularmente en la Gerencia de Informática, ya que el proceso de desarrollo en
la mayoría de los proyectos del Banco de México, se han realizado por la experiencia, o bajo
otro tipo de metodologías, sin embargo actualmente, se ha iniciado una labor para adoptar una
metodología que pueda eficientar el proceso, esto en un futuro, sería a nivel institucional,
logrando así las metas propuestas en tiempo y recursos; en pro de la satisfacción de sus
clientes, esto suena menos complejo para otro tipo de industrias, no es precisamente así para el
proceso de desarrollo de software, por lo que, para efectos de este trabajo, nos enfocaremos
únicamente a aquellos desarrollos que se efectúan bajo la metodología de RUP, que es en primer
lugar, un proceso de desarrollo de software, es decir, es “el conjunto de actividades necesarias
para transformar los requisitos de un usuario en un sistema de software” 2. Sin embargo, el
proceso unificado es más que un simple proceso; es un marco de trabajo genérico que puede
especializarse para una gran variedad de sistemas de software, para diferentes áreas de
aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños
de proyecto, esto nos ayudará a desarrollar la propuesta expuesta en el Capítulo III.
EL PROCESO DE DESARROLLO DE SOFTWARE.
2.1 Definiciones de Calidad.

Tal vez sería importante antes de continuar, señalar la definición de Calidad, dado que es una
palabra en la que se basa nuestro trabajo.
A lo largo del tiempo, se han creado varias definiciones de Calidad, pero vamos a citar la
definición que marca ISO (International Organization for Standarization):
Calidad: Definición según ISO 9000:2000

" Calidad: Grado en el que un conjunto de características inherentes cumple con los requisitos."
La norma hace una serie de aclaraciones que considero, son importantes mencionar:
Características: Rasgo diferenciador, inherente de un producto, proceso o sistema relacionado
con un requisito.
Una característica puede ser inherente o asignada, cualitativa o cuantitativa. Existen varias
clases de características, tales como, físicas, sensoriales, de comportamiento, de tiempo,
ergonómicas, funcionales.
Requisito: Necesidad o expectativa establecida, generalmente implícita u obligatoria.
Generalmente implícita significa que es habitual o una práctica común, para la organización, sus
clientes y otras partes interesadas que la necesidad o expectativa bajo consideración esté
implícita.
Otra definición es la de Joseph Juran, él, define a la calidad como idoneidad o aptitud para el uso,
esta calidad se determina por características del producto que el usuario puede reconocer como
beneficiosas, de igual forma las características son de diversos tipos, tecnológicas, sensoriales,
con relación al tiempo, contractuales, éticas.
Con esto vemos que ya inicia una orientación hacia el cliente, como lo marca la definición según
la norma.
2
IVAR JACOBSON, GRADY BOOCH, JAMES RUMBAUGH, El proceso unificado de desarrollo de
software, Adison Wesley, España, 2000, pp.4
13
RUP.
De igual forma Armand Feigenbaum, quien, orienta su definición hacia el cliente, quien es al que
debe satisfacerse las expectativas, de acuerdo al conjunto de características del producto (bien
o servicio) de marketing, ingeniería, fabricación y mantenimiento.
Por lo que por un lado tenemos una orientación hacia el cliente, pero por otro lado, hacia el
producto, esto lo vemos con Philip Crosby, quien define calidad como cumplimiento de unas
especificaciones o la conformidad a uso requisitos, estos son del diseño a los requisitos del
cliente, del bien fabricado y entregado a los diseños y especificaciones y del servicio con las
prestaciones pactadas con el cliente, esto con una base en la prevención y orientado al alcance
de las conformidades.
Edwards Deming ve la calidad como un grado predecible de uniformidad y fiabilidad a bajo costo
y adecuado a las necesidades del mercado, con un enfoque estadístico; Genichi Taguchi concibe
la calidad como, las pérdidas mínimas para la sociedad en la vida del producto, esto con un
enfoque de costos.
Dado lo anterior, en lo siguiente se entenderá Calidad como cumplir con los requisitos del
cliente.
2.2 Los sistemas informáticos en el Banco de México.

Los objetivos en una empresa son los que la guían para cumplir su misión, y representan el punto
de llegada, es el fin hacia el cual nos dirigimos de manera intencionada, por lo que ayudan a
determinar qué acciones a emprender, en el Banco de México, se tienen objetivos de operación,
éstos son: objetivos de operación como Autoridad y como Empresa y tanto en la operación como
autoridad como en la operación como empresa, la información es el insumo más importante para
el funcionamiento de la Institución.
No sólo es indispensable que el personal cuente con la información que requiera para el
adecuado desempeño de sus funciones, sino que también se debe proveer al público con todos
los elementos para que pueda entender y evaluar las acciones de la autoridad. Esto último es
fundamental para lograr el apoyo a las políticas del Banco que se requiere para su eficacia en un
contexto en el que la política monetaria se realiza a través de instrumentos indirectos y de
objetivos de inflación.
En esta materia, tanto en los aspectos internos al Banco como en los externos, el objetivo es que
la información esté siempre disponible para quien la requiera. Igualmente importante es que la
información se provea de manera oportuna, que sea confiable y de fácil consulta, para lograr
esto, es necesario contar con sistemas que sean rápidos, seguros, y que tengan la capacidad de
cubrir estas necesidades de información.
En los últimos años, el Banco ha promovido la realización de sus funciones en un contexto

caracterizado por: a) un más amplio acceso público a la información, y mayor transparencia y
rendición de cuentas a la sociedad, b) innovaciones continuas en el sistema financiero que lo
hacen más sofisticado e integrado y c) un uso creciente de tecnología en todos los procesos.
La información juega un papel central en cada uno de estos puntos, por lo que constituye uno de
los activos más importantes del Banco. Con el fin de sacar el máximo provecho de este activo,
se requiere que la información sea acopiada, compartida, distribuida, procesada y almacenada de
maneras más eficientes que las que actualmente se utilizan. Para esto, son necesarios sistemas
con una conectividad más robusta y una comunicación más efectiva al interior del Banco.
En particular, las estrategias de desarrollo de sistemas en el Banco, están orientadas a la

consolidación y modernización de los sistemas de transacción y de operación del Banco, con
servicios informáticos eficientes que faciliten los resultados deseados. Las estrategias apoyan al
Banco en el cumplimiento de su mandato legal proponiendo cómo las tecnologías de información
pueden ser utilizadas de manera creativa para ofrecer servicios y posibilitar el trabajo en equipo.
Asimismo aseguran que la inversión en tecnología esté alineada con la misión del Banco.
14
RUP.
La infraestructura informática del Banco ha mejorado sustancialmente en los últimos años. Al día
de hoy se cuenta con una infraestructura tecnológica avanzada. Se ha adquirido y desarrollado
software especializado para bases de datos institucionales y se han emprendido ambiciosos
programas de capacitación. Se han hecho esfuerzos para promover la estandarización de las
tecnologías de información a lo largo de la Institución.
Asimismo, las áreas han trabajado fuertemente para modificar sus sistemas buscando simplificar
sus procesos y hacer mejor uso de la infraestructura que se tiene.
2.3 El desarrollo de sistemas de forma general.

Por otro lado, existen diferentes metodologías usadas para el desarrollo de software en el Banco
de México, actualmente se está trabajando sobre una, que es “el proceso unificado de desarrollo
de software” (RUP, por sus siglas en ingles), que promete ser la única metodología a utilizar,
ésta es relativamente nueva en el área de desarrollo del Banco, por consecuencia, es necesaria
una labor de investigación más profunda, pero antes de entrar al detalle del RUP, es necesario
entender la complejidad del proceso de desarrollo de software, para esto me gustaría entrar un
poco a detalle.
Un proceso define quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo. En
la ingeniería del software el objetivo es construir un producto de software o mejorar uno
existente. Un proceso efectivo proporciona normas para el desarrollo eficiente de software de
calidad. Captura y presenta las mejores prácticas que el estado actual de la tecnología permite.
En consecuencia, reduce el riesgo y hace el proyecto más predecible. El efecto global es el
fomento de una visión y una cultura comunes.
Es necesario un proceso que sirva de guía para todos los participantes – clientes, usuarios,
desarrolladores y directores ejecutivos. No nos sirve ningún proceso antiguo; necesitamos uno
que sea el mejor proceso que la industria pueda reunir en este punto de la historia. Por último,
necesitamos un proceso que esté ampliamente disponible, de forma que todos los interesados
puedan comprender su papel en el desarrollo que se encuentran implicados.
Un proceso de desarrollo de software debería también ser capaz de evolucionar durante muchos
años. Durante esta evolución debería limitar su alcance, en un momento de tiempo dado, a las
realidades que permitan las tecnologías herramientas, personas y patrones de organización.
o Tecnologías. El proceso debe construirse sobre las tecnologías –lenguajes de
programación, sistemas operativos, computadores, estructuras de red, entornos de
desarrollo, etc.- disponibles en el momento que se va a emplear el proceso.
o Herramientas. Los procesos y herramientas deben desarrollarse en paralelo. Las
herramientas son esenciales en el proceso. Dicho de otra forma, un proceso ampliamente
utilizado puede soportar la inversión necesaria para crear herramientas que lo soporten.
o Personas. Un creador del proceso debe limitar el conjunto de habilidades necesarias para
trabajar en el proceso a las habilidades que los desarrolladores actuales poseen, o
apuntar aquellas que los desarrolladores puedan obtener rápidamente. Hoy es posible
empotrar en herramientas de software técnicas que antes requerían amplios
conocimientos.
o Patrones de organización. Aunque los desarrolladores de software no pueden ser
expertos tan independientes como en otro tipo de industrias, están muy lejos de los
trabajadores autómatas en los cuales Frederick W. Taylor basó su “dirección científica”
hace cien años. El creador del proceso debe adaptar el proceso a las realidades del
momento.
Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias. Además el
equilibrio debe estar presente no sólo ahora, sino también, en el futuro. El creador del proceso
debe diseñar el proceso de forma que pueda evolucionar, de igual forma que el desarrollador de
software intenta desarrollar un sistema que no sólo funcione este año, sino que evoluciona con
éxito en los años venideros. El desarrollo de un producto nuevo es bastante arriesgado en sí
mismo como para añadirle el riesgo de un proceso que esté poco validado por la experiencia de
su uso. En estas circunstancias, un proceso puede estar estable. Sin equilibrio de tecnologías,
15
RUP.
herramientas, personas y organización, el uso del proceso sería bastante arriesgado, por lo que
en el trabajo, se tratará la importancia del proceso de desarrollo de software, para poder
comprender el origen de su dificultad.
2.4 Problemáticas y aspectos relevantes de los sistemas de software

usados en el Banco de México.
No obstante lo anterior, el Banco todavía está lejos de la posición deseada. La información,
insumo primordial para las labores del Banco, aún se encuentra almacenada en bases de datos
fragmentadas y aisladas. Esta situación representa un serio obstáculo a los flujos de información
y a los beneficios que de ellos se derivan.
Los sistemas de empresa del Banco todavía muestran rezagos importantes. El problema principal
es que son sistemas propietarios, obsoletos en muchos casos, y cuya falta de automatización da
lugar a actividades con un exceso de intervención manual. Asimismo, a muchos de estos
sistemas les falta documentación, metodología de desarrollo y procedimientos de contingencia.
La seguridad de la operación de la Institución es una prioridad absoluta. Existe un grado

razonable de seguridad contra ataques del exterior, si bien hay deficiencias en la protección a
ataques desde el interior, principalmente por insuficiencias en los esquemas de autenticación de
usuarios y cifrado de información.
Por otra parte, las actividades de empresa del Banco deben ser homogéneas a lo largo de la
Institución, sujetas a una normatividad sencilla y realizadas de manera transparente,
contribuyendo a lograr una operación auditable en todo momento.
La actividad informática deberá construirse sobre procesos eficientes, los cuales a partir de
información fuente, apoyados en una infraestructura moderna, operados por personal calificado y
motivado e inmersos en un ambiente de seguridad y coordinación institucional, generan la
información necesaria para la toma de decisiones.
Para mantener a los sistemas en operación en un estado óptimo y prever con tiempo sus mejoras
o reemplazos, así como para ofrecer el mejor servicio posible a los usuarios, deberá hacerse un
monitoreo continuo y una evaluación periódica de los sistemas y servicios con base en un
conjunto de indicadores desarrollados para tal fin.
El papel crítico que juega el Banco de México en los sistemas financieros y de pagos, obligan a
que su operación esté sujeta a los más altos estándares de seguridad. No sólo debe prevenirse
que personas no autorizadas tengan acceso a información o a los sistemas de operación, sino que
la continuidad operativa también esté garantizada. Los sistemas del Banco deben estar en
condiciones de proveer servicios las 24 horas del día de los 365 días del año.
Como se mencionó anteriormente, el problema principal, es que se desarrollaron sistemas

propietarios, sistemas hombre en la Gerencia de Informática, en donde un sistema depende al
100% de la persona que lo desarrolló, ya que se carece de documentación, la metodología de
desarrollo no estaba bien definida, y mucho menos los procedimientos de contingencia.
Con base en esto se decidió a nivel institucional que se desarrollarían sistemas bajo la
metodología del proceso unificado de desarrollo de software (Rational Unified Process, RUP).
En la actualidad, en la Gerencia de Informática, ya se desarrollan sistemas bajo esta metodología,
y la propuesta en este trabajo se orienta a estandarizar el proceso de desarrollo de software,
para que en un futuro, los sistemas que sean desarrollados bajo esta metodología se encuentren
bajo un proceso formal de mejora contínua.
16
RUP.
2.5 Tendencias actuales en el proceso de desarrollo de software. El

proceso unificado.
2.3.1 El proceso unificado de desarrollo de software, RUP.
El proceso unificado de desarrollo de software o Rational Unified Process, RUP, por sus siglas
en inglés, es antes que nada, un proceso para desarrollar sistemas, es un marco de trabajo, que
va más allá de simplemente transformar los requerimientos de un usuario en un desarrollo de
software, está pensado para todo tipo de desarrollos, es decir, puede utilizarse para desarrollar
sistemas con diferentes tipo de lenguajes, tamaño de organizaciones y de proyectos.
Es importante señalar antes de continuar que, el desarrollo de sistemas con RUP, hace uso de
UML (Lenguaje Unificado de Modelado – Unified Modeling Language) para preparar todos los
esquemas de un sistema de software, es decir, UML es una parte principal del RUP.
El proceso unificado de Rational, es un proceso de ingeniería de software. Proporciona un

acercamiento disciplinado a la asignación de tareas y responsabilidades en una organización de
desarrollo. Su propósito es asegurar la producción de software de alta calidad que se ajuste a las
necesidades de sus usuarios finales con costos y tiempos predecibles.
RUP es una metodología de desarrollo de software cuyo objetivo es integrar los aspectos de
desarrollo de software para desarrollar todo tipo de sistemas.
2.3.2 Introducción al RUP.
Es necesario entender las bases teóricas o claves en las que se fundamenta el RUP, de las
cuales, es importante destacar que es un proceso iterativo e incremental, es decir, el proyecto
se hace en iteraciones(éstas son un conjunto de actividades que se llevan a cabo, de acuerdo a
un plan de iteración, y unos criterios de evaluación, esto genera una versión), donde cada una de
las iteraciones que se desarrollan contienen trabajo y éstas iteraciones se organizan o componen
cuatro fases(inicio, elaboración, construcción, transición), a su vez de éstas fases se generan
productos/artefactos, o “artifacts” como se les llama en el RUP. Pero para generar los productos
deseados, deben desarrollarse flujos de trabajo con sus objetivos.
Ahora, los puntos importantes de manera general en el RUP, son tres, que es dirigido por casos
de uso, centrado en la arquitectura, e iterativo e incremental. Estas tres partes clave son las que
hacen diferentes esta forma de desarrollar software a las demás.
Las características principales de RUP son:
 Dirigido por casos de uso

La razón de ser de un sistema de software es servir a usuarios, los usuarios pueden ser
personas o bien otros sistemas, para poder servir a este usuario debe realizar cierta
secuencia de acciones que proporciona una resultado importante, una interacción de este tipo
es caso de uso.
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al
usuario(cliente) un resultado significativo, una facilidad que se provee al usuario. Varios
casos de uso, constituyen el modelo de casos de uso, en el cual se describe la funcionalidad
total del sistema.
Desde un punto de vista práctico, se puede decir que los casos de uso son una herramienta
que ayuda a especificar los requerimientos en un sistema, esto se logra contestando la
pregunta ¿qué debe hacer el sistema para cada usuario?; dado que en los casos de uso se
establecen los requisitos del sistema, éstos guían el desarrollo del sistema.
Basándose en el modelo de casos de uso los desarrolladores crean sus propios modelos para
el diseño e implementación del sistema, y a su vez las personas encargadas de las pruebas
17
RUP.
del sistema prueban la implementación para garantizar que los componentes del modelo de
implementación, implementan de manera adecuada los casos de uso, es por ello que el
proceso de desarrollo es dirigido por casos de uso, porque no solo se inicia con ellos, si no
que guían la arquitectura del sistema a la vez que avanzan los casos de uso, avanza el ciclo
de desarrollo de sistemas.
 Centrado en la arquitectura
La arquitectura involucra los elementos más significativos del sistema, es como en medicina,
una radiografía del cuerpo humano, se contemplan los huesos desde varias vistas y ángulos,
análogamente, la arquitectura en un sistema de software, es una radiografía del sistema que
se está desarrollando, debe ser lo suficientemente completa como para que todos los
involucrados en el desarrollo tengan una visión clara de lo que están construyendo, pero, a la
vez, debe ser lo suficientemente simple como para que si se le quita algo importante del
sistema, no haya problema si se queda sin especificar. Se representa mediante varias vistas
que se centran en aspectos concretos del sistema, abstrayéndose de lo demás.
Es importante remarcar que el desarrollo de casos de uso va de la mano con la arquitectura,
uno a otro se relacionan. Debe existir interacción entre los casos de uso como entre la
arquitectura, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo y por
otro lado la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, en
realidad ambos deben evolucionar de la mano.
 Iterativo e incremental
Para que un proyecto sea más manejable, se recomienda separarlo en ciclos. Cada ciclo tiene
fases, para cada una de las cuales debe considerarse como un proyecto pequeño el cual está
constituido por una o más iteraciones de las actividades principales básicas de cualquier
proceso de desarrollo.
De manera general el RUP divide el proceso en cuatro fases, dentro de las cuales, se llevan
a cabo varias iteraciones de acuerdo al proyecto y en las destacan las actividades.
18
RUP.
Figura 2..1. Diagrama del RUP.
De las características principales mencionadas anteriormente, no debemos olvidar las

siguientes:
 Desarrollo basado en componentes.

El desarrollo de sistemas también se divide en componentes, estos componentes tienen a su
vez, interfaces las cuales posteriormente serán ensambladas para generar un sistema. Esto
permite que se vaya desarrollando el software de acuerdo a la maduración de sus
componentes.
 Uso del Lenguaje Unificado de Modelado

Con la metodología, se usa un lenguaje de modelado, para el desarrollo de los modelos, el
cual es UML, este lenguaje estándar se usa para visualizar, especificar, construir y
documentar los artefactos de un sistema.
 Proceso integrado
Para tener un proceso integrado, se parte de la base que debe existir una estructura que
abarque los ciclos, fases, flujos de trabajo, mitigación de riesgos, control de calidad gestión
del proyecto y control de la configuración; RUP establece una estructura que integra todos
los aspectos anteriores.
La estructura del RUP se define también en base a los siguientes cuatro elementos:
1. Roles. Se establecen para responder al ¿quién?.
Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de
individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos
roles, así como un mismo rol puede ser representado por varias personas. La
responsabilidad de un rol son tanto el llevar a cabo un conjunto de actividades como el
ser “dueño” de un conjunto de artefactos.
2. Actividades. Se establecen para responder el ¿cómo?.
Una actividad de un trabajador en específico, es una unidad de trabajo que se solicita a
una persona de acuerdo al rol que desempeñe. Las actividades tienen un objetivo
concreto, normalmente expresado en términos de crear algún producto.
3. Productos. Se establecen para responder el ¿qué?.
19
RUP.
Un artefacto o llamado también producto, es aquella información que es producida,

modificada o usada por un proceso. Son los resultados tangibles de un proyecto.
4. Flujos de trabajo. Se establecen para responder al ¿cuándo?.
En RUP, se definan varios diferentes grupos de trabajo, entre los que destacan los de
proceso y los de apoyo. Las iteraciones a realizar consistirán en la ejecución de estos
flujos de trabajo con una mayor o menor intensidad, esto depende de la fase e iteración
en la que se encuentre el proyecto.
Roles
Actividad
Artefacto/
Producto
Figura 2.2. Roles, Actividades y Artefactos en RUP.
2.3.3 La vida del Proceso Unificado.
El proceso unificado se repite a lo largo de una serie de ciclos, y éstos ciclos son los que forman
la vida de un sistema.
Tiempo
Inicio Elaboración Construcción Transición
Iteración Iteración Iteración Iteración

… ... ... ... ...
#1 #2... #n-1 #n...
Versiones
Figura 2.3. Un ciclo con sus fases e iteraciones.
2.3.4 Fases del RUP.

Como se puede apreciar en la Figura 1, el RUP, se divide en 4 fases, que son:
 Incepción (Inception)/Inicio.
20
RUP.
 Elaboración
 Construcción
 Transición
A continuación, se describirán brevemente cada una de las fases.
 Incepción o inicio.
La fase de inicio, trata de responder a las siguientes preguntas: ¿cuál es elobjetivo del
proyecto?, ¿es factible hacerlo?, ¿sería mejor construirlo o comprar algunos componentes o
partes?, ¿cuánto va a costar?, entre otras. En este punto no se trata de recopilar todos los
requisitos del producto, se trata de explorar el problema lo justo para decidir si es mejor
continuar o dejarlo. Este punto no se lleva más de una semana en decidirlo.
Los objetivos son:

a) Establecer el ámbito del proyecto y sus límites.
b) Encontrar los casos de uso críticos del sistema, los escenarios básico que definen la
funcionalidad.
c) Mostrar al menos una arquitectura candidata para los escenarios principales.
d) Estimar el coste en recursoso y tiempo de todo el proyecto.
e) Estimar riesgos, los puntos de incertidumbre.
Los productos a generar deben ser:

i) Visión del negocio: Describe los objetivos y restricciones a alto nivel.
ii) Modelo de casos de uso.
iii) Especificación adicional: Requisitos no funcionales.
iv) Glosario: Terminología clave del dominio.
v) Lista de riesgos y planes de contingencia.
vi) El caso del negocio (business case).
vii) Prototipos exploratorios para probar conceptos o la arquitectura candidata.
viii) Plan de iteración para la primera iteración de la fase de elaboración.
ix) Plan de fases.
Cabe mencionar, que no todos los productos son obligatorios, ni deben completarse al 100%,
se debe tener en cuenta el objetivo de la fase de inicio.
Al terminar la fase de inicio, se deben comprobar los siguientes criterios de evaluación para
continuar:
a) Todos los interesados en el proyecto, coinciden en la definición del ámbito del sistema y
las estimaciones de la agenda.
b) Entendimiento de los requisitos, evidenciado por la fidelidad de los casos de uso
principales.
c) Las estimaciones de tiempo, costo y riesgo son creíbles.
d) Comprensión total de cualquier prototipo de la arquitectura desarrollado.
e) Los gastos hasta el momento se asemejan a los planeados.
En el dado caso que el proyecto no pase los criterios, es necesario plantearse abandonarlo o
repensarlo a una mayor profundidad.
 Elaboración.
El propósito de esta fase, es analizar el problema, establecer los cimientos de la arquitectura,
desarrollar el plan del proyecto y eliminar los mayores riesgos. Cuando se finaliza esta fase,
se llega al punto de no retorno del proyecto, a partir de este momento, hemos pasado las dos
primeras fases, para afrontar la fase de construcción, que es costosa y arriesgada. Es por
ello que esta fase es de gran importancia.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en las
iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los
casos de uso críticos identificados en la fase de inicio.
21
RUP.
También debe demostrarse que se han evitado los riesgos más graves.
Los objetivos son:

a) Definir, validar y cimentar la arquitectura.
b) Completar la visión.
c) Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en
sucesivas iteraciones. Debe incluir los costos si es necesario.
d) Demostrar que la arquitectura propuesta soportará la visión con un costo y tiempo
razonable.
Al finalizar esta fase, se tendrán los siguientes productos:

i) Un modelo de casos de uso completa al menos hasta el 80%, esto es, todos los casos
y actores identificados, la mayoría de los casos desarrollados.
ii) Requisitos adicionales.
iii) Descripción de la arquitectura de software.
iv) Un prototipo ejecutable en la arquitectura.
v) Lista de riesgos y caso de negocio revisados.
vi) Plan de desarrollo para el proyecto.
vii) Un caso de desarrollo actualizado que especifica el paso a seguir.
viii) Posiblemente un manual de usuario preliminar.
La forma de aproximarse a esta fase debe ser tratar de abarcar todo el proyecto con la
profundidad mínima. Sólo se profundiza en los puntos críticos de la arquitectura o riesgos
importantes.
En esta fase, se actualizan todos los productos de la fase de inicio, el glosario, el caso de
negocio, el ROI (return of invest), etc.
Los citerior de evaluación son los siguientes:

a) La visión del producto es estable.
b) La arquitectura es estable.
c) Se ha demostrado mediante la ejecución del prototipo que los principales elementos de
riesgo han sido abordados y resueltos.
d) El plan para la fase de construcción es detallado y preciso. Las estimaciones son
creíbles.
e) Todos los interesados coinciden en que la visión actual será alcanzada si se siguen los
planes actuales en el contexto de la arquitectura actual.
f) Los gastos hasta ahora son aceptables, comparados con los previstos.
 Construcción.
La finalidad de esta fase, es alcanzar la capacidad operacional del producto de fomra
incremental, a través de las sucesivas iteraciones. Durante esta fase, todos los
componentes, características y requisitos que no hayan sido implementados, integrados y
probados, deben hacerlo, para poder obtener una versión que sea utilizda por los usuarios.
El énfasis de esta fase es el control de las operaciones realizadas, administrando los
recursos eficientemente, de tal forma que se optimicen los costos, los calendarios y la
calidad.
Los objetivos son:

a) Minimizar los costos de desarrollo mediante la optimización de recursos y evitando el
tener que rehacer un trabajo o incluso desecharlo.
b) Conseguir una calidad adecuada tan rápido como sea práctico.
c) Conseguir versiones funcionales, tan rápido como sea práctico.

i) Modelos completos (casos de uso, análisism diseño, despliegue e implementación).
ii) Arquitectura íntegra (mantenida y mínimamente actualizada).
iii) Riesgos presentados mitigados.
22
RUP.
iv) Plan de proyecto para la fase de Transición.

v) Manual inicial de usuario (con suficiente detalle).
vi) Prototipo operacional.
vii) Caso de negocio actualizado.
 Transición.
La finalidad de la fase de transición es poner el producto en manos de los usuarios finales,
para lo que típicamente se requerirá desarrollar nuevas versiones actualizadas del producto,
completar la documentación, capacitar al usuario en el manejo del producto, y en general
tareas relacionadas con el ajuste, configuración, instalación y usabilidad del producto.
Los objetivos son:
a) Conseguir que el usuario se valga por sí mismo.
b) Un producto final que cumpla los requisitos esperados, que funcione y satisfaga
suficientemente al usuario.

i) Prototipo operacional.
ii) Documentos legales.
iii) Caso de negocio completo.
iv) Línea de base del producto completa y corregida que incluye todos los modelos del
sistema.
v) Descripción de la arquitectura completa y corregida.
Las iteraciones en esta fase se dirigirán a desarrollar una nueva versión. La complejidad de
esta fase, depende de la naturaleza del proyecto, de su alcance y de la organización en la que
deba implantarse.
2.6 El proceso de desarrollo de software en la Gerencia de

Informática.
Actualmente, en la Gerencia se desarrollan sistemas bajo la metodología RUP. Es necesario
señalar que es reciente la adopción de esta metodología, por lo que aún no se cubren ni todas las
disciplinas, ni se generan todos los productos recomendados que marca el RUP.
El gráfico que se muestra abajo, ejemplifica la manera en que se lleva el proceso de desarrollo
de software bajo la metodología RUP actualmente en la Gerencia.
Disciplinas Disciplinas
Requeri -
mientos Adminis-
Proceso de Desarrollo
Procesos de Apoyo
tración de
proyectos
Análisis y
Diseño
Ambiente
Pruebas
23
RUP.
Figura 2.4. Proceso de desarrollo de software actual.
A continuación, se describirán con mayor detalle cada una de las disciplinas usadas para el
desarrollo de sistemas, expuestas en la figura 2.4, mediante un diagrama principal por cada una
de las disciplinas, seguido de uno específico por cada actividad.
Procesos de Desarrollo
1. Administración de Requerimientos
El propósito de la disciplina de Administración de Requerimientos estará enfocada principalmente
a:
Establecer y formalizar las expectativas del desarrollo o proyecto en cuestión tomando en
consideración las necesidades y características solicitadas por los usuario finales y los usuarios
involucrados
Establecer y formalizar las fronteras del desarrollo o proyecto
Considerar y administrar la información necesaria que requiera la disciplina de Administración
para apoyar la planeación y el contenido de las iteraciones así como las métricas que la misma
considera importante.
Apoyar a la demás disciplinas en el entendimiento global de los requerimientos a través de la
documentación generada.
Apoyar en la definición de la interfaz de usuario a través del desarrollo de prototipos si el
proyecto o desarrollo así lo requiere.
A continuación se anexa el diagrama de flujo de trabajo principal, para visualizar de una mejor
manera las actividades realizadas dentro de esta disciplina. Cabe mencionar que en lo siguiente,
después de cada diagrama principal, se anexa el detalle de cada actividad para una mejor
comprensión.
Flujo de Trabajo
Diagrama Principal
24
RUP.
Figura 2.5. Diagrama principal de la disciplina Administración de requerimientos.
25
Propuesta de Implantación del Sistema de Gestión ISO-9001:2000 para el proceso de Desarrollo del Software usando la metodología del RUP.
Diagramas específicos
Figura 2.6. Diagrama de la actividad Analizar el problema.
26
Analizar el problema
El propósito de esta actividad es:
 identificar a los usuarios y participantes
 establecer acuerdos entre los mismos
 definir las fronteras del sistema
 identificar sus restricciones.
Rol/Responsable Tarea Fase

Analista - Identificar Requerimientos para Visión Incepcion
Ingeniero de Requerimientos El objetivo de esta tarea es la de establecer las Elaboration
secciones principales a recabar para el
desarrollo del documento de Visión e ir
generando checklist que guíen el desarrollo de
las sesiones de levantamiento de
requerimientos.
Analista - Detectar Actores y Casos de Uso Incepcion
Ingeniero de Requerimientos El objetivo de esta tarea es evaluar a los Elaboration
actores y casos de uso que se van detectando e
ir evaluando su agrupación.
Analista - Capturar Glosario Incepcion
Ingeniero de Requerimientos El objetivo de esta tarea es la de comenzar a Elaboration
desarrollar el Glosario que se tendrá a lo largo
del proyecto y que será utilizado para describir
el vocabulario de negocio. Este vocabulario
será utilizado principalmente en las
Especificaciones de Casos de Uso.
Analista - Desarrollar Plan de Administración de Incepcion
Ingeniero de Requerimientos Requerimientos Elaboration
Esta tarea consiste en desarrollar un plan para
documentar los requerimientos haciendo uso
del Racional Requisite Pro. Se centra
principalmente en los atributos y las guías de
traceabilidad.
Tabla 2.1. Detalles del rol, tarea y fase de la actividad analizar el problema.
27
Figura 2.7. Diagrama de la actividad Entender las necesidades del usuario.
28
Entender las necesidades del usuario

 levantar la información del proyecto con los usuarios con la finalidad de entender sus necesidades reales
 Documentar la información recolectada

Analista - Levantar necesidades con el usuario Incepcion
Ingeniero de Esta tarea consiste en evaluar los perfiles de los usuarios y decidir Elaboration
Requerimientos el mecanismo de levantamiento de requerimientos. Este puede ser
un Taller de Requerimientos, entrevistas personales o reuniones
grupales. Cualquiera de estas actividades deberá ser documentada.
Esta tarea alimentará a las tareas de la actividad de “Analizar el
Problema”.
Analista - Desarrollar Visión Incepcion
Ingeniero de El objetivo de esta tarea es ir desarrollando paulatinamente el Elaboration
Requerimientos documento de Visión conforme se vayan levantando los
requerimientos.
Analista - Generar Survey de Casos de Uso Incepcion
Ingeniero de Esta tarea consiste en generar el Survey de Casos de Uso con la Elaboration
Requerimientos información que actualmente se encuentra levantada.
Analista - Construir el Modelo Inicial Incepcion

Ingeniero de Esta tarea consiste en desarrollar el modelo inicial del sistema, Elaboration
Requerimientos basado en el Survey de Casos de Uso dentro de Racional Rose.
Analista - Desarrollar Especificaciones Suplementarias Incepcion
Ingeniero de Esta tarea consiste en documentar y generar las especificaciones Elaboration
Requerimientos suplementarias que se vayan generando.
Analista - Administrar Dependencias Incepcion
Ingeniero de Esta tarea consiste en la creación y/o actualización del repositorio Elaboration
Requerimientos de información dentro de Racional Requisite Pro. Los requerimientos
que se vayan levantando deberán existir dentro de este repositorio
con la finalidad de administrar el alcance del proyecto e ir
administrando los cambios en los requerimientos.
Tabla 2.2. Detalles del rol, tarea y fase de la actividad entender las necesidades del usuario.
29
Figura 2.8. Diagrama de la actividad Definir el sistema.
30
Definir el Sistema
realizar el análisis de alto nivel de los requerimientos levantados

integrar a las disciplinas participantes
Poner a disposición de las mismas la información generada

Analista - Refinar el Glosario Incepcion
Ingeniero de EL Glosario generado deberá actualizarse permanentemente. Elaboratio
Requerimientos En esta tarea el Glosario podrá ser sometido a revisión por n
los usuarios.
Analista - Refinar el Survey de Casos de Uso Incepcion
Ingeniero de Esta tarea consiste en refinar el Survey de Casos de Uso Elaboratio
Requerimientos conforme se vayan levantando los requerimientos. n
Analista - Refinar el Documento de Visión Incepcion
Ingeniero de El objetivo de esta tarea refinar paulatinamente el Elaboratio
Requerimientos documento de Visión conforme se vayan levantando los n
requerimientos.
Refinar Modelo
El objetivo de esta tarea es la de refinar el modelo e ir
integrando a la Disciplina de Arquitectura.
Analista - Delegar y Administrar Dependencias Incepcion
Ingeniero de El repositorio del Racional Requisite Pro deberá contar con Elaboratio
Requerimientos la información actualizada y deberá ser puesta a disposición n
entre los participantes del proyecto.
Tabla 2.3. Detalles del rol, tarea y fase de la actividad definir el sistema.
31
Figura 2.9. Diagrama de la actividad Administrar el alcance.
32
Administrar el Alcance
Priorizar y redefinir los requerimientos levantados para establecer su desarrollo por iteraciones
Identificar el conjunto de casos de uso que representan la funcionalidad central.

Analista - Priorizar Casos de Uso Incepcion
Ingeniero de El objetivo de esta tarea es establecer la priorización de Elaboratio
Requerimientos Casos de Uso sugerida por la disciplina de Requerimientos n
para el desarrollo de Casos de Uso por iteraciones. Esta
priorización deberá llevarse a cabo basada en la información
sobre los atributos previamente registrada dentro del
repositorio de Requerimientos Rational Requisite Pro.
Analista - Actualizar Dependencias Incepcion
Ingeniero de El objetivo de esta tarea es la de actualizar a todas las Elaboratio
Requerimientos disciplinas necesarias sobre la priorización de los casos de n
uso.
Arquitecto de Software Actualizar Artefactos Incepcion
El objetivo de esta tarea es la de actualizar todos los Elaboratio
artefactos generados con base en la priorización de n
requerimientos establecida.
Tabla 2.4. Detalles del rol, tarea y fase de la actividad administrar el alcance.
33
Figura 2.10. Diagrama de la actividad Redefinir el sistema.
34
Redefinir el Sistema
Describir el flujo de eventos de las Especificaciones de Casos de Uso en detalle

Detallar las especificaciones suplementarias
Desarrollar el documento de Especificación de Requerimientos de Software
Modelar el prototipo y/o la interfaz del usuario

Especificador de Casos de Detallar Casos de Uso Incepcion
Uso – Ingeniero de El objetivo de esta tarea es la de detallar los flujos básicos y Elaboratio
Requerimientos alternos de cada uno de los Casos de Uso identificados de n
manera formal.
Especificador de Casos de Detallar Especificación Suplementarias Incepcion
Uso – Ingeniero de El objetivo de esta tarea es la de detallar de manera puntual Elaboratio
Requerimientos las especificaciones suplementarias previamente n
identificadas. El detalle de las mismas deber evitar
ambigüedades.
Especificador de Casos de Desarrollar Especificación de Requerimientos de Incepcion
Uso – Ingeniero de Software Elaboratio
Requerimientos El objetivo de esta tarea es la de empezar la construcción n
del documento de Especificación de requerimientos de
Software que formalizará el desarrollo de la disciplina dentro
del proyecto.
Diseñador – Ingeniero de Modelar la Interfaz del Usuario Incepcion
Requerimientos Esta tarea tiene como finalidad la construcción del prototipo Elaboratio
y/o modelado de la interfaz de usuario. n
Tabla 2.5. Detalles del rol, tarea y fase de la actividad redefinir el sistema.
35
Figura 2.11. Diagrama de la actividad Administrar cambios en requerimientos.
36
Administrar Cambios en los Requerimientos
Administrar y dar seguimiento a las solicitudes de cambio

Reestructurar el modelo de Casos de Uso basados en esas solicitudes
Administrar los atributos y traceabilidad necesaria en el repositorio de Racional Requisite Pro

Analista - Someter a Revisión y obtener retroalimentación sobre Incepcion
Ingeniero de los artefactos generados Elaboration
Requerimientos Todos los artefactos generados y según establezca el
Administrador del Proyecto en conjunto con el Ingeniero de
Requerimientos deberá ser sometidos a revisión con el
usuario para su retroalimentación. Las revisiones que
pueden llevarse a cabo podrán ser revisión de pares en un
inicio, seguido de inspecciones preeliminares por el usuario
y/o administrador del proyecto seguida de la revisión formal
para establecer las versiones finales aprobadas.
Analista – Ingeniero de Actualizar Artefactos Incepcion
Requerimientos El resultado generado como parte de la Administración de Elaboration
Requerimientos podrá considerar la actualización de Construction
artefactos que se vean impactados.
Especificador de Casos de Administrar Dependencias Incepcion
Uso – Ingeniero de El resultado generado como parte de la Administración de Elaboration
Requerimientos Requerimientos podrá considerar la actualización de los Construction
repositorios de información tanto de solicitudes de cambios
como de la administración de los requerimientos.
Tabla 2.6. Detalles del rol, tarea y fase de la actividad administrar cambios en los requerimientos.
37
Artefactos
Artefactos Clasificació Cómo Utilizarlos Aprobació Herramientas

n (Por Fase) n Formal Utilizadas
I E C T
Obligatorio 30% 100% Negociable Requisite Pro
Glosario
MS Word
Plan de Obligatorio 100% Negociable Requisite Pro
Administración MS Word
de
Requerimientos
Obligatorio 100% Obligatorio Requisite Pro
Visión
MS Word
Survey de Casos Obligatorio 80% 100% Obligatorio Requisite Pro
de Uso MS Word
Especificación Obligatorio 40% 100% Obligatorio Requisite Pro
de Casos de Uso MS Word
Especificaciones Obligatorio 50% 80% 100% Obligatorio Requisite Pro
Suplementarias MS Word
Modelo de Caso Negociable 50% 100% Opcional Rational Rose
de Uso (cat)
Prototipo de Opcional 30% 100% Opcional A elegir
Interfaz de
Usuario
Especificación Obligatorio 50% 80% 100%  Obligatorio Microsoft Word
de SODA para Word
Requerimientos
de Software
Plan de Negociable     Negociable MS Project
Actividades por
Iteración
Tabla 2.7. Artefactos generados en requerimientos.
Notas sobre los Artefactos

 Los atributos de los requerimientos son considerados parte del Plan de
Administración de Requerimientos de ahí que no se listan como un artefacto
separado.
 Las métricas son consideradas parte del Plan de Administración de Requerimientos
de ahí que no se listan como un artefacto separado.
 La documentación de las necesidades de los usuarios involucrados son consideradas
dentro del documento de Visión así como dentro del Plan de Administración de
Requerimientos de ahí que no se listan como un artefacto separado.
 El modelo del Casos de Uso puede desarrollarse en Rose para servir como base
para la disciplina de Análisis y Diseño. Dado que el diagrama se incluye en el
38
Survey de Casos de Uso y en cada una de las Especificaciones de Casos de Uso

este artefacto puede ser negociable.
 Todas las sesiones de levantamiento de requerimientos deberán ser documentadas
en minutas.
Reportes
Herramientas Rol
Reportes Clasificación
Utilizadas Responsable
Actores Opcional SODA
Casos de Uso Opcional SODA
Survey de Casos de Uso Obligatorio SODA
Tabla 2.8. Reportes usados en requerimientos.
39
2. Análisis y Diseño
El propósito de esta disciplina es trasformar los requerimientos a una especificación de
cómo implementar el sistema.
El análisis se interesa por los requisitos funcionales, sobre qué debe hacer el sistema; el
diseño es un refinamiento del análisis que describe cómo implementar el sistema, tomando
40
en cuenta los requerimientos no funcionales, proponiendo una arquitectura robusta con un

diseño que se adapte al ambiente de implementación para un mejor desempeño del sistema.
Flujo de Trabajo
Diagrama Principal
Inicio
Definir arquitectura
candidata
Refinar la
Arquitectura
Analizar el
comportamiento del
sistema
Diseñar Diseñar la Base

Componentes de Datos
Fin
Figura 2.12. Diagrama principal de la disciplina Análisis y Diseño.
Definir una Arquitectura Candidata
41
Crear un bosquejo Definir elementos

Definir la
Arquitecto inicial de la significativos
organización
arquitectura del Sist.
Visión Doc. de arquitectura
Figura 2.13. Diagrama de la actividad Definir una arquitectura candidata.
Actividades/Tareas
Rol
Responsable Descripción de la Actividad
Arquitecto Crear un bosquejo inicial de la arquitectura
Modelar una primera aproximación de la arquitectura del
sistema.
Definir elementos significativos de la arquitectura
Se definen los conceptos esenciales que manejará el sistema
así como sus relaciones obteniendo un conjunto de clases
preliminares.
Definir organización del sistema
Se analiza una posible estructura lógica del sistema a nivel
de capas y subsistemas.
Tabla 2.9. Detalles del rol del arquitecto en la actividad definir una arquitectura candidata.
Analizar el comportamiento del sistema
42
Identificar
elementos de
Análisis de CU Definir
diseño
realizaciones
de CU
Arquitecto /
Diseñador
Identificar
Definir mecanismos
clases de
de análisis
análisis
Survey Esp. de Mod. de Realizaciones

Visión
de CU CU Diseño de CU
Figura 2.14. Diagrama de la actividad Analizar el comportamiento del sistema.
Actividades/Tareas
Rol
Arquitecto / Analizar casos de uso
Diseñador Identificar los elementos participantes de cada caso de uso y cómo
se relacionan entre sí. Se analiza el flujo de información (entrada,
proceso, salida) para cada uno.
Definir mecanismos de análisis
Se identifican patrones de solución aplicables a problemas
comunes para reducir la complejidad del análisis, proporcionando
una solución consistente, transformando los requerimientos
funcionales en conceptos de software.
Identificar elementos de diseño
Se refinan los mecanismos de análisis obteniendo mecanismos de
diseño agregando un detalle completo al mecanismo de análisis
conceptual pero se detiene antes de requerir la tecnología en
particular, proporcionando una solución para cada uno dentro de la
arquitectura, se identifican los elementos que proporcionarán el
comportamiento del sistema.
Identificar clases de análisis
Se analizan los conceptos clave traduciéndolos a clases de control,
clases de entidad y clases de interfaz, identificando las clases que
representarán el comportamiento del sistema.
Definir realizaciones de casos de uso
Para cada caso de uso se define una secuencia de pasos que
permitan describir la funcionalidad principal y alterna de cada uno,
identificando las clases involucradas y su relación.
Tabla 2.10. Detalles del rol del arquitecto en la actividad analizar el comportamiento del sistema.
43
Refinar la arquitectura
Priorizar CU Incorporar
Transición de las
elementos de
act. de análisis a
diseño
act. de diseño
existentes
Desarrollar el modelo
Mantener la Describir la
Diseñador de implementación
consistencia e distribución
integridad de la del Sistema
Arquitectura
Mod. de Clases
Esp. Survey Esp. de Doc. de Vista de (refinado)
Suplementarias de CU CU Arquitectura Distribución
(refinado)
Figura 2.15. Diagrama de la actividad Refinar la arquitectura.
Actividades/Tareas
Rol
Diseñador Priorizar casos de uso
Se ordenan los casos de uso tomando en cuenta la
funcionalidad, la estabilidad, el riesgo que implica para el
desarrollo del sistema y su relación con otros componentes.
Obteniendo así los casos de uso fundamentales del sistema
para desarrollarlos según este orden.
Transición de las actividades de análisis a actividades
de diseño
Se refinan los mecanismos de diseño obteniendo los
mecanismos de implementación donde se propone la
tecnología con la que se van a implementar los mecanismos
de diseño. Se detallan las clases de análisis definiendo
atributos, responsabilidades y operaciones y la forma en que
interactúan entre sí.
Incorporar elementos de diseño existentes
Si existen componentes y se pueden reutilizar se agregan al
sistema de forma tal que se mantenga la integridad creando
una interfase de comunicación entre ellos.
Mantener la consistencia e integridad de la arquitectura
Se refina la arquitectura verificando que los componentes
del sistema mantengan la integridad con los componentes
reutilizables que se agregan al sistema.
Descripción de la distribución del sistema
Se propone la distribución física de los procesos y
componentes en cada nodo del sistema.
44
Desarrollar el modelo de implementación

Se refina el modelo de clases incluyendo los mecanismos de
comunicación entre clases. Y se muestra la distribución en
subsistemas y capas.
Tabla 2.11. Detalles del rol del arquitecto en la actividad refinar la arquitectura.
Diseño de componentes
Diseño de Diseñar el
Refinar elementos
Subsistemas modelo de
de diseño
componentes
Refinar y actualizar Implementación

Diseñador realizaciones de CU de componentes
Doc. de Mod. de Vista de Doc. de Modelo del

Arquitectura Clases Componentes Arquitectura sistema
(refinado)
Figura 2.16. Diagrama de la actividad Diseño de componentes.
Actividades/Tareas
Rol
Diseñador Refinar los elementos de diseño
Se refinan los elementos de diseño asociados a cada caso de
uso, verificando que cumplan con la funcionalidad requerida.
Refinar y actualizar realizaciones de casos de uso
Se verifican las realizaciones de cada caso de uso agrupando
los elementos que proporcionan la misma funcionalidad. Se
toman en cuenta las actualizaciones realizadas.
Diseño de subsistemas
Se agrupan los componentes obtenidos de acuerdo a su
funcionalidad en subsistemas.
Diseñar el modelo de componentes
Se definen los módulos que constituyen el sistema y en cada
módulo se describe qué clases implementa y la forma en la
que se relacionan.
45
Implementación de componentes
A cada componente se le asocia la unidad de código que lo
desarrolla y le da la funcionalidad requerida.
Tabla 32. Detalles del rol del arquitecto en la actividad diseño de componentes.
Diseño de base de datos
Identificar clases Diseñar la Definir mecanismos y

persistentes estructura de la BD estrategias para
Diseñador acceder los datos
persistentes
Mod. de Doc. de Doc. de Mod. de

Clases Arquitectura Arquitectura Datos
Figura 2.17. Diagrama de la actividad Diseño de base de datos.
Actividades/Tareas
Rol
Diseñador Identificar clases persistentes
De los elementos significativos se identifican cuales tendrán
la característica de persistencia dentro del sistema, que se
convertirán en las clases de tipo entidad.
Diseñar la estructura de la Base de Datos
Con base a las clases persistentes se propone la estructura
de la base de datos del sistema.
Definir mecanismos y estrategias para acceder los
datos persistentes
Después de realizarse el diseño de la base de datos y con
base a las características del sistema se definen los
mecanismos de comunicación con la base de datos.
Tabla 2.13. Detalles del rol del arquitecto en la actividad diseño de bases de datos.
Artefactos
Artefactos Cómo Utilizarlos Revisión Herramienta Rol

Ince Elab Cons Tran de s Utilizadas Responsabl
p t s Detalles e
Documento de 10% 70% 90% 100% Interno MsWord Arquitecto
Arquitectura de Formal de Software
46
Software (Software
Arquitecture
Document)
10% 70% 90% 100% Interno Rational Arquitecto
Modelo del Sistema
Formal Rose de Software
Tabla 2.14. Artefactos generados en análisis y diseño.
Cómo
Artefactos Razón
Utilizarlos
Este documento es un reporte del modelo,
Documento de proporciona una descripción arquitectónica
Arquitectura de En Word comprensiva del sistema, usando diversas vistas de la
Software arquitectura para representar diferentes aspectos del
sistema.
El modelo del sistema proporciona una descripción a
Modelo del En Rational detalle del sistema, casos de uso, subsistemas,
sistema Rose clases, componentes, etc. y la forma en que éstos
están relacionados.
Tabla 2.15. Notas sobre los artefactos usados en análisis
I nicioy diseño.
[Definir la Misión de las Pruebas
3. Pruebas
Verificar el alcance Verificar la estabilidad
de la prueba] del sistema
El propósito de está disciplina es evaluar la calidad del producto de software con ayuda de
diferentes técnicas, que nos permitan detectar defectos en el producto de software, y
verificar que se satisfacen los requerimientos del usuario.
De está forma se proporcionará una realimentación con las demás disciplinas, en etapas
tempranas del desarrollo de software que puedan ser resueltos de manera efectiva y en
Seleccionar otra
técnica
tiempo. Probar y Evaluar Lograr la misión
establecida
Flujo de Trabajo
Diagrama Principal
Mejorar los activos

de pruebas]
Iniciar otro
ciclo de prueba
47
F in
Figura 2.18. Diagrama principal de la disciplina de Pruebas.
48
Definir la Misión de las Pruebas
Ingeniero de Identificar motivadores Establecer la Misión

Pruebas de pruebas
Vision
Plan de Desarrollo
Plan de Pruebas de Software
Plan de Iteración
Ingeniero de Definir Identificar Definir el alcance

Pruebas objetivos ideas de de las pruebas
de pruebas pruebas
Modelo del Sistema Documento de Lista de Ideas de Pruebas

Arquitectura
Modelo de Caso de Uso
Figura 2.19. Diagrama de la actividad Definri la misión de pruebas.
Actividades/Tareas
Rol
Ingeniero de Identificar Motivadores de Pruebas
pruebas En está primera etapa se analizan los documentos de Visión
y el Plan de la iteración para definir los elementos y puntos
que motivaron el trabajo de pruebas. Al termino de esta
actividad se iniciará el desarrollo del Plan de Pruebas.
Establecer la misión
En este punto se procederá a delimitar cuál será la misión
del equipo de pruebas, para ello se analizarán los
documentos Plan de desarrollo de software y Visión. Con
los resultados de está actividad, se continua implementando
el Plan de Pruebas
Definir los objetivos de pruebas
En esta parte se especificarán más a detalle, puntos
objetivos que serán sujetos a evaluaciones por parte del
49
equipo de pruebas, para ello se analizarán los artefactos

Modelo de Casos de Uso, Modelo del Sistema, Documento de
Arquitectura. A estos puntos se les asignará una prioridad.
Está actividad también agregará información al Plan de
pruebas.
Definir el alcance de las pruebas
Con la información obtenida anteriormente y establecida en
el Plan de Pruebas, se realizará un análisis que permita
definir el alcance del trabajo de pruebas, es decir se
detallarán las técnicas y métodos que serán utilizados para
evaluar. Está información servirá de retroalimentación al
Plan de Pruebas.
Identificar Ideas de Pruebas
Con los artefactos utilizados anteriormente realizará un
análisis detallado para identificar ideas de pruebas, es decir
los puntos básicos e importantes del sistema que serán
evaluados. Como resultado de está actividad se generará una
lista de Ideas de Pruebas.
Tabla 2.16. Detalles del rol del ingeniero de pruebas definiendo la misión de pruebas.
50
Verificar el alcance de la prueba
Plan de Pruebas Ideas de Pruebas
IIngeniero de Definir el ambiente Definir los detalles Definir la Testabilidad

Pruebas de pruebas de las pruebas de los elementos
Guías de Pruebas
Script de Pruebas
Ambiente de pruebas Caso de Prueba
IImplementar Suite Implementar Prueba

de Pruebas
Suite de Pruebas Script de Pruebas
Figura 2.20. Diagrama de la actividad Verificar el alcance de la prueba.
Rol
Ingeniero de Definir los detalles de las pruebas
pruebas De los motivadores, misión e ideas de pruebas, se comienza
a detallar la estrategia de pruebas que se utilizará.
Especificando tipos de pruebas y su prioridad, además de
especificar los siguientes puntos:
Objetivo
Técnica o método de realización
Herramientas necesarias
51
Criterio de Finalización
Está información será plasmada en el Plan de pruebas.
Posteriormente se procederá a crear los casos de pruebas
derivados de la lista de Ideas de pruebas y enfocándolos a
cada tipo de prueba.
Definir el ambiente de pruebas

En este punto se procederá a establecer los recursos de
software y hardware necesarios para crear el ambiente de
pruebas idóneo.
Definir la “Testabilidad” de los elementos
En esta parte se identificarán los elementos físicos
necesarios para llevar acabo la prueba, además de analizar
los elementos de software que puedan ser probados sobre la
configuración. Con lo anterior, se establece un bosquejo del
script de prueba que muestre los pasos que deben seguirse
para implementar dicha prueba.
Implementar Prueba
Con los casos de prueba ya desarrollados, y el bosquejo del
script de prueba, se detallará aún más el script de prueba
que será ejecutado posteriormente.
Pueden generarse nuevos scripst con la información
anterior.,Los scripts pueden ser manuales o automatizados).
El resultado de realizar está actividad, es terminar la
elaboración de los scripts de prueba, para posteriormente
ejecutarlos.
Implementar “suite” de pruebas
Después de desarrollar los scripts de pruebas, se deben
analizar para identificar cuáles pueden ejecutarse en
conjunto con otros, dependiendo de sus características de
ejecución y objetivos. De está forma se realizan las suites de
pruebas, que se ejecutarán para verificar varios objetivos de
pruebas en una sola acción.
Tabla 2.17. Detalles del rol del ingeniero de pruebas en la actividad verificar el alcance de la prueba.
52
Validar la estabilidad del sistema
Ideas de Pruebas Ejecutable Suite de Pruebas
IIngeniero de Implementar Prueba Ejecutar suite Analizar fallas detectadas

Pruebas de pruebas
Caso de prueba Solicitud de Cambio Solicitud de Cambio

Log de Pruebas
Definir los detalles Determinar resultados

de las pruebas de pruebas
Resumen de evaluación
de las pruebas Resultados de las pruebas
Figura 2.21. Diagrama de la actividad Validar la estabilidad del sistema.
Rol
Ingeniero de Implementar prueba
pruebas Está actividad se realizará varias veces dependiendo de la
generación de nuevas ideas de pruebas y de los cambios que
sufra el ejecutable. Se debe analizar el ejecutable para
identificar nuevos casos de prueba y mejorar los scripts de
prueba existentes. En este paso se ejecutarán los casos de
prueba y scripts diseñados. De esta forma se podrán
reportar defectos que generarán las solicitudes de cambio.
Ejecutar suite de pruebas
Esta actividad se lleva acabo paralelamente con la anterior,
y consiste en ejecutar los scripts de pruebas definidos, lo
que generará un Log de resultados, que nos permitirá revisar
el resultado de la ejecución .
53
Analizar fallas detectadas

Con el Log de resultados obtenido anteriormente, se
analizarán y evaluarán los resultados en base a los
requerimientos. De está forma se generarán las solicitudes
de cambio necesarias.
Determinar resultados de las pruebas
Con la información obtenida anteriormente y controlando las
solicitudes de cambio realizadas y resueltas, se comenzará a
elaborar el Resumen de evaluación de las pruebas que será
entregado al Administrador del proyecto. Por otro lado debe
controlarse las evidencias de los resultados obtenidos.
Definir los detalles de las pruebas
Se analizará nuevamente la estrategia de prueba para
determinar si con ella se ha logrado alcanzar la misión de las
pruebas, si no es así se procederá a mejorar o cambiar está.
Lo que puede provocar que se modifiquen casos de prueba o
que se generen nuevos.
Tabla 2.18. Detalles del rol del ingeniero de pruebas en la actividad validar la estabilidad del sistema..
54
Probar y Evaluar
Ejecutable Script de Prueba

Solicitud de Suite de Pruebas Script de Prueba
Cambio
IIngeniero de Implementar Prueba Implementar suite Ejecutar suite Analizar fallas Definir los
Pruebas de pruebas de pruebas detectadas Elementos a probar
Ideas de Pruebas
Caso de prueba Datos de entrada Log de Pruebas

Ambiente de pruebas Solicitud de Cambio
Identificar ideas Definir los detalles Determinar resultados

de pruebas de las pruebas Verificar cambios de pruebas
en el ejecutable
Ideas de Pruebas
Solicitud de Cambio Resumen de evaluación

Resultados de las pruebas Solicitud de Cambio de las pruebas
Figura 2.22. Diagrama de la actividad Probar y evaluar.
Rol
Ingeniero de Implementar prueba
pruebas De los resultados obtenidos se analizará nuevamente la
estrategia de prueba para determinar si con ella se ha
logrado alcanzar la misión de las pruebas, si no es así se
procederá a mejorar o cambiar está. Por lo anterior se
procederá a modificar los casos de prueba o crear nuevos.
Implementar suite de pruebas

Tras analizar los resultados obtenidos se revisarán los
55
scripts de pruebas, y se decidirá si son susceptibles de

mejora en cuanto a sus características de ejecución y
objetivos
Ejecutar suite de pruebas
Se ejecutarán las nuevas suites de pruebas, con lo cuál se
generará un Log de resultados que nos permitirá verificar
defectos encontrados y los resultados de la ejecución de la
suite de pruebas.

requerimientos y a las solicitudes de cambio realizadas
anteriormente. Si se detectan nuevos defectos estos se
reportarán en una solicitud de cambio.
Identificar Ideas de pruebas
Con los resultados obtenidos anteriormente se realizará
nuevamente un análisis detallado para determinar si se ha
cumplido con las misión establecida, si no es así se
procederá a identificar nuevas ideas de pruebas, es decir los
puntos básicos e importantes del sistema que serán
evaluados nuevamente. Como resultado de está actividad se
retroalimentará la lista de Ideas de Pruebas.
Definir los elementos a probar
Se realizará nuevamente un análisis de los elementos físicos
necesarios para ejecutar las pruebas en el ambiente de
pruebas establecido. Además de verificar que el ejecutable
cuente con las elementos necesarios que permitan evaluarlo.
Con lo anterior se generará un bosquejo de nuevos scripts
de prueba.
Con la información obtenida anteriormente se revisará la
estrategia de prueba establecida para mejorarla o cambiarla
dependiendo de los resultados obtenidos.
Se procederá a mejorar o crear nuevos casos de prueba,
detallando objetivos, técnicas, puntos de verificación y
criterios de aceptación.
Verificar cambios en el ejecutable

De las solicitudes de cambio realizadas anteriormente, se
realizarán modificaciones al ejecutable mismas que deberán
revisarse y verificar que fueron completadas. Los
resultados obtenidos se almacenarán y se reportarán.
Determinar resultados de las pruebas

Con la información obtenida anteriormente y controlando las
solicitudes de cambio realizadas y resueltas, se
retroalimentará el Resumen de evaluación de las pruebas
que será entregado al Administrador del proyecto. Pro otro
lado deben controlarse las evidencias de los resultados
obtenidos.
Tabla 2.19. Detalles del rol del ingeniero de pruebas en la actividad probar y evaluar.
56
Lograr la misión establecida
IIngeniero de Verificar el alcance Verificar el alcance

Pruebas Obtenido de las de la calidad
pruebas
de las pruebas
Solicitud de Cambio
Resultados de Log de Pruebas Solicitud de Cambio
las pruebas
Determinar resultados Identificar Ideas

de pruebas de pruebas Implementar Implementar Analizar fallas
prueba Suite prueba detectadas
Ideas de Pruebas
Log de Pruebas
Figura 2.23. Diagrama de la actividad Logra la misión establecida.
Rol
Ingeniero de Verificar el alcance obtenido de las pruebas
pruebas Con el resumen de la evaluación de pruebas elaborado, se
analizará y revisará la cobertura del trabajo de pruebas y el
alcance de la misión establecida. Se evaluarán las métricas
establecidas para verificar el cumplimiento de los objetivos.
Estos resultados se informarán al líder de proyecto.
57
Verificar el alcance de la calidad

Con el resumen de la evaluación de pruebas, las solicitudes
de cambio y los resultados de pruebas, se verificará la
cobertura de los objetivos de calidad establecidos para el
producto y el porcentaje de cumplimiento. Estos resultados
se informarán al líder de proyecto.
Determinar resultados de pruebas
Con la información obtenida anteriormente y con el Log de
pruebas se retroalimentará el Resumen de la evaluación de
las pruebas, podrán generarse nuevas solicitudes de pruebas
y se registrarán y almacenarán los resultados.
Identificar ideas de pruebas
Con los resultados obtenidos durante el proyecto se revisará
la lista de ideas de pruebas, para mejorarla o
retroalimentarla.
Implementar prueba
Con las ideas de pruebas anteriores, se realizará un análisis
de los resultados obtenidos, verificando si falta cubrir
alguno. Si es así se ejecutarán los casos de prueba y scripts
necesarios. Con ellos se generan nuevos resultados y Logs
de pruebas.
Se revisarán las suites de pruebas para mejorarlas.
Posteriormente se ejecutarán y generarán nuevos resultados
y Log de pruebas.
requerimientos de calidad y a las solicitudes de cambio
realizadas anteriormente. Si se detectan nuevos defectos
estos generarán una solicitud de cambio.
Tabla 2.20. Detalles del rol del ingeniero de pruebas en la actividad lograr la misión establecida.
58
Mejorar los activos de pruebas
Guías de Pruebas Script de pruebas
Desarrollar la
IIngeniero de implementación Desarrollar Guías Definir los elementos
Pruebas de la prueba de Prueba a probar
de las pruebas
Ambiente de pruebas
Suite de Pruebas
Implementar Identificar ideas Definir detalles

Implementar suite de pruebas de pruebas de Definir rastreabilidad
pruebas pruebas de necesidades
Plan de pruebas
Script de pruebas Guías de Pruebas Datos de entrada
(Catálogo de Ideas de
Pruebas)
Figura 2.24. Diagrama de la actividad Mejorar los activos de pruebas.
Rol
Ingeniero de Desarrollar implementación de la prueba
pruebas Con los resultados obtenidos de las pruebas realizadas, se
deberá mejorar la estructura de implementación de las
pruebas verificando los objetivos establecidos. De esta
forma se realizarán mejoras al ambiente de pruebas y a las
suites de prueba.
Desarrollar guías de pruebas

Está actividad consiste en crear una guía de lo aprendido en
las pruebas realizadas anteriormente. Está guía podrá
contener lineamientos para la creación de casos de prueba,
scripts de prueba y ambiente de pruebas. Como resultado de
59
obtendrá una guía que apoye en el futuro en la

implementación de pruebas.
Definir los elementos a probar
Con el resumen de evaluación de la prueba, se realizará un
análisis de cobertura, con lo cuál podremos encontrar
elementos del sistemas que deban volver a evaluarse o
realizar nuevas pruebas . Podría ser necesario volver a
generar o mejorar los scripts de pruebas.
Con el resumen de evaluación de la prueba, se realizará un
análisis de cobertura, con lo cuál podremos encontrar
nuevos elementos del sistema que deban volver a evaluarse
o realizar nuevas pruebas . Por lo cuál se volverán a generar
o mejorar scripts de pruebas.
Implementar pruebas
Con los scripts de prueba creados anteriormente, se
procederá a ejecutarlos para mejorar los activos de pruebas
desarrollados, mejorando también las guías de pruebas.
Identificar ideas de pruebas

Partiendo del resumen de evaluación de las pruebas, la
nueva generación de ideas de pruebas para esta fase
consiste en mejorar y refinar la lista de ideas de pruebas,
generada anteriormente y crear una guía de estás ideas.

Con la información obtenida en el resumen de la evaluación
de las pruebas se analizarán la estrategia de pruebas y los
casos de prueba para mejorar o enriquecer los datos de
prueba generados anteriormente.
Definir rastreabilidad de necesidades

Con los resultados plasmados en el resumen de la evaluación
de las pruebas, se procederá a verificar la rastreabilidad y
cobertura de los requerimientos del sistema por parte del
equipo de pruebas, plasmando las desviaciones o el
cumplimiento , en el plan de pruebas.
Tabla 2.21. Detalles del rol del ingeniero de pruebas en la actividad mejorar los activos de pruebas.
Artefactos
Artefactos Cómo Utilizarlos Revisión Herramienta Rol

Ince Elab Cons Tran de s Utilizadas Responsabl
p t s Detalles e
Plan de Pruebas 80% 100% 100% Externo- Micosoft Ingeniero de
(Test Plan) Formal Word pruebas
Interno- MS Word y Ingeniero de
Casos de Prueba
30% 95% 100% Formal Rational Test pruebas
(Test Case)
Manager
Scripts de Pruebas 10% 70% 100% Interno- Robot, Ingeniero de
(TestScripts) Formal TestManager Pruebas
60
Resúmen de 100% 100% Interno- MS Word Ingeniero de

Evaluación de la Formal Pruebas
Prueba (Test
Evaluation Summary)
Tabla 2.22. Artefactos generados en pruebas.
Cómo
Artefactos Razón
Utilizarlos
Registro de Se genera automáticamente al ejecutar scripts
Pruebas automáticos y manuales. Manejo interno para
(TestLog) generación del Resumen de Evaluación de la prueba
Lista de Ideas Manejo interno para la generación de algunos casos
(Test Ideas de prueba. No se generarán catálogos de Ideas de
List) prueba por ser proyecto de implementación.
Modelo de
Análisis de
Carga No se aplica
(Workload
Analysis Model)
Datos de
Requeridos para los casos de prueba. Su manejo y
Prueba
revisiones son internos
(TestData)
Resultados de la Se genera automáticamente al ejecutar scripts
Prueba automáticos y manuales. Manejo interno para
(TestResults) generación del Resumen de Evaluación de la prueba
Arquitectura de
Automatización
No aplica
de Pruebas
(TestResults)
Especificación
de Intgerfaz de
Pruebas (Test No aplica
Interface
Specification)
Configuración
del Ambiente de
Pruebas (Test No aplica
Enviroment
Configuration)
Suite de Su manejo será ocasional y de revisión interna
Pruebas informal. Util para pruebas de regresión pero de poco
(TestSuite) uso en un proyecto de implementación.
Tabla 2.23. Notas sobre los artefactos generados en pruebas.
Reportes
Cómo Herramientas Plantilas/Ejempl
Reportes
Utilizarlos Utilizadas os
Reportes de Cobertura de TestManager, No Aplica
Casos de Prueba SoDA, Seagate
61
Crystal Reports
Tabla 2.24. Reportes generados en pruebas.
Notas sobre los Reportes

Los reportes de cobertura indican el nivel de avance en las pruebas y por lo tanto se
generan para los diferentes estados: Planeados, Diseñados, Implementados, Ejecutados y
Validados.
Procesos de Apoyo
4. Administración de proyectos
El propósito de esta disciplina es efectuar la planeación del desarrollo del proyecto, así
como coordinar y guiar el trabajo efectuado en las demás disciplinas, poniendo énfasis en:
 Asignación de recursos.
 Calendarización de actividades.
 Administración de Riesgos.
 Medición del avance en el desarrollo.
 Evaluación del trabajo desarrollado.
62
Flujo de Trabajo
Diagrama Principal
Figura 2.25. Diagrama principal de la disciplina Administración de proyectos.
Concebir un nuevo Proyecto
63
Figura 2.26. Diagrama de la actividad Concebir un nuevo proyecto.
Actividades/Tareas
Rol
Administrador Recepción del Requerimiento
del Proyecto Se establece la necesidad de un nuevo sistema o
modificación mayor a un sistema existente.
Asignar al Equipo de Requerimientos
Se asigna el proyecto al equipo de Requerimientos para que
establezca un análisis de requerimientos inicial que permita
evaluar la factibilidad del proyecto y la asignación de
recursos.
Identificar y evaluar riesgos
Se revisan los riesgos que es posible identificar hasta el
momento, se categorizar de acuerdo a su impacto y se
proponen estrategias de mitigación.
Administrador Aprobar del Proyecto
del Proyecto Utilizando el análisis de requerimientos inicial, se determina
Gerente del la factibilidad del proyecto aprobándose su desarrollo o por
Area el contrario se determina su inviabilidad y se cancela la
Director del solicitud.
Area
Administrador Iniciar del Proyecto
del Proyecto Una vez aprobado el proyecto, se asignan los recursos
iniciales y se establece un plan para la primera iteración.
Tabla 2.25. Detalles del administrador del proyecto en la actividad concebir un nuevo proyecto.
64
Administrar la Iteración
Figura 2.27. Diagrama de la actividad Administrar la iteración.
Actividades/Tareas
Rol
Administrador Asignar al personal
del Proyecto Se determina el personal que participará en la iteración, se
le asignan tareas y en caso de requerirse se le capacita para
el mejor desempeño de sus actividades.
Iniciar la Iteración
Se dan a conocer los planes y objetivos de la iteración.
Identificar y evaluar riesgos
Se revisan los riesgos que es posible identificar hasta el
momento, se categorizar de acuerdo a su impacto y se
proponen estrategias de mitigación.
Evaluar la iteración
Se revisan los resultados obtenidos en la Iteración y se
comparan contra los objetivos originales. Se reportan las
causas identificadas de desviaciones.
Tabla 2.26. Detalles del administrador del proyecto en la actividad administrar la iteración.
65
Desarrollar el Plan de Administración de Software
Figura 2.28. Diagrama de la actividad Desarrollar elplan de administración de software.
Actividades/Tareas
Rol
Administrador Planificar Fases e Iteraciones
del Proyecto Se determinan las iteraciones que compondrán cada fase, las
fechas en que deben realizarse y los principales objetivos a
cumplir en cada una.
Definir la organización del personal asignado al
proyecto
Se integran los grupos de trabajo para cada disciplina y las
interacciones entre ellos.
Desarrollar el Plan de Métricas
Se produce un plan para poder medir el tamaño y el avance
en el proyecto. Este plan puede refinarse en cada iteración.
Desarrollar Plan de Aceptación del Producto
Conforme avanza el proyecto se van determinando los
criterios de aceptación.
Tabla 2.27. Detalles del administrador del proyecto en la actividad desarrollar el plan de administrar el software.
66
Planear la Iteración siguiente
Figura 2.29. Diagrama de la actividad Planear la iteración siguiente.
Actividades/Tareas
Rol
Administrador Reunir los planes detallados por disciplina
del Proyecto Se solicita a los equipos de cada disciplina desarrollen un
plan detallado para sus actividades.
Compilar el plan de la iteración
A partir de los planes detallados se genera un plan general
para la iteración.
Tabla 2.28. Detalles del administrador del proyecto en la actividad planear la iteración siguiente.
67
Cierre de Fase
Figura 2.30. Diagrama de la actividad Cierre de fase.
Actividades/Tareas
Rol
Administrador Reunir los reportes de avance por disciplina
del Proyecto Se establece conjuntamente con los demás participantes en
el proyecto, el estado actual de cada disciplina.
Presentar el estado del proyecto
Se informa a la Gerencia y la Dirección del avance el estado
del proyecto, mediante un documento resumen o
diapositivas.
Tabla 2.29. Detalles del administrador del proyecto en la actividad cierre de fase.
68
Cierre de Proyecto
Figura 2.31. Diagrama de la actividad Cierre de proyecto.
Actividades/Tareas
Rol
Administrador Reunir los reportes de resultados por disciplina
del Proyecto Se establece conjuntamente con los demás participantes en
el proyecto, el estado final de cada disciplina.
Cotejar el proyecto contra el Documento de Aceptación.
Se revisa el documento de aceptación el para detectar
desviaciones o carencias en el producto final.
Presentar el estado del proyecto
Se informa a la Gerencia y la Dirección del avance el estado
del proyecto, mediante un documento resumen o
diapositivas.
Tabla 2.30. Detalles del administrador del proyecto en la actividad cierre de proyecto.
69
Monitorear y Controlar el Proyecto
Figura 2.31. Diagrama de la actividad Monitorear y controlar el proyecto.
Actividades/Tareas
Rol
Administrador Monitorear el estado del Proyecto
del Proyecto Se efectúan reuniones periódicas con los integrantes de los
equipos de trabajo para conocer los avances y los problemas
a los que se enfrentan.
Manejar excepciones y Problemas.
Se busca solucionar aquellas situaciones que representan
obstáculos para el éxito del proyecto.
Registrar el estado del proyecto
Se mantiene un registro detallado de las situaciones
observadas dentro del proyecto.
Tabla 2.31. Detalles del administrador del proyecto en la actividad monitorear el proyecto.
Artefactos
Artefactos Cómo Utilizarlos Revisió Herramienta Rol

Ince Elab Cons Tran n de s Utilizadas Responsable
p t s Detalle
s
Plan de Desarrollo 30 % 80% 90% 100%
de Software Externo Adminitrador
MS Word
(Software Formal del Proyecto
Development Plan )
70
Se construye un plan
Plan de Iteración por cada iteración Interno Adminitrador
MS Project
(Iteration Plan) durante todas las Formal del Proyecto
fases
Evaluación de las Se construye una Interno MS Word Adminitrador
Iteraciones evaluación por cada Formal del Proyecto
(Iteration iteración durante
Assessment) todas las fases
Lista de Riesgos 40% 80% 90% 100% Interno MS Word Adminitrador
(Risk List) Fromal del Proyecto
Plan de 80% 100% ✓ ✓ Externo MS Word Adminitrador
comunicación Formal del Proyecto
Plan de Métricas 10% 80% 90% 100% Interno MS Word Adminitrador
del Proyecto Fromal del Proyecto
(Project
Measurements)
Plan de Aceptación 10% 80% 90% 100% Externo MS Word Adminitrador
del Producto Formal del Proyecto
Se construirá uno Adminitrador
Evaluación del diferente al final de del Proyecto
Estado del Proyecto cada fase
(Status
Assessment)
Tabla 2.32. Artefactos generados en administración del proyecto.
Cómo
Artefactos Razón
Utilizarlos
El uso de MS Project permite a todos los
Plan de En MS
participantes calendarizar sus tareas, haciendo
Iteración Project
innecesario el fromato RUP de Plan de Iteración.
Evaluación del En este proyecto no es práctico el uso de un
En Power
Estado del documento con este fin. Se sustituye por el Reporte
Point
Proyecto de Fin de Fase.
Tabla 2.33. Notas sobre los artefactos generados en la administración del proyecto.
71
Reportes
Cómo Herramientas Plantillas/Ejempl

Reportes
Utilizarlos Utilizadas os
Formato
Presentación a
Fin de fase Power Point No aplica
la Gerencia y
la Dirección
Tabla 2.34. Reportes generados en la administración de proyectos.
Notas sobre los Reportes

Al final de cada fase se formalizará una reunión con la Dirección y la Gerencia para
reportar el avance y los objetivos conseguidos, resumiendo la evaluación de las iteraciones
finalizadas y mostrando los siguientes pasos a tomar.
Configurando la Disciplina
No se realizarán las actividades siguientes:
Desarrollo del Plan de Administración de Riesgos
Desarrollo del Plan de Resolución de Problemas
Desarrollo del Plan de Aseguramiento de la Calidad
debido a que los artefactos producidos en ellas no proporcionan un valor agregado al
proyecto.
Por otro lado no se considerará al artefacto “Orden de Trabajo” como particular a la
disciplina de Administración de Proyecto, sino que se utilizará en el contexto del Control de
Cambios.
5. Ambiente
El propósito principal de la disciplina de Ambiente es de proveer un proceso de desarrollo
de software. Describiendo las actividades que se realizarán, las guías que se utilizarán y
los artefactos que se generarán.
72
Flujo de Trabajo
Diagrama Principal
Figura 2.32. Diagrama principal de la disciplina de Ambiente.
73
Figura 2.33. Diagrama de la actividad Preparar ambiente.
Actividades/Tareas
Rol
Ingeniero del Desarrollar el Caso de Desarrollo
Proceso Trabajará en forma conjunta con cada uno de los integrantes
de las disciplinas de RUP, para establecer las actividades
que se harán y los artefactos que se generarán en cada
proyecto informátíco
Proponer las plantillas
Recopilará las plantillas que se utilizarán durante el proceso
de desarrollo de sistemas.
Construir el sitio web
Considerando la descripción del caso de desarrollo
construirá el sitio WEB del proyecto informático.
Tabla 2.35. Detalles del ingeniero del proceso en la actividad preparar ambiente.
74
Figura 2.34. Diagrama de la actividad Preparar ambiente para la iteración.
Actividades/Tareas
Rol
Ingeniero del Refinar el Caso de Desarrollo
Proceso Realizará las mejoras necesarias durante el desarrollo del
proyecto, atendiendo las peticiones hechas por los
especialistas de cada disciplina.
Actualizar las plantillas
Realizará las mejoras requeridas en las plantillas incluyendo
modificaciones de forma y fondo.
Refinar el sitio web
Realizará las mejoras y adecuaciones necesarias al sitio
WEB, procurando facilitar el acceso a los diferentes
documentos generados en cada disciplina.
Tabla 2.36. Detalles del ingeniero del proceso en la actividad preparar ambiente para la iteración.
75
Figura 2.35. Diagrama de la actividad Preparar guías para la iteración.
Rol
Preparar guías para la iteración
Trabajará en forma conjunta con los especialista de cada
disciplina para el establecimiento de la guías, las deben
incluir los lineamientos necesarios para realizar diversos
trabajo.
Tabla 2.37. Detalles del ingeniero del proceso en la actividad preparar guías para la iteración.
2.6 Comentarios.
Con este capítulo se comprendió porqué es complejo el proceso de desarrollo de software
en la industria y de manera específica en la Gerencia de Informática, así como la aplicación
e importancia de los sistemas informáticos en el Banco.
Se mostró el proceso de desarrollo de sistemas en la gerencia usando la metodología RUP;
el cual resulta complejo comprender ya que es una metodología nueva y poco difundida
esto lo hace difícil de explicar y mucho más de llevar a cabo.
76
CAPÍTULO III
NORMAS, VOLUNTARIA Y OBLIGATORIA.
77
Capítulo III. NORMAS, VOLUNTARIA Y OBLIGATORIA.
El objetivo de este capítulo, es entender qué es ISO, su historia, para después, mostrar los
elementos principales que conforman el sistema de calidad ISO 9001:2000; de igual forma,
se mostrarán las directrices que marca la ISO 9000-3, y cómo se relacionan para efectos
de este trabajo.
ISO 9000.
3.1 Antecedentes de ISO 9000.

Desde su edición inicial en 1987, la serie de normas ha encontrado su lugar en todo tiempo
de organizaciones. De acuerdo con la encuesta de 1999 realizada por ISO, más de 350,000
organizaciones en 150 países han sido certificadas sobre la base de la normatividad ISO
9000.3
Se han venido realizando varias encuestas para conocer la opinión de las organizaciones
certificadas con la normatividad ISO 9000. una de estas encuestas, realizada en 1996
reveló que el 83% de las organizaciones registraron una mejoría en el control de la gestión
y satisfacción del cliente. El 60% identificó una mejor oportunidad para asegurar los
puestos de trabajo. También registraron numerosos reclamos con relación a las primeras
versiones de la serie ISO 9000:1994 que ponía demasiado énfasis en los procedimientos
documentados y no en los resultados; que promovía estilos de gestión burocráticos que
requerían una administración de tiempo completo; que sus resultados eran más de
consistencia que de calidad; que contenía muy poco principios de TQM (Total Quality
Management) como el mejoramiento continuo y el enfoque al cliente. La versión 2000 toma
en cuenta todas estas inquietudes y representa un avance significativo en el modo de cómo
se establecen los requisitos del sistema de calidad.
La forma en que la serie de normas ISO 9000:2000 fue desarrollada es muy diferente a las
versiones previas, ya que en estas nuevas versiones se presentan las siguientes mejoras 4:
 Una aplicación genérica para todo tipo y tamaño de organización y sector industrial.
 Mejor alineación con los procesos de negocio.
 Flexibilidad que permita a ISO 9001 adecuarse a la organización.
 Demostración de la mejora continua.
 Mayor orientación a la eficacia del sistema de gestión de calidad.
 Que ISO 9004 incluya la eficacia y eficiencia de la organización.
 Mayor consistencia de las partes interesadas en la organización.
 Mejorar la compatibilidad con ISO 14000.
 Que facilite la auto-evaluación.
La nueva versión de la serie ISO 9000 intenta dar respuesta a las inquietudes mencionadas
anteriormente. Las nuevas revisiones tomarán en cuenta no solo la experiencia previa con
los sistemas de gestión de la calidad, sino también con las nuevas ideas emergentes sobre
los sistemas genéricos de gestión. Este nuevo enfoque permitirá al sistema de gestión de
calidad tener más flexibilidad para adaptarse a las necesidades cotidianas de la
organización.
Por otro lado, las nuevas normas de la serie ISO 9000:2000 están basadas en los ocho
Principios de Gestión de Calidad. Estos se acordaron por consenso, incorporando mucho de
las ideas de TQM (Total Quality Management).
3
Instituto Latinoamericano de la Calidad A.C (INLAC)., Guía de interpretación ISO 9001.2000, INLAC-
Latinoamérica, México, p.13.
4
Instituto Latinoamericano de la Calidad A.C (INLAC)., Guía de interpretación ISO 9001.2000, INLAC-
Latinoamérica, México, pp.13, 14.
78
Estos principios se prestan para su uso por parte de la alta dirección como una estructura
destinada a llevar a sus organizaciones hacia la mejora de su funcionamiento. Los ocho
principios de la gestión de la calidad se definen en la norma ISO 9000:2000 “fundamentos y
Vocabulario”, así como en la norma ISO 9004:2000 “Directrices para la mejora del
desempeño”. A continuación se indican las descripciones de estos principios tal como
aparecen en las citadas normas.5
1. Enfoque en el cliente. Las organizaciones dependen de sus clientes

y por tanto, deberían comprender las demandas actuales y futuras
de sus clientes, satisfacer los requerimientos y esforzarse en
rebasar sus expectativas.
2. Liderazgo. Los líderes son los que establecen la unidad en cuanto a
los fines y el rumbo de la organización. Es conveniente que éstos
desarrollen y mantengan su entorno interno que permita que las
personas puedan participar de forma plena en la consecución de
los objetivos de la organización.
3. Participación del personal. Las personas que intervienen en todos
los niveles de la organización constituyen la esencia de ésta y su
plena participación es lo que permite que sus capacidades sean
aprovechadas en beneficio de la organización.
4. Enfoque en el proceso. El resultado esperado se consigue de forma
más eficiente cuando las actividades y los recursos relacionados se
gestionan como un proceso.
5. Gestión basada en los sistemas. La identificación, comprensión y
gestión a modo de sistema de los procesos interrelacionados
contribuye a la eficacia y la eficiencia de la organización a la hora
de conseguir sus objetivos.
6. Mejora continua. La mejora continua del funcionamiento global de
la organización debería constituir un objetivo permanente de ésta.
7. Toma de decisiones basada en hechos. Las decisiones eficaces se
basan en el análisis de los datos y la información.
8. Relación mutuamente beneficiosa con los suministradores. Una
organización y sus suministradores mantienen independencia y una
relación mutuamente beneficiosa sirve para aumentar la capacidad
de ambas partes a la hora de aportar un valor añadido.
3.2 La norma ISO 9001:2000.

La norma de manera general, en su apartado de Generalidades, dentro de la introducción,
acentúa que6:
 El diseño e instrumentación de un sistema de administración de la calidad dependerá
de las necesidades, objetivos y tipo de producto que proporciona una organización.
 La norma ISO 9001 no es una norma técnica, sino que más bien complementa los
requerimientos técnicos de los productos.
 La norma ISO 9001 no implica uniformidad en la estructura de los sistemas de
administración de la calidad o de la documentación.
Por otro lado, el modelo propuesto por la norma ISO 9001 es conocido como “enfoque de
procesos”, éste se basa en el ciclo planear, hacer, comprobar y actuar, y se refiere a la
identificación sistemática y administración de procesos y sus interacciones que operan
dentro de la organización.
El ciclo Planear, Hacer, Comprobar, Actuar, se deriva del ciclo Planear, Hacer, Observar,
de Frederick Taylor, modificado en la década de 1930 por el ciclo Especificación,
5
ISO 9000:2000, NMX-CC-9000-IMNC-2000, COPANT/ISO 9000-2000, pp.1,2.
6
James L. Lamprecht, Guía interpretativa de ISO 9001-2000 Con énfasis en la metodología estadística, Panorama,
México, 2001, p.21.
79
Producción, Inspección de Walter Shewhart, que por su parte se inspiró en el modelo

científico de Formulación de hipótesis, Experimento, Prueba de hipótesis. 7
El método de Shewhart fue modificado por el Dr. Deming más tarde, a principios de la
década de 1950. Ishikawa sugiere los seis pasos siguientes para instrumentar el modelo:
Planear.
1. Determinar metas y objetivos. Estos pueden especificarse en la política de
calidad.
2. Determinar métodos para alcanzar las metas y objetivos establecidos.
Hacer.
3. Comprometerse en la evaluación de la educación requerida en la fuerza de
trabajo, necesaria para alcanzar los objetivos y realizar la capacitación.
4. Instrumentar métodos.
Comprobar.
5. Comprobar o estudiar los efectos de la instrumentación. Determinar las
causas de dichos efectos. En donde se sugiere hacer uso del diagrama de
causa-efecto.
Actuar.
6. Si no se alcanzan los objetivos emprender acciones correctivas o
preventivas apropiadas para lograr los objetivos.
De lo anterior se desprende el siguiente modelo:

Mejora
Continua del
Satisfacción del cliente
sistema de
Calidad
Requerimientos del
Responsabilidad de la
Dirección
cliente
Administración de Medición, Análisis y

Recursos Mejora
Entradas Realización del Producto Resultados Producto o

Servicio
Figura 3.1. Modelo de procesos ISO 9001.
Una importante mejora de las normas revisadas es que ahora la estructura de ISO
9001:2000 es consistente con ISO 9004:2000. ahora es posible emplear con mayor facilidad
ambas normas de manera conjunta o independiente. Si bien, ISO 9004:2000 proporciona
guía respecto de los sistemas de administración de la calidad, no es un lineamiento para
7
Walter Shewhart, Statistical Method from the Viewpoint of Quality Control, Dover publication, Inc., N.Y., 1986,
pp.45,149.
80
instrumentar ISO 9001:2000. Por lo tanto, es importante observar que la certificación no

puede emitirse con base en los lineamientos de ISO 9004.
Otra observación importante es que la norma ISO 9001:2000 es compatible con otras, como
ISO 14001 de sistemas de administración ecológica.
La norma ISO 9001:2000, en su nueva versión varía algunos puntos con respecto a la
versión de 1994, en la nueva versión por ejemplo algunos cambios que se han introducido
son: que tiene una estructura orientada a proceso y una secuencia más lógica del
contenido, un proceso de mejora continua como un paso importante para fortalecer el
Sistema de gestión de calidad, la medición de la satisfacción del cliente como información
clave para la mejora, mayor atención a los recursos tales como comunicación y ambiente de
trabajo, cambios y mejoras a la terminología para una mejor interpretación, mayor
compatibilidad con las normas del sistema de gestión ambiental, referencia específica a los
principios de gestión de calidad y una adición del concepto de auto-evaluación(ISO
9004:2000) como un motor del proceso de mejora.8
Entre otros cambios, esto generó que la estructura de la norma haya cambiado, alterando el
orden y número de requisitos; esto es importante, porque para efectos de este trabajo las
recomendaciones establecidas en la norma ISO 9000-3 están ligadas a la norma ISO
9001:1994.
Para visualizar mejor esto, se adjuntan las tablas comparativas con el detalle de los
respectivos requisitos haciendo énfasis en las recomendaciones que se marcan en ISO
9000-3 (texto de la tabla en cursivas).
Tabla comparativa ISO 9001:2000 con ISO 9001:1994.
ISO 9001:2000 ISO 9001:1994

1 Objeto y campo de aplicación 1
1.1 Generalidades
1.2 Aplicación
2 Referencias normativas 2
3 Términos y definiciones 3
4 Sistema de gestión de la calidad
4.1 Requisitos generales 4.2.1
4.2 Requisitos de la documentación
4.2.1 Generalidades 4.2.2
4.2.2 Manual de calidad 4.2.1
4.2.3 Control de los documentos 4.5.1+4.5.2+4.5.3
4.2.4 Control de los registros de calidad 4.16
5 Responsabilidad de la dirección
5.1 Compromiso de la dirección 4.1.1
5.2 Enfoque al cliente 4.3.2
5.3 Política de la calidad 4.1.1
5.4 Planificación
5.4.1 Objetivos de la calidad 4.1.1
5.4.2 Planificación del sistema de gestión de la 4.2.3
calidad
5.5 Responsabilidad, autoridad y comunicación
5.5.1 Responsabilidad y autoridad
5.5.2 Representante de la dirección 4.1.2.1
5.5.3 Comunicación interna 4.1.2.3
5.6 Revisión por la dirección
8
Estévez R. F., Las normas ISO 9000 e ISO 14000 del nuevo milenio, Sistemas globales de Gestión de calidad y
ambiental, Qualitec Internacional, S.A. de C.V., 1999, p.177
81
5.6.1 Generalidades 4.1.3

5.6.2 Información para la revisión
5.6.3 Resultados de la revisión
6 Gestión de los recursos
6.1 Provisión de recursos 4.1.2.2
6.2 Recursos humanos
6.2.1 Generalidades 4.1.2.2
6.2.2 Competencia, toma de conciencia y 4.18
formación
6.3 Infraestructura 4.9
6.4 Ambiente de trabajo 4.9
7 Realización del producto
7.1 Planificación de la realización del producto 4.2.3+4.10.1
7.2 Procesos relacionados con el cliente
7.2.1 Determinación de los requisitos 4.3.2+4.4.4
relacionados con el producto 4.3.2+4.3.3+4.3.4
7.2.2 Revisión de los requisitos relacionados con 4.3.2
el producto
7.2.3 Comunicación con el cliente
7.3 Diseño y desarrollo
7.3.1 Planificación del diseño y desarrollo 4.4.2+4.4.3
7.3.2 Elementos de entrada para el diseño y 4.4.4
desarrollo
7.3.3 Resultados del diseño y desarrollo 4.4.5
7.3.4 Revisión del diseño y desarrollo 4.4.6
7.3.5 Verificación del diseño y desarrollo 4.4.7
7.3.6 Validación del diseño y desarrollo 4.4.8
7.3.7 Control de cambios del diseño y desarrollo 4.4.9
7.4 Compras
7.4.1 Proceso de compras 4.6.2
7.4.2 Información de las compras 4.6.3
7.4.3 Verificación de los productos comprados 4.6.4+4.10.2
7.5 Producción y prestación del servicio
7.5.1 Control de la producción y de la prestación 4.9+4.15.6+4.19
del servicio
7.5.2 Validación de los procesos de producción y 4.9
de la prestación del servicio
7.5.3 Identificación y trazabilidad 4.8+4.10.5+4.12
7.5.4 Propiedad del cliente 4.7
7.5.5 Preservación del producto 4.15.2+4.15.3+4.15.4+4.15.5
7.6 Control de los dispositivos de seguimiento y 4.11.1+4.11.2
medición
8 Medida, análisis y mejora
8.1 Generalidades 4.10+4.20.1+4.20.2
8.2 Seguimiento y medición
8.2.1 Satisfacción del cliente
8.2.2 Auditoría interna 4.17
8.2.3 Seguimiento y medición de los procesos 4.17+4.20.1+4.20.2
8.2.4 Seguimiento y medición del producto 4.10.2+4.103.+4.10.4+4.10.5+4.20+4.20.2
8.3 Control del producto no conforme 4.13.1+4.13.2
8.4 Análisis de datos 4.20.1+4.20.2
8.5 Mejora
8.5.1 Mejora continua 4.1.3
8.5.2 Acción correctiva 4.14.1+4.14.2
8.5.3 Acción preventiva 4.14.1+4.14.3
Tabla 3.1. Tabla comparativa de los requisitos de la norma ISO 9001, versión 2000 y 1994.
82
Tabla comparativa ISO 9000-3 con ISO 9001:1994.
ISO 9000-3 ISO 9001:1994

4.1 Responsabilidad de la administración 4.1 Responsabilidad de la dirección
4.1.1 Responsabilidad de la administración de 4.1.1 Política de calidad
proveedores 4.1.2 Organización
4.1.1.1 Política de calidad 4.1.2.2 Recursos
4.1.1.2 Organización 4.1.2.3 Representante de la dirección
4.1.1.2.1 Responsabilidad y autoridad 4.1.3 Revisión de la dirección
4.1.1.2.2 Verificación de recursos y personal
4.1.1.2.3 Representante de la administración
4.1.1.3 Revisión de la administración
4.1.2 Responsabilidad de la administración de
compras
4.1.3 Revisiones entre el proveedor y compras
4.2 Sistema de calidad 4.2 Sistema de calidad
4.2.1 General 4.2.1 Generalidades
4.2.2 Documentación de sistema de calidad 4.2.2 Procedimientos del sistema de calidad
4.2.3 Plan de calidad 4.2.3 Planeación de calidad
4.3 Auditorías internas al sistema de calidad 4.17 Auditorías de calidad internas
Determinar la efectividad del sistema de calidad.
Auditorías y acciones de seguimiento.
4.4 Acciones correctivas 4.14 Acciones correctiva y preventiva
4.14.1 Generalidades
4.14.2 Acción correctiva
4.14.3 Acción preventiva
5.1 General
Un proyecto de desarrollo debe ser organizado
de acuerdo a un modelo de ciclo de vida.
Actividades de planeación deben ser planeadas e
implementadas de acuerdo a la naturaleza del
modelo de ciclo de vida utilizado.
5..2 Revisión de contrato 4.3 Revisión de contrato
Alcance y requerimientos definidos y 4.3.2 Revisión
documentados. 4.3.3 Modificaciones al contrato
Identificación de riesgos. 4.3.4 Registros
Protección de información propietaria.
Requerimientos.
Capacidad del proveedor para lograr los
requerimientos contractuales.
Definición del trabajo de subcontratistas.
Acuerdo en la terminología utilizada.
El comprador tenga la capacidad de lograr las
obligaciones contractuales
5.2.2 Aspectos de calidad
Criterios de aceptación.
Manejo de cambios.
Manejo de problemas (reclamaciones y quejas).
Rol del comprador (especificación, instalación y
aceptación).
Instalaciones, software y herramientas a proveer
por el comprador.
Estándares y procedimientos a utilizar.
Requerimientos de réplica.
5.3 Especificaciones de requerimientos del 4.3 Revisión del contrato
comprador 4.3.1 Generalidades
5.3.1 General 4.3.2 Revisión
Requerimientos completos y no ambiguos. 4.3.3 Modificaciones al contrato
Desempeño, seguridad, confiabilidad y 4.3.4 Registros
privacidad. 4.4 Control de diseño
83
5.3.2 Cooperación mutua 4.4.1 Generalidades

Asignar a una persona responsable por ambas 4.4.2 Planeación de diseño y desarrollo
partes. 4.4.3 Interrelaciiones organizacionales y técnicas
Método para acordar requerimientos y 4.4.4 Datos de entrada del diseño
aprobación de cambios. 4.4.5 Resultados del diseño
Prevenir malos entendidos. 4.4.6 Revisión del diseño
Registrar y revisar resultados de discusiones. 4.4.7 Verificación del diseño
4.4.8 Validación del diseño
4.4.9 Cambios del diseño
5.4 Planeación de desarrollo 4.4 Control de diseño
Definición del proyecto. 4.4.2 Planeación de diseño y desarrollo
Organización de los recursos (estructura, 4.4.3 Interrelaciones organizacionales y técnicas
responsabilidades). 4.4.4 Datos de entrada del diseño
Fases de desarrollo. 4.4.5 Resultados del diseño
Calendario de proyecto (tareas, recursos, 4.4.6 Revisión del diseño
tiempos). 4.4.7 Verificación del diseño
Identificación de planes relacionados. Plan de 4.4.8 Validación del diseño
calidad, plan de configuración de la 4.4.9 Cambios del diseño
administración, plan de integración, plan de
pruebas.
5.4.2 Plan de desarrollo
5.4.2.1 Fases
Transformar los requerimientos del proveedor
en un producto de software.
Fases.
Entradas.
Saldidas.
Procedimientos de verificación en cada fase.
Análisis de problemas potenciales.
5.4.2.2 Administración
Plan de desarrollo e implementación y
entregables.
Control de avance.
Responsabilidades y asignación de trabajo.
Interfases entre diferentes grupos.
5.4.2.3 Desarrollo de métodos y herramientas
Reglas, prácticas y convenciones.
Herramientas y técnicas de desarrollo.
Administración de la configuración.
5.4.3 Control de avance
5.4.4 Entradas a las fases de desarrollo
Definidas y documentadas
5.4.5 Salidas de las fases de desarrollo
Lograr los requerimientos relevantes.
Criterios de aceptación.
Funcionalidad.
5.4.6 Verificación de cada fase
Revisiones de desarrollo.
Comparación de diseños.
Pruebas y demostraciones.
5.5 Plan de calidad 4.2 Sistema de calidad
5.5.2 Contenido 4.2.2 Procedimientos del sistema de calidad
Objetivos de calidad definidos en términos 4.2.3 Planeación de calidad
medibles. 4.4 Control de diseño
Criterios de entradas y salidas para cada fase. 4.4.1 Generalidades
Tipos de pruebas, verificaciones y validaciones. 4.4.2 Planeación de diseño y desarrollo
Plan detallado de pruebas. 4.4.3 Interrelaciones organizacionales y técnicas
Definición de responsabilidades, revisiones y 4.4.4 Datos de entrada del diseño
pruebas, control de cambios, control de errores 4.4.5 Resultados del diseño
y acciones correctivas. 4.4.6 Revisión del diseño
84
4.4.7 Verificación del diseño

5.6 Diseño e implantación 4.4 Control de diseño
Transforma los requerimientos en un producto 4.4.2 Planeación de diseño y desarrollo
de software. 4.4.3 Interrelaciones organizacionales y técnicas
5.6.2 Diseño 4.4.4 Datos de entrada del diseño
Reglas de diseño y definición de interfases 4.4.5 Resultados del diseño
internas. 4.4.6 Revisión del diseño
Metodología de diseño. 4.4.7 Verificación del diseño
Uso de experiencias pasadas, lecciones 4.4.8 Validación del diseño
aprendidas, evitar recurrencias del mismo o 4.4.9 Cambios del diseño
similar problema. 4.13 Control de producto no conforme
Procesos subsecuentes, facilitar pruebas, 4.13.1 Generalidades
mantenimiento y uso. 4.13.2 Revisión y disposición de productos no
5.6.3 Implementación conforme
Reglas de programación, lenguaes, consistencia
de nombres, código.
Metodología de implementación.
Revisiones, registros.
5.7 Pruebas y validación 4.4 Control de diseño
5.7.2 Plan de pruebas 4.4.2 Planeación de diseño y desarrollo
Pruebas unitarias, integración, sistema. 4.4.3 Interrelaciones organizacionales y ténicas
Casos de prueba, datos de prueba y resultados 4.4.4 Datos de entrada del diseño
esperados. 4.4.5 Resultados del diseño
Tipos de pruebas a desarrollar. 4.4.6 Revisión del diseño
Ambiente de pruebas, herramientas y software 4.4.7 Verificación del diseño
de pruebas. 4.4.8 Validación del diseño
Criterios de aceptación. 4.4.9 Cambios del diseño
Documentación de usuario. 4.10 Inspección y prueba
Personal y capacitación requerida. 4.10.1 Generalidades
5.7.3 Pruebas 4.10.2 Inspección de prueba de recibo
Registro de los resultados de las pruebas. 4.10.3 Inspección de prueba en proceso
Anotar cualquier problema y su impacto, para 4.10.4 Inspección y pruebas finales
que el problema sea revisado hasta su solución. 4.10.5 Registros de inspección y prueba
Cualquier modificación debe ser identificada y 4.11 Control de equipo de inspección
vuelta a probar, así como su impacto. 4.11.1 Generalidades
Evaluar la relevancia de las pruebas. 4.11.2 Procedimientos de control
La configuración de hardware y software debe 4.13 Control de productos no conformes
ser considerada y documentada. 4.13.1 Generalidades
5.7.4 Validación 4.13.2 Revisión y disposición de productos no
Prueba integral. conforme
5.7.5 Prueba de campos
5.8 Aceptación 4.10 Inspección y prueba
El comprador debe juzgar el producto y deberá 4.10.2 Inspección y prueba de recibo
documentarse. 4.10.3 Inspección y prueba en proceso
5.8.2 Aceptación del plan de pruebas 4.10.4 Inspección y pruebas finales
Calendario. 4.10.5 Registros de inspección y prueba
Procedimientos para evaluación. 4.15 Manejo de almacenamiento
Software y hardware de ambiente y recursos. 4.15.1 Generalidades
Criterios de aceptación. 4.15.2 Manejo
4.15.3 Almacenamiento
4.15.4 Empaque
4.15.5 Conservación
4.15.6 Entrega
5.9 Réplica, entrega e instalación 4.10 Inspección y prueba
5.9.1 Réplica 4.10.1 Generalidades
Número de copias. 4.10.2 Inspección y prueba de recibo
Tipo de medio (formato, versión y forma de 4.10.3 Inspección y prueba en proceso
85
lectura). 4.10.4 Inspección y pruebas finales

Documentación (manuales, guías). 4.10.5 Registros de inspección y prueba
Aspectos de licencias. 4.13 Control de producto no conforme
Custodia de copias de respaldo y original. 4.13.1 Generalidades
5.9.2 Entrega 4.13.2 Revisión y disposición de productos no
Copias correctas y completas. conforme
5.9.3 Instalación 4.15 Manejo de almacebamiento, empaque,
Calendario, trabajo fuera de las horas normales conservación y entrega
y fines de semana. 4.15.1 Generalidades
Acceso a instalaciones del cliente. 4.15.2 Manejo
Disponibilidad de personal con ciertas 4.15.3 Almacenamiento
habilidades. 4.15.4 Empaque
Acceso a los sistemas y equipos del cliente. 4.15.5 Conservación
Validación de cada instalación (contractual). 4.15.6 Entrega
Procedimiento formal para aprobación de cada
instalación terminada.
5.10 Mantenimiento 4.13 Control de productos no conforme
Resolución de problema. 4.13.2 Revisión y disposición de productos no
Modificación de interfase. conforme
Expansión funcional o mejora de desempeño. 4.19 Servicio
Definir aspectos a mantener. Programas, datos y
estructuras, especificaciones, documentos del
comprador, documentos del proveedor.
5.10.2 Plan de mantenimiento
Alcance del mantenimiento.
Identificación del estatus inicial del producto.
Organizaciones de soporte.
Actividades de mantenimiento.
Registros y reportes de mantenimiento.
5.10.3 Identificación del estatus actual
5.10.4 Organizaciones de soporte
5.10.5 Actividades de mantenimiento
Resolución de problemas, detección.
Análisis y corrección de no conformidades
causadas por problemas operacionales.
Soluciones temporales, luego permanentes.
Interfases, adiciones o cambios al software.
Expansión funcional o mejoras de desempeño.
5.10.6 Registros y reportes de mantenimiento
Lista de solicitud de servicio o reporte del
problema y el estatus actual.
Organización responsable de atender la solicitud.
Prioridad.
Resultados de las acciones correctivas.
Datos estadísticos de errores y mantenimiento.
5.10.7 Procedimiento de versiones
Tipos de versiones dependiendo de la frecuencia
y/o impacto en la operación del comprador y la
habilidad de implementar cambios en cualquier
punto.
Método para comunicar cambios actuales o
futuros.
Método para confirmar la implementación de
cambios sin problemas.
Indicar qué cambios se han implementado y en
qué localidades.
6.1 Administración de la configuración 4.4 Control de diseño
Mecanismos para identificar, controlar y dar 4.4.2 Planeación del diseño y desarrollo
seguimiento a las versiones de software. 4.4.3 Interrelaciones organizacionales y técnicas
Identificar la versión de software. 4.4.4 Datos de entrada del diseño
86
Identificar el estatus de los productos de 4.4.5 Resultados del diseño

software. 4.4.6 Revisión del diseño
Control de un item de software por más de una 4.4.7 Verificación del diseño
persona. 4.4.8 Validación del diseño
Proveer la coordinación de la actualización de 4.4.9 Cambios del diseño
productos múltiples en una o más localidades. 4.5 Control de documentos y datos
Identificar y dar seguimiento a las solicitudes de 4.5.1 Generalidades
cambio desde su inicio hasta su liberación. 4.5.2 aprobación y emisión de documentos y
6.1.2 Plan de administración de la configuración datos
Organizaciones involucradas y 4.5.3 Cambios en documentos y datos
responsabilidades. 4.8 Identificación y rastraebilidad del producto
Actividades a desarrollar. 4.12 Estado de inspección y prueba
Herramientas, técnicas y metodologías a utilizar. 4.13 Control de producto no conforme
6.1.3 Actividades 4.13.1 Generalidades
6.1.3.1 Identificación y seguimiento 4.13.2 Revisión y disposición de productos no
Especificaciones funcionales y técnicas. conforme
Herramientas de desarrollo.
Interfases con software y hardware.
Documentos y archivos relacionados con
software.
6.1.3.2 Control de cambios
Identificar, documentar, revisar y autorizar
cualquier cambio.
6.1.3.3 Reporte de estatus
Registrar, administrar y reportar el estatus.
6.2 Control de documentos 4.5 Control de documentos y datos
Procedimientos de control de documentos. 4.5.2 aprobación y emisión de documentos y
Aprobación de los procedimientos. datos
Procedimiento de cambios. 4.5.3 Cambios en documentos y datos
6.2.2 Tipos de documentos
Sistema de calidad en el ciclo de vida de los
sistemas.
Documentos de planeación, actividades del
proveedor y su interacción con el comprador.
Documentos de los productos, entradas, salidas,
verificación y validación, documentación para el
comprador y el usuario y documentación de
mantenimiento.
6.2.3 Aprobación y uso
Revisión y aprobación de los documentos por el
personal autorizado antes de su uso.
Disponibilidad de los documentos.
Quitar documentos obsoletos.
6.2.4 Cambios a los documentos
6.3 Registros de calidad 4.16 Control de los registros de calidad
Tiempo de retención de los registros debe ser
establecido y registrado.
6.4 Medidores 4.20 Técnicas estadísticas
6.4.1 Medidores de los productos 4.20.1 Identificación de necesidades
Errores y fallas. 4.20.2 Procedimientos
Recolectar y reportar periódicamente las
métricas.
Identificar el nivel actual de desempeño de cada
métrica.
Acciones correctivas en caso de exceder los
niveles definidos.
Establecer metas de mejoras en términos de las
métricas.
6.4.2 Proceso
Qué tan bien el proceso de desarrollo de
software se lleva a cabo.
87
Qué tan efectivo el proceso de desarrollo está

para reducir la probabilidad de introducción de
errores o de no detectarlos.
6.5 Reglas, prácticas y convenciones 4.9 Control de procesos
4.11 Control de equipo de inspección, medición y
prueba
4.11.2 Procedimientos de control
6.6 Herramientas y técnicas 4.9 Control de procesos
4.11 Control de equipo de inspección, medición y
prueba
4.11.2 Procedimientos de control
6.7 Compras 4.6 Adquisiciones
El proveedor debe asegurar que un producto o 4.6.2 Evaluación de subcontratistas
servicio comprado está de acuerdo con los 4.6.3 Datos para adquisiciones
requerimientos especificados. 4.6.4 Verificaciones de los productos compardos
6.7.2 Apoyo de subcontratistas 4.6.4.1 Verificación del proveedor en las
6.7.3 Validación de producto no comprado instalaciones del subcontratista
4.6.4.2 Verificación del cliente al producto
subcontratado
6.8 Productos incluidos de software 4.7 Control de productos proporcionados por el
Validación. cliente
Almacenamiento.
Protección.
Mantenimiento
6.9 Capacitación 4.18 Capacitación
Proveer capacitación para todo el personal
involucrado en las actividades de un proyecto.
Tabla 3.2. Tabla comparativa de los requisitos de la norma ISO 9001 versión de 1994 con las directrices de ISO
9000-3.
A continuación se muestra la siguiente tabla propuesta para identificar la relación que tiene
ISO 9001:2000 con ISO 9000-3.
Tabla comparativa ISO 9000-3 con ISO 9001:2000.
NMX-CC-9001-IMCN-2000 ISO 9000-3

Introducción 0
Generalidades 0.1
Enfoque basado en procesos
Relación con la norma NMX-CC- 0.2
9004-IMNC
Compatibilidad con otros sistemas de 0.3
gestión
0.4
Objeto y campo de aplicación 1 Alcance
Generalidades 1
Aplicación 1.1
1.2
Referencias normativas 2 2 Normas de referencia
Términos y definiciones 3 3 Definiciones
Sistemas de gestión de la calidad 4 4 Requisitos del sistema de Calidad
Requisitos generales 4.1
Requisitos de la documentación 4.2 Sistema de calidad
Documentación 4.2
88
Generalidades 4.2.1 Generalidades

Manual de la calidad 4.2.1 4.2.2 Procedimientos del sistema de
Control de los documentos 4.2.2 Calidad
Control de los registros 4.2.3
4.2.4
Responsabilidad de la dirección 5 4.1 Responsabilidad de la dirección
Política de Calidad
4.1.1 Organización
4.1.2 Revisión de la dirección
4.1.3
Compromiso de la dirección 5.1

Enfoque al cliente 5.2
Política de calidad 5.3
Planificación 5.4
Objetivos de calidad 4.5.1
Planificación del sistema de gestión 5.4.2 4.2.3 Planeación de la Calidad
de la calidad
Responsabilidad, autoridad y 5.5
comunicación
Representante de la dirección 5.5.2
Comunicación interna 5.5.3
Revisión de la dirección 5.6
Gestión de los recursos 6
Competencia, toma de conciencia y 6.2.2 4.18 Capacitación
formación
Infraestructuras 6.3
Ambiente de trabajo 6.4
Realización del producto 7
Planificación de la realización del 7.1 4.4.2 Planeación del diseño y desarrollo
producto
Procesos relacionados con los 7.2
clientes
Determinación de los requisitos 7.2.1 4.4.3 Interrelaciones organizacionales y
relacionados con el producto técnicas
4.4.4 Entradas del diseño
4.4.5 Resultado del diseño
4.4.6 Revisión del diseño
4.4.7 Verificación del diseño
Revisión de los requisitos 7.2.2 4.3 Revisión del contrato
relacionados con el producto 4.3.1 Generalidades
4.3.2 Revisión
4.3.3 Modificaciones al contrato
4.3.4 Registros
Diseño y desarrollo 7.3 4.4 Control del diseño

compras 7.4 4.4.1 Generalidades
4.6 Adquisiciones
4.6.1 Generalidades
4.6.2 Evaluación de subcontratistas
Datos para adquisiciones
4.6.3 Verificación de los productos
4.6.4 comprados
Producción y prestación del servicio 7.5 4.15 Manejo, almacenamiento, empaque,
conservación y entrega
Generalidades
4.15.1 Manejo
4.15.2 Almacenamiento
4.15.3 Empaque
89
4.15.4 Conservación
4.15.5 Entrega
4.15.6 Servicio
4.19
Control de dispositivos de 7.6 4.5 Control de documentos y datos
seguimiento y de medición Generalidades
4.5.1 Aprobación y emisión de documentos
4.5.2 y datos
Cambios en documentos y datos
4.5.3 Control de equipo de inspección,
medición y prueba
4.11 Generalidades
Control de registros de calidad
4.11.1
4.16
Medición, análisis y mejor 8 4.12 Estado de inspección y prueba
Generalidades 8.1 4.10.1 Generalidades
Auditoría interna 8.2.2 4.10 Inspección y pruebas
4.10.2 Inspección y pruebas de recibo
Inspección y prueba en proceso
4.10.3 Inspección y pruebas finales
Registros de inspección y prueba
4.10.4 Auditorías de calidad internas
4.10.5
4.17
Seguimiento y medición de los 8.2.3 4.7 Control de productos proporcionados
procesos y producto 8.2.4 por el cliente
Identificación y rastreo del producto
4.8 Control del proceso
4.9
Control de producto no conforme 8.3 4.13 Control de producto no conforme
Generalidades
4.13.1 Revisión y disposición de productos
4.13.2 no conformes
Análisis de datos 8.4 4.20 Técnicas estadísticas
4.20.1 Identificación de necesidades
Procedimientos
4.20.2
mejora 8.5
Mejora continua 8.5.1
Acciones correctivas 8.5.2 4.14 Acción correctiva y preventiva
Acciones preventivas 8.5.3 Generalidades
4.14.3
Tabla 3.3. Tabla comparativa de los requisitos de la norma ISO 9001 versión de 2000 con las directrices de ISO
9000-3.
Las tablas comparativas nos permitirán visualizar qué recomendación establecida en la ISO
900-3, es aplicable a nuestro sistema, basado en ISO 9001:2000.
90
3.3 Requisitos Generales.

La organización debe establecer, documentar, implementar y mantener un sistema de
gestión de la calidad y mejorar continuamente su eficacia de acuerdo a los requisitos de la
norma ISO 9001:2000.
En este apartado, se exponen los requisitos que establece la nueva versión de la norma,
estructurados de acuerdo al siguiente esquema:
I. Introducción a la norma (Partes 1, 2, 3, y 4)
II. Responsabilidad de la dirección (Parte 5)
III. Gestión de los recursos (Parte 6)
IV. Realización del producto (Parte 7)
V. Medición, análisis y mejora (Parte 8)
I. Introducción a la norma.
De manera general los objetivos y el campo de aplicación son:
 Demostrar la capacidad de cumplir los requerimientos del cliente y los requisitos
reglamentarios.
 Satisfacer al cliente, por la aplicación efectiva del sistema, incluyendo la mejora
continua y la prevención de no conformidades.
Pueden ser procedentes, en su aplicación, implantación y certificación, exclusiones a

ciertos requerimientos de la norma, debidos a:
 La naturaleza de los productos y/o servicios de la organización.
 Los requerimientos del cliente.
 Los requerimientos reglamentarios
De todas maneras, los únicos requisitos que pueden ser excluidos son los correspondientes
al capítulo “realización del producto”.
A continuación se va a detallar de forma resumida los requisitos de la norma ISO 9011:200,

así como los temas en los que se dividen, indicando el punto de la norma donde se recogen.
4. Sistema de Gestión de la Calidad

4.1 Gestión de Sistemas y Procesos
Establecer, documentar, implementar y mantener un sistema de gestión de calidad y
mejorar continuamente su eficacia.
4.2 Documentación
La organización debe establecer y mantener un manual de calidad, así como llevar un
adecuado control de los documentos y registros para proporcionar evidencia de la
conformidad de los requisitos.
4.3 Uso de los principios de gestión de calidad

Los 8 principios de calidad se han desarrollado con la intención de que la alta dirección
pueda utilizarlos para liderar la organización hacia la mejora del desempeño.
II. Responsabilidad de la Dirección

5.1 Compromiso de la dirección
Comunicar la importancia de cumplir los requisitos del cliente, establecer la política de
calidad y objetivos, suministro de recursos.
5.2 Enfoque al cliente

Determinar las necesidades y expectativas del cliente, cumplir requisitos, satisfacción del
cliente.
5.3 Política de calidad
91
Apropiada al propósito de la organización, compromiso para cumplir requisitos y mejorar el

SGC, marco de referencia para establecer y revisar los objetivos.
5.4.1 Objetivos de Calidad

Establecer los objetivos de calidad en los niveles y funciones relevantes, incluir aquellos
necesarios para cumplir los requisitos del producto.
5.4.2 Planificación del sistema de gestión de calidad

La planificación del sistema de gestión de calidad debe llevarse a cabo para cumplir los
requisitos así como los objetivos de calidad.

Las responsabilidades y autoridades deben ser definidas y comunicadas dentro de la
organización.
5.5.2 - 5.6 Revisión por la dirección (Representante de la Dirección)

Revisiones para asegurar la continua consistencia, adecuación y eficacia del SGC.
5.5.3 Comunicación interna

Asegurar una comunicación apropiada dentro de la organización con respecto a los
procesos del SGC y su eficacia.
III. Gestión de los recursos

6.1 Provisión (suministro) de recursos
Determinar y proporcionar recursos para implementar y mantener el SGC y mejorar
continuamente su eficiencia.
6.2 Recursos Humanos

El personal que realice labores que afecten la calidad del producto debe ser competente
con base en la educación, formación, habilidades y experiencia.
6.3 Infraestructura
Identificar, suministrar y mantener la infraestructura necesaria para lograr la conformidad
del producto (equipo adecuado, servicios de apoyo, etc).
6.4 Ambiente de trabajo

Identificar y gestionar el ambiente de trabajo necesario para logra la conformidad del
producto (métodos de trabajo creativos, oportunidad para un mayor involucramiento, reglas
de seguridad, ergonomía).
IV. Realización del producto

7.1 Planificación de la realización del producto
Debe determinar los objetivos de calidad y requisitos para el producto, la necesidad de
establecer procesos y documentación y de proveer recursos específicos para el producto,
las actividades de verificación, validación, seguimiento, inspección y criterios de
aceptación, así como los registros.

Determinar los requisitos relacionados con el cliente, revisión de los requisitos
relacionados con el producto y comunicación con el cliente (sobre información sobre el
producto, solicitud, manejo de contrato o pedido, retroalimentación del cliente, incluyendo
quejas).
92
Planificación del diseño y desarrollo, entradas al diseño y desarrollo, resultados del diseño
y desarrollo, revisión del diseño y desarrollo verificación del diseño y desarrollo validación
del diseño y desarrollo, control de cambios.
7.4 Compras
Proceso de compras, información de compras, verificación del producto comprado.
7.5 operaciones de producción y servicio

Control de operaciones de producción y servicio, validación de los procesos de las
operaciones de producción y servicio, identificación y trazabilidad, bienes del cliente,
prestación del producto.
7.6 Control de los equipos de medición y seguimiento

Determinar las mediciones que se debe hacer así como los dispositivos para medición y
seguimiento que necesarios para suministrar evidencia de la conformidad del producto.
V. Medición, análisis y mejora

8.2 Seguimiento y Medición
La organización debe hacer seguimiento sobre información relativa a la satisfacción del
cliente, auditorías Internas (para saber si el SGC se ha implementado y mantenido),
medición y seguimiento a los procesos y a los productos.
8.3 Control de producto no conforme

El producto no conforme debe ser identificado y controlado para prevenir su uso o entrega
no intencional para tomar acciones apropiadas.
8.4 Análisis de datos

Determinar, recopilar, y analizar los datos apropiados para demostrar la adecuación y
eficacia del SGC y para evaluar donde pueden realizarse mejoras continuas del SGC.
8.5 Mejora
La organización debe mejorar continuamente la eficacia del SGC a través de: política de
calidad, objetivos de calidad, resultados de la auditoría, análisis de datos, acciones
correctivas, acciones preventivas, revisión por la dirección.
3.4 Estructura documental del sistema de gestión de la calidad.

Dos de los objetivos más importantes que se siguieron a lo largo de la revisión de la serie
de normas ISO 9000 fueron:
a) El desarrollo de un formato simplificado que tenga en cuenta tanto a la pequeña
como a la mediana empresa.
b) Que la cantidad y el nivel de detalle de la documentación exigida mantengan una
mayor consonancia con los resultados esperados a partir de las actividades del
proceso empleado por la organización.
Estos objetivos permiten una mayor flexibilidad a las organizaciones, a la hora de concretar
sus alternativas para el sistema de gestión de la calidad. Esto facilita que cada organización
a título individual elabore la mínima cantidad de documentos necesarios para demostrar su
eficacia en la planificación, funcionamiento y la mejora continua de sus sistema de gestión
de calidad.
El apartado 4.1 de “Requisitos generales” de la norma, exige que la organización

“establezca documentos, implante, mantenga y mejore continuamente la eficacia de un
sistema de gestión de la calidad de acuerdo con los requisitos de esta norma internacional”.
En este apartado se expone que la documentación debe incluir:
93
a) Declaraciones documentadas de una política de calidad y objetivos de la calidad.

b) Un manual de calidad
c) Los procedimientos documentados requeridos en esta norma internacional.
d) Los documentos requeridos por la organización para la planificación, operación y
control eficaz de sus procesos.
e) Los registros de la calidad requeridos por esta norma internacional.
La estructura más común es la de cuatro niveles, en la que se establece para el:

Nivel 1. Manual de calidad (manual de políticas).
Nivel 2. Manual de procedimientos generales.
Nivel 3. Manual de procedimientos específicos.
Nivel 4. Otros documentos (métodos, instructivos, especificaciones, registros, etc.).
Con respecto a los procedimientos obligatorios deberán existir cuando menos lo9s
relacionados a: manual de calidad, control de registros, control de documentos, acciones
preventivas, acciones correctivas, auditoría interna, producto no conforme, medición de la
satisfacción del cliente, mejora continua.
3.5 Comentarios.
Es importante conocer la estructura de la norma ISO 9001:2000 e ISO 9001:1994, para
visualizar en qué apartados se empalma con la ISO 9000-3, para efectos de las
recomendaciones a considerar.
Lo que se ha presentado anteriormente, en las tablas, corresponde a los criterios de la
norma ISO 9001:1994 y de la versión 2000, es importante señalar la relación de los puntos,
ya que, la guía ISO 9000-3, son las directrices para la aplicación de la norma ISO9001:1994
en el diseño, desarrollo, suministro, instalación y mantenimiento de software para
computadoras, y aún no tienen una actualización para la versión del 2000.
94
CAPÍTULO IV
DIAGNÓSTICO DE LA SITUACIÓNACTUAL.
95
Capítulo IV. DIAGNÓSTICO DE LA SITUACIÓN ACTUAL.
El objetivo de este capítulo, es definir qué partes del proceso de implantación de acuerdo a
los requerimientos de la norma ISO 9001:2000 se tienen desarrollados en la actualidad y si
así fuere, en qué grado, de manera tal, que nos proporcionen un indicio del proceso a
seguir en la implementación del sistema.
DIAGNÓSTICO DEL ÁREA DE ACUERDO A LA NORMA.
4.1 Presentación del caso.
4.2 Diagnóstico del área de acuerdo a los cinco criterios.
CRITERIOS DE LA NORMA ISO 9001:2000.
4.0 Sistema de administración de la calidad.
5.0 Responsabilidad de la gerencia.
6.0 Gestión de los recursos.
7.0 Realización del producto.
8.0 Medición, análisis y mejora
96
LISTA DE VERIFICACIÓN DE AUDITORÍAS
Requerimiento ISO 9001: 4 Sistema de administración de calidad / 4.1 Requerimientos generales

Área(s) Auditada(s):
Personal Auditado
Nombre Puesto Nombre Puesto
Requerimiento Cumplimiento Evidencia

Sí No N/A
El área ha establecido, documentado, implantado, mantenido y X
mejorado continuamente su sistema de administración de calidad de
acuerdo con los requerimientos de este Estándar Internacional.
Para implantar el sistema de administración de calidad, el área: X
 Ha identificado los procesos necesarios para el sistema de
administración de calidad X
 Ha determinado la secuencia y la interacción de estos
procesos. X
 Ha determinado los criterios y los métodos requeridos para
asegurar la operación efectiva y el monitoreo efectivos de X
estos procesos.
 Mide, monitorea y analiza estos procesos, e implanta las
acciones necesarias para lograr los resultados planeados y la X Parcialmente, mediante un sistema interno.
mejora continua.
 Maneja estos procesos de acuerdo a esta normativa
internacional. X
Algún personal externo realiza alguna actividad o esta involucrado en X

algún proceso que afecte la conformidad del producto con los
requerimientos.
En caso afirmativo:
 Aseguran el control de estos procesos.
 Se encuentran identificados en el sistema de administración
de calidad
97
Requerimiento ISO 9001: 4. Sistema de administración de calidad / 4.2 Requerimientos de documentación

Personal Auditado

Sí No N/A
4.2.1 General
En la documentación del sistema de administración de calidad se han
incluido:
 Declaraciones documentales de una política de calidad y X
objetivos de calidad.
 Manual de Calidad. X
 Procedimientos documentados requeridos en este Estándar X
Internacional
 Documentación requerida por el área para asegurar la X
planeación, operación y monitoreo efectivo de sus procesos.
 Registros requeridos por este Estándar Internacional.
X
Para definir la extensión de la documentación del sistema de

administración de calidad ha dependido de lo siguiente:
a) El tamaño de el área y el tipo de actividades.
b) La complejidad y la interacción de los procesos.
c) La competencia del personal.
98
Requerimiento ISO 9001: 4. Sistema de administración de calidad / 4.2 Requerimientos de documentación

Personal Auditado

Sí No N/A
4.2.2 Manual de Calidad
Se tiene/mantiene establecido con un Manual de Calidad que incluye: X
 El alcance del sistema de administración de Calidad
incluyendo los detalles y justificación de cualquier exclusión.
 Los procedimientos documentados establecidos para el
sistema de administración de calidad o la referencia a ellos.
 Una descripción de la interacción de los procesos del sistema
de administración de calidad.
4.2.3 Control de Documentos

Se mantiene un control de los documentos requeridos por el sistema X
de administración de calidad.
Cuentan con un procedimiento documentado donde se definen los
controles necesarios para:
 La aprobación de los documentos para su adecuación antes
de publicar.
 Revisar y actualizar según sea necesario así como reaprobar
documentos.
 Asegurar que las versiones relevantes de los documentos
aplicables estén disponibles en los puntos de uso.
 Asegurar que los documentos sean legibles y fácilmente
identificables.
 Asegurar que los documentos de origen externo son
identificados y su distribución controlada.
99
 Prevenir el uso no intencionado de documentos obsoletos, y

aplicarles una identificación adecuada si son retenidos para
cualquier propósito.
4.2.4 Control de Registros.

Se tienen establecidos y mantenidos los registros que proporcionan X
evidencia de la conformidad con los requerimientos y de la operación
efectiva del sistema de administración de calidad.
Se mantienen los registros legibles, fácilmente identificables y
recuperables.
Mantienen establecido un procedimiento documentado para definir los
controles necesarios para la identificación, almacenamiento,
protección, recuperación, tiempo de retención y disposición de los
registros.
100
Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.1 Compromiso de la gerencia

Personal Auditado

Sí No N/A
5.1 Compromisos de la Gerencia
La alta gerencia cuenta con evidencia de su compromiso para el X
desarrollo e implantación y la mejora del sistema de administración de
calidad incluyendo:
 La comunicación a el área de la importancia de cumplir con
los requerimientos del cliente así como también
requerimientos regulatorios y legales.
 El establecimiento de la política de calidad y los objetivos de
calidad.
 Conduciendo revisiones gerenciales.
 Asegurando la disponibilidad de los recursos necesarios.
101
Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.2 Enfoque al cliente / 5.3 Política de Calidad
Personal Auditado

Sí No N/A
5.2 Enfoque al Cliente
La alta gerencia se ha asegurado que los requerimientos del cliente X
sean determinados, convertidas en requerimientos y cumplidas con el
objetivo de incrementar la satisfacción del cliente.
 ¿Se realizan reuniones con el cliente, para validar el X
cumplimiento de los requisitos, verificar resultados, aprobar
resultados, se levanta la minuta de las reuniones?
 ¿Existe una revisión periódica, distribución e implantación de X
estándares o especificaciones del cliente?
NOTA: Ver relación con los siguientes puntos (Ver. 7.2.1 y 8.2.1).
5.3 Política de Calidad
La alta gerencia ha asegurado que la política de calidad: X
 Es apropiada al propósito de el área.
 Incluye un compromiso de cumplir los requerimientos y de
mejora continua.
 Proporciona un marco de trabajo para establecer y revisar los
objetivos de la calidad.
 Es comunicada y entendida en el área.
 Es revisada para su continua adecuación.
102
Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.4 Planeación

Personal Auditado

Sí No N/A
5.4.1 Objetivos de calidad
Ha establecido la alta gerencia objetivos de calidad, incluyendo X Desarrollados en un taller interno.
aquellos necesarios para cumplir con los requerimientos para el
producto, en funciones y niveles relevantes dentro de el área.
Los objetivos de calidad definidos son medibles y consistentes con la X
política de calidad.
5.4.2 Planeación de calidad
La alta gerencia debe asegurar que:
a) En la planeación del sistema de administración de la calidad es X
efectuada con el fin de cumplir con los requerimientos dados en el
punto 4.1, así como con los objetivos de calidad.
b) La integridad del sistema de administración de calidad es X

mantenida cuando son planeados e implantados cambios en el
sistema de administración de calidad.
103
Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.5 Administración

Personal Auditado

Sí No N/A
Se tienen definidas y han sido documentadas las responsabilidades y X Parcialmente, ya que no hay nada escrito
autoridades dentro de el área por parte de la alta gerencia.
 ¿Es delegada la autoridad al personal para: prevenir la X
recurrencia de no-conformidades, identificar y registrar
problemas de calidad, iniciar y verificar acciones correctivas,
controlar procesos, realizar inspecciones?
5.5.2 Representante de la gerencia
Ha designado la alta gerencia a un miembro de la gerencia que, X
independientemente de otras responsabilidades, tenga
responsabilidad y autoridad definida para:
 Asegurar que los procesos necesarios del sistema de
administración de calidad son establecidos, implantados y
mantenidos.
 Informar a la alta gerencia el desempeño del sistema de
administración de calidad, incluyendo necesidades de mejora.
 Promover el conocimiento de los requerimientos del cliente a
través de toda el área.
Nota:
La responsabilidad del representante de la gerencia puede incluir el
enlace con partes expertas en asuntos relacionados con el sistema de
administración de calidad.
104
Se ha asegurado la alta gerencia que se tengan establecidos X

procesos apropiados de comunicación dentro de el área, y que la
comunicación tiene con respecto a la efectividad del sistema de
 ¿Existe algún mecanismo de comunicación dentro de la
Gerencia?
Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.6 Revisión gerencial

Personal Auditado

Sí No N/A
5.6.1 General
Mantiene la alta gerencia un proceso de revisión del sistema de X
administración de calidad, en intervalos planeados, para asegurar su
continua adecuación, suficiencia y efectividad.
En éstas revisiones se evalúan las oportunidades de mejora y la
necesidad de cambios al sistema de administración de calidad,
incluyendo la política de calidad y objetivos de calidad.
Se mantienen los registros de las revisiones gerenciales.
5.6.2 Entradas de la revisión
105
Se incluyen como datos de entrada para la revisión de la gerencia la X

siguiente información:
 Resultados de auditorías.
 Retroalimentación del cliente.
 Desempeño del proceso y conformidad del producto.
 Estado de acciones preventivas y correctivas.
 Acciones de seguimiento de revisiones gerenciales
anteriores.
 Cambios que podrían afectar al sistema de administración de
calidad.
 Recomendaciones de mejora.
106

Sí No N/A
5.6.3 Salidas de la revisión
Se incluyen en los datos de salida de la revisión de la gerencia X
cualquier decisión y acciones relacionadas con:
 La mejora de la efectividad del sistema de administración de
calidad y sus procesos.
 La mejora del producto en relación a los requerimientos del
cliente.
 Necesidades de recursos.
107
Requerimiento ISO 9001: 6. Administración de recursos / 6.1 Provisión de recursos

Personal Auditado

Sí No N/A
Se ha determinado y proporcionado los recursos necesarios para: Únicamente verbal
a) Para implantar y mantener el sistema de administración de calidad X
y mejorar continuamente su efectividad.
b) Incrementar la satisfacción del cliente mediante el cumplimiento de X
sus requerimientos.
108
Requerimiento ISO 9001: 6. Administración de recursos / 6.2 Recursos humanos

Personal Auditado

Sí No N/A
6.2.1 General
El área se asegura que el personal que realiza actividades que afecta X Registros de capacitación
la calidad del producto es competente con base en educación
apropiada, entrenamiento, habilidades y experiencia.
 ¿Están claramente definidas y documentadas las X
responsabilidades y autoridades de todo el personal que
afecta la calidad (Gerente, Subgerente, Líder, etc)?
6.2.2 Competencia, conocimiento y entrenamiento
Tiene el área definidas las necesidades de competencia para el X
personal que realiza actividades que afectan la calidad del producto.
El área ha proporcionado el entrenamiento u otras acciones para X

satisfacer las necesidades identificadas.
Se evalúa la efectividad del entrenamiento proporcionado. X
Se asegura el área de que los empleados tienen conocimiento de la X

relevancia e importancia de sus actividades y cómo contribuyen al
logro de los objetivos de calidad.
Se mantienen registros apropiados de la educación, entrenamiento, X

habilidades y experiencia. (Ver 4.2.4).
109
Requerimiento ISO 9001: 6. Administración de recursos / 6.3 Infraestructura / 6.4 Medio de Trabajo
Personal Auditado

Sí No N/A
6.3 Infraestructura
El área ha determinado, proporcionado, y mantiene la infraestructura X Visual y registros de inventario.
que necesita para alcanzar la conformidad del producto, incluyendo
según sea aplicable:
 Edificios, espacios de trabajo y facilidades asociadas.
 Equipo de proceso, tanto como hardware y software.
 Servicios de soporte tales como transporte o comunicación.
 ¿Están documentados los procesos de la Gerencia? X
6.4 Medio de Trabajo

Se han determinado y se administran el medio de trabajo necesarios X Hardware, software, comunicaciones.
para alcanzar la conformidad de los requerimientos del producto.
 ¿Se realiza una evaluación periódica del ambiente de X
trabajo en la Gerencia?
110
Requerimiento ISO 9001: 7. Realización del producto / 7.1 Planeación de la realización del producto.
Personal Auditado

Sí No N/A
El área planea y desarrolla los procesos necesarios para la X Artefactos, metodología RUP.
realización del producto.
La planeación de los procesos de realización es consistente con los X
otros requerimientos del sistema de administración de calidad de el
área.
Como parte de la planeación de los procesos para la realización del
producto en el área se ha determinado lo siguiente, según sea
apropiado:
 Objetivos de calidad y requerimientos para el producto. X Artefactos, metodología RUP.
 Necesidad de establecer los procesos, documentación, y X Artefactos, metodología RUP.
proporcionar los recursos y las facilidades específicas al
producto.
 Actividades requeridas de verificación, validación, monitoreo, X Artefactos, metodología RUP.
inspección y pruebas específicas para el producto y los
criterios de aceptabilidad del producto.
 Los registros que son necesarios para proporcionar evidencia X
de que los procesos de realización y el producto resultante
cumple con los requerimientos (Ver 4.2.4).
NOTA 1: La documentación que describe cómo los procesos del
sistema de administración de calidad (incluyendo los procesos de
realización del producto) y los recursos a ser aplicados a un producto
específico, proyecto o contrato puede ser referida como un plan de
calidad.
NOTA 2: El área puede aplicar los requerimientos dados en el punto
7.3 para el desarrollo de los procesos de realización del producto.
111
La salida de la planeación se encuentra en una forma adecuada a los X

métodos de operación de el área.
 ¿Existe personal calificado, para realizar las actividades de X
verificación en las etapas de inspección, pruebas y
monitoreo del diseño, producción, instalación y servicio?
112
Requerimiento ISO 9001: 7. Realización del producto / 7.2 Procesos relacionados con el cliente
Personal Auditado

Sí No N/A
7.2.1 Determinación de requerimientos relacionados al producto
Ha identificado el área los siguientes requerimientos: X
 Requerimientos especificados por el cliente, incluyendo los
requerimientos para la entrega y actividades post-entrega.
 Requerimientos no declarados por el cliente pero necesarios X Disciplina de Requerimientos de RUP.
para el uso especificado o intencionado, donde sea conocido.
 Requerimientos estatutarios y regulatorios relacionados con X Disciplina de Requerimientos de RUP.
el producto.
 Cualquier requerimiento adicional determinado por el área. X Disciplina de Requerimientos de RUP.
 ¿Existe algún mecanismo para medir la calidad del servicio X
proporcionado al cliente?
7.2.2 Revisión de requerimientos de producto
Revisa el área los requerimientos identificados del cliente junto con X Disciplina de Requerimientos de RUP.
requerimientos adicionales determinados por el área.
Se revisan los requerimientos antes de establecer un compromiso X
para suministrar un producto al cliente (por ejemplo el envío de una
propuesta, la aceptación de un contrato u orden) para asegurar que:
 Los requerimientos del producto se definen.
 Si el cliente no proporciona declaración documentada del
requerimiento, los requerimientos del cliente son confirmados
antes de ser aceptados.
 Son resueltas la diferencias entre el contrato u orden y los
requerimientos previamente expresados.
 El área tiene la habilidad de reunir los requerimientos
definidos.
113

Sí No N/A
7.2.2 Revisión de requerimientos relacionados al producto.
El área revisa los relacionados con el producto. X Disciplina de Requerimientos de RUP.
Las revisiones son conducidas antes de que el área establezca X Disciplina de Requerimientos de RUP.
compromiso para suministrar un producto al cliente (por ejemplo, el
envío de una propuesta, la aceptación de un contrato u orden,
aceptación de cambios a contratos u órdenes).
Se asegura el área que: X Disciplina de Requerimientos de RUP.
 Los requerimientos del producto son definidos.
 Los requerimientos de la orden o contrato que difieran de
aquellos previamente expresados son resueltos.
 Cuenta con la capacidad de cumplir con los requerimientos
definidos.
Se mantienen los registros de los resultados de la revisión y las X Disciplina de Requerimientos de RUP.
acciones generadas por la revisión (Ver 4.2.4)
 ¿Están las actividades de revisión de contrato
adecuadamente documentadas y actualizadas para
asegurar que los requisitos del cliente son entendidos?
Se confirman los requerimientos del cliente cuando no se proporciona X Disciplina de Requerimientos de RUP.
declaración documentada del requerimiento antes de su aceptación.
Cuando los requerimientos sufren modificaciones, se asegura el área X Disciplina de Requerimientos de RUP.
de que los documentos relevantes son modificados y el personal
relevante es enterado de los requerimientos cambiados.
Nota: En algunas situaciones como sitios de internet, la revisión
formal es impráctica para cada orden. La revisión puede cubrirse
mediante información relevante del producto, tal como catálogos o
material publicitario.
Tiene el área determinados e implantados arreglos efectivos para la X
comunicación con los clientes relacionado a:
 Información del producto.
 Manejo de solicitudes, contratos u órdenes, incluyendo
modificaciones.
Retroalimentación del cliente, incluyendo quejas del cliente.
114
Requerimiento ISO 9001: 7 Realización del producto / 7.3 Diseño y desarrollo

Personal Auditado

Sí No N/A
7.3.1 Planeación del diseño y desarrollo
El área planea, controla el diseño y desarrollo del producto. X Artefactos de RUP.
Se incluye en la planeación del diseño y el desarrollo: X Artefactos de RUP.
 Etapas del proceso de diseño y desarrollo.
 Actividades de revisión, verificación y validación apropiadas
en cada etapa del diseño y desarrollo.
 Responsabilidades y autoridades para las actividades de
diseño y desarrollo.
 ¿La metodología usada para el diseño y desarrollo, incluye: la X Parcialmente, a través de RUP
definición del proyecto y objetivos, recursos
asignados(estructura del equipo, responsables, recursos
materiales a utilizar), las fases de desarrollo incluyen: tareas,
entradas, salidas, procedimientos de verificación y análisis de
problemas potenciales, plan de proyecto: tareas a ser
realizadas y tiempo requerido e interrelación entre ellas,
responsables y recursos, plan de calidad, plan de
administración de la configuración y plan de pruebas?
 ¿El plan de desarrollo abarca objetivos de calidad en
términos cuantificables, responsabilidades para cada
actividad de revisión, pruebas, control de cambios y acciones
correctivas?
Se tienen definidas las interfaces entre los diferentes grupos X

implicados en el diseño y desarrollo para asegurar comunicación
efectiva y claridad de responsabilidades.
Se actualiza la salida de la planeación conforme el diseño y desarrollo X A través de la metodología RUP

progresa.
115
7.3.2 Entradas del diseño y desarrollo

Se tienen definidas y documentadas las entradas relacionadas con X
requerimientos del producto y se mantienen registros de ésta
actividad.
 ¿En el caso de desarrollo de sistemas están definidos X
claramente y sin ambigüedad los requisitos funcionales? En definición
(Desempeño, seguridad, confiabilidad, interfases).
Se incluyen en los datos de entrada: X
 Requerimientos de desempeño y funcionales.
 Requerimientos regulatorios y estatutarios aplicables.
 Información aplicable derivada de diseños semejantes
previos.
 Cualquier otros requerimientos esenciales para el diseño y
desarrollo.
 ¿Se han establecido planes de diseño y asignado
responsabilidad para cada proyecto?
Son revisados los datos de entrada del diseño para asegurar su X

adecuación y resueltos los requerimientos incompletos, ambiguos o
conflictivos entre sí.
116

Sí No N/A
7.3.3 Salidas del diseño y desarrollo
Son verificadas las salidas del diseño y desarrollo en forma que X Verbal únicamente.
permitan su verificación contra las entradas del diseño y desarrollo.
 ¿Han sido documentados los resultados finales del diseño
como requerimientos que pueden ser verificados?
Son aprobadas las salidas del diseño previo a su liberación. X Verbal únicamente.
Las salidas del diseño y desarrollo reúnen las siguientes condiciones: X

 Requerimientos de entrada del diseño y desarrollo.
 Proporcionan información apropiada para compras, operación
de producción y provisión de servicio.
 Contiene o hacen referencia a los criterios de aceptación del
producto.
 Definir las características del producto que son esenciales
para su seguridad y uso apropiado.
7.3.4 Revisión del diseño y desarrollo

Se conducen en etapas adecuadas y de acuerdo a los arreglos X Verbal únicamente.
planeados, revisiones sistemáticas del diseño y desarrollo para:
 Evaluar la capacidad de los resultados del diseño y desarrollo
para que cumpla con los requerimientos.
 Identificar los problemas y proponer acciones de seguimiento
necesarias.
 ¿Han sido conducidas las revisiones de diseño y X
documentadas formalmente según el plan de diseño?
Se incluye entre los participantes en tales revisiones a representantes X No siempre.

de funciones concernientes con la etapa de diseño y el desarrollo que
está siendo revisada.
Son registrados los resultados de las revisiones y las acciones X Documentación informal.
subsiguientes de seguimiento.
7.3.5 Verificación del diseño y desarrollo

Se realizan verificaciones del diseño y desarrollo de acuerdo al los X Visual únicamente, sin documentación formal.
117
7.3.5 Verificación del diseño y desarrollo

Se realizan verificaciones del diseño y desarrollo de acuerdo al los X Visual únicamente, sin documentación formal.
arreglos planeados para asegurar que las salidas del diseño y
desarrollo han satisfecho los requerimientos de entrada del diseño y
desarrollo. X
 ¿Se llevan a cabo la inspección y pruebas finales de
acuerdo a los procedimientos escritos?
 ¿Se asegura que el producto es entregado hasta que se han X
complementado satisfactoriamente todas las actividades
especificadas en los procedimientos?
Son registrados y mantenidos los resultados de la verificación y las X Verbal únicamente.
acciones de seguimiento.
118
7.3.6 Validación del diseño y desarrollo
Se realizan validaciones del diseño y desarrollo de acuerdo a los X Verbal únicamente.

arreglos planeados para asegurar que el producto resultante es capaz
de cumplir los requerimientos para la aplicación especificada o uso no
intencionado, donde sea conocido.
 ¿Ha sido realizada la validación del diseño en las X
frecuencias especificadas, anotando los resultados y
asignando responsables para la solución de fallas?
Cuando así es aplicable, se completa la validación antes de la X Necesario por la propia actividad de desarrollo de
entrega o implantación del producto. sistemas.
Son registrados y mantenidos los resultados de la validación y las X Verbal únicamente.

acciones necesarias de seguimiento.
7.3.7 Control de cambios al diseño y desarrollo
Son identificados, y mantenidos los registros de los cambios del X
diseño y desarrollo.
 ¿Se ha obtenido una aprobación por escrito o una X
desviación del cliente previo a la implantación de un cambio
de diseño en producción?
Son revisados, verificados y validados los cambios, según sea X
apropiado, y aprobados antes de la implantación.
 ¿Son documentados y aprobados los cambios de diseño por X
personal autorizado antes de su implantación?
Se incluye en le control anterior la evaluación del efecto de los X

cambios en las partes, componentes y productos entregados.
Son registrados y mantenidos los resultados de la revisión de los X

cambios y las acciones necesarias de seguimiento.
119
Requerimiento ISO 9001: 7. Realización del producto / 7.4 Compras

Personal Auditado

Sí No N/A
7.4.1 Control de compras
Controla el área sus procesos de compras para asegurar que el X
producto comprado esté conforme con los requerimientos
especificados.
El tipo y la extensión del control en los procesos de compra dependen X
del efecto del producto comprado en los procesos subsecuentes de
realización del producto o el producto final.
Evalúa y selecciona el área a sus proveedores basado en su X
capacidad de suministrar el producto de acuerdo con los
requerimientos de el área.
Se tiene definidos los criterios para la selección, evaluación y re- X
evaluación de los proveedores.
Se mantienen registros de los resultados de las evaluaciones y de las X
acciones subsecuentes generadas del seguimiento.
7.4.2 Información de compras
Contienen los documentos de compra información describiendo el X
producto a ser comprado, incluyendo donde sea apropiado:
 Requerimientos para la aprobación del producto,
procedimientos, procesos, equipos.
 Requerimientos para la calificación del personal.
 Requerimientos del sistema de administración de calidad.
El área asegura que los requerimientos especificados contenidos X
enlos documentos de compra antes de la comunicación con el
proveedor son los adecuados.
7.4.3 Verificación del producto comprado
120
Tiene el área identificadas y aplicadas las inspecciones y las X

actividades necesarias para asegurar que los productos comprados
cumplen los requerimientos de compra especificados.
Si se establece o el cliente establece realizar verificaciones de las X
instalaciones de los proveedores, se tienen establecidos los arreglos
de la verificación propuesta y método de liberación del producto en la
información de compra.
Requerimiento ISO 9001: 7. Realización del producto / 7.5 Producción y provisión del servicio
Personal Auditado

Sí No N/A
7.5.1 Control de producción y provisión del servicio.
Se planean y se llevan a cabo la producción y la provisión del servicio X
bajo condiciones controladas.
Controla el área las operaciones de producción y servicio mediante:
 Disponibilidad de información que especifica las
características del producto. X Artefactos de RUP.
 Donde sea necesario, la disponibilidad de instrucciones de
trabajo. X
 Uso de equipo adecuado.
 Disponibilidad y uso de dispositivos de medición y monitoreo. X Herramientas usadas por RUP.
 ¿Se tiene un proceso para validar lo correcto y completo de
las versiones de los sistemas? X
 Implantación de actividades de monitoreo y medición. X
 Implantación de procesos definidos para la liberación, entrega X
y las actividades aplicables de post-entrega.
7.5.2 Validación de procesos para producción y provisión del servicio
121
Lleva a cabo el área validaciones de los procesos de producción y X

servicio donde la salida resultante no puede ser verificada mediante
medición o monitoreo subsecuente, incluyendo cualquier proceso
donde las deficiencias pueden llegar a ser aparentes solo después de
que el producto está en uso o el servicio ha sido entregado.
Las validaciones permiten demostrar la capacidad de los procesos X
para lograr los resultados planeados.
Se tienen definidos los arreglos para la validación incluyendo, según X
sea aplicable:
 Criterios definidos para la revisión y aprobación de los
procesos.
 Aprobación de equipo y calificación del personal.
 ¿Se tiene claramente definido el rol, responsabilidad, y X Únicamente en ls casos en que el cliente es personal del
obligaciones del cliente y de la Gerencia, en la etapa de Banco.
instalación, considera aspectos como: calendario de acceso a
los sistemas, incluyendo fines de semana y horario fuera de
la jornada de trabajo, acceso a las instalaciones del cliente y
sus restricciones, disponibilidad de acceso a los sistemas y
equipo del cliente, disponibilidad de personal del cliente
necesario para alguna autorización, posible validación en
cada instalación, proceso de aprobación de cada instalación
al cierre?
 Uso de metodologías y procedimientos específicos.
 Requerimientos de registros.
 Re validación.
7.5.3 Identificación y rastreabilidad
Se mantiene identificado, según sea apropiado, el producto por X Herramientas de RUP.
medios adecuados a través de las etapas de realización del producto.
 ¿Se tiene un procedimiento para administrar las versiones X Herramientas de RUP.
de las aplicaciones, respaldos y procesos de recuperación
en caso de desastre?
 ¿Se tiene algún mecanismo para identificar el estado del X En definición.
software a lo largo de las etapas, desde desarrollo hasta
implantación?
Se mantiene identificado el estado del producto con respecto a los X
requerimientos de las mediciones y monitoreos.
Se mantiene un control y registro de la identificación única del X
producto, donde la rastraebilidad es un requerimiento.
 ¿Existe un procedimiento de replicación que incluya: el X
número de copia de cada software a ser liberado, el medio
de almacenamiento, incluyendo formato y versión, la
122
Se mantiene un control y registro de la identificación única del X

producto, donde la rastraebilidad es un requerimiento.
 ¿Existe un procedimiento de replicación que incluya: el X
número de copia de cada software a ser liberado, el medio
de almacenamiento, incluyendo formato y versión, la
documentación estipulada como manuales y guías de
usuario, derechos de autor, licencias, otros, custodia del
original y copias de respaldo para casos de desastre?
7.5.4 Propiedad del cliente
Se ejerce un adecuado cuidado con la propiedad del cliente mientras X
está bajo el control de el área o siendo usado por el área.
Se mantiene un control de identificación, verificación, protección y X
salvaguarda de la propiedad de cliente proporcionada para el uso o
incorporación en el producto.
 ¿Se tiene algún mecanismo de almacenamiento, protección X
y mantenimiento a los productos o información
proporcionados por el cliente?
Se mantienen registros y se reporta al cliente cuando cualquier X
propiedad de éste se pierda, dañe o de otro modo es encontrada
inapropiada para el uso.
Nota: La propiedad del cliente puede incluir propiedad intelectual.
7.5.5 Conservación del Producto
Se mantiene un control para asegurar que se conserva la X
conformidad del producto con los requerimientos de cliente durante el
procesamiento interno y la entrega al destino intencionado.
 ¿Se tienen planes de mantenimiento a los sistemas y/o X
equipos donde se incluye: alcance del mantenimiento,
identificación del estado actual del sistema o equipo,
personal responsable de la Gerencia y representante por
parte del cliente, tipo de mantenimiento(solución de
problemas originados por ellos, modificación de interfase,
expansión funcional o mejoramiento del desempeño),
actividades del mantenimiento, registros y reportes de
mantenimientos anteriores?
El control antes mencionado incluye la identificación, manejo X
empaque, almacenamiento y protección del producto.
 ¿Se tiene un procedimiento para liberar la nueva versión con X
los cambios realizados, que considera: si se implanta una
parte del sistema o una copia completa del sistema,
calendario de liberación de la nueva versión, proceso para
confirmar que los cambios implantados no provocan ningún
problema, registros a levantar que señalan qué cambios
fueron implantados en qué localidad(para el caso de varios
sites y varios productos)?
El control mencionado incluye a las partes componentes de un X
producto.
123
Requerimiento ISO 9001: 7 Realización del producto / 7.6 Control de dispositivos de medición y monitoreo
Personal Auditado

Sí No N/A
Se tienen identificadas las mediciones y monitoreos a ser realizadas y X
los dispositivos de medición y monitoreo requeridos para proveer
evidencia de la conformidad del producto con los requerimientos
especificados.
 ¿Se realiza un proceso específico para registrar, administrar X
y reportar la realización y resultados de las inspecciones y
pruebas?
Se tienen establecidos los procesos que aseguren que los monitoreos X
y mediciones pueden ser efectuadas y son efectuadas de manera que
sea consistente con los requerimientos de monitoreo y medición.
Se mantiene un control sobre los dispositivos de medición y X
monitoreo que incluya, según sea aplicable para asegurar resultados
válidos:
 Calibración o verificación a intervalos especificados o antes
de su uso, contra estándares de medición rastreables a
estándares o nacionales y donde tales estándares no existe,
la base usada para la calibración es registrada.
 Ajustado y re ajustado según se requiera.
 Identificación para permitir que el estado de calibración sea
determinado.
 Protección contra ajustes que invalidarían la calibración.
 Protección de daño y deterioro durante el manejo,
mantenimiento y almacenamiento.
Se evalúa y registra la validez de los resultados de medición previos X
cuando se encuentra un equipo no conforme con los requerimientos y
las acciones apropiadas sobre el equipo y cualquier equipo afectado.
124
Se mantienen los registros de los resultados de las calibraciones y X

verificaciones de los equipos.
 ¿El equipo de inspección, medición y pruebas (incluyendo X
software) utilizado, es capaz de dar la exactitud y precisión
requeridas?
Es confirmada la capacidad para satisfacer la aplicación intencionada X
al software usado para la medición y monitoreo de requerimientos
especificados, previo al uso inicial y reconfirmado según sea
necesario.
 ¿Se aseguran las instalaciones de inspección, medición y X
pruebas (incluyendo software cuando sea aplicable) para
garantizar que la calibración no sea alterada?
125
Requerimiento ISO 9001: 8 Medición, análisis y mejora / 8.1 General

Personal Auditado

Sí No N/A
Se tienen planeados e implementados los procesos de monitoreo, X
medición, análisis y mejora necesarios para:
 Demostrar la conformidad del producto.
 Asegurar la conformidad del sistema de administración de
calidad.
 Mejorar continuamente la efectividad del sistema de
 ¿Se ha identificado en la Gerencia la necesidad de técnicas
estadísticas para establecer, controlar y verificar la habilidad
de los parámetros del proceso y las características del
producto?
En esta planeación se tienen incluidos la determinación de métodos X

aplicables, incluyendo técnicas estadísticas y la extensión de su uso.
 ¿Se establecen y mantienen procedimientos para implantar
y controlar la aplicación de técnicas estadísticas?
126
Requerimiento ISO 9001: 8 Medición, análisis y mejoras / 8.2 Monitoreo y medición

Personal Auditado

Sí No N/A
8.2.1 Satisfacción del cliente
Se mantiene un mecanismo para monitorear la información en X
relación con la percepción del cliente en cuanto al cumplimiento de
los requerimientos.
Se tiene definidas las metodologías para obtener y usar esta X
información.
8.2.2 Auditoría Interna
Conduce el área auditorías internas a intervalos planeados para X
determinar si el sistema de administración de calidad:
 Está conforme con los arreglos planeados, con los
requerimientos de este estándar internacional y con los
requerimientos del sistema de administración de calidad
establecido.
 Ha sido efectivamente implantado y mantenido.
Se tiene planeado un programa de auditoría tomando en X

consideración el estado y la importancia de las actividades y áreas a
ser verificadas así como también los resultados de auditorías previas.
Se tiene definidos los criterios de auditoría, alcance, la frecuencia y X
las metodologías.
La selección de auditores y conducción de las auditorías aseguran la X
objetividad e imparcialidad del proceso de auditorias.
Se aseguran de que los auditores no auditen su propio trabajo. X
127
Se tiene definido un procedimiento documentado en el que se X

incluyan las responsabilidades y los requerimientos para la
planeación y conducción de las auditorías, así como reportar los
resultados y el mantenimiento de los registros.
Se aseguran de que la gerencia responsable del área auditada toma X

acciones sin retraso indebido, para eliminar las no conformidades y
sus causas.
Las actividades de seguimiento incluyen la verificación de las X

acciones tomadas y se reportan los resultados de la verificación (Ver
8.5.2).
128

Sí No N/A
8.2.3 Monitoreo y medición de procesos
Se aplican métodos adecuados para monitorear y donde sea X
aplicable se miden los procesos del sistema de administración de
calidad.
¿Existe algún mecanismo para identificar problemas y sus
posibles impactos, así como su notificación a los responsables
de la solución y seguimiento?
Permiten demostrar estos métodos la capacidad para alcanzar los X
resultados planeados.
Se toman acciones de corrección y acciones correctivas según sea X
apropiado que aseguren la conformidad del producto cuando los
resultados planeados no son alcanzados.
8.2.4 Medición y monitoreo de producto
Se monitorean y se miden las características del producto para X
verificar que los requerimientos para el producto se cumplen.
 ¿Se siguen: las inspecciones y pruebas a los sistemas y pruebas
de aceptación, casos de pruebas, datos de prueba y resultados
esperados, tipos de pruebas a ser desarrollados: pruebas
funcionales, de desempeño, ambiente de las pruebas, herramientas
y pruebas de software, criterios de aceptación, personal requerido o
capacitación requerida asociada?
¿Antes de entregar los sistemas o aplicaciones, se realiza una
prueba al final del desarrollo, de preferencia en un ambiente similar
de operación?
Las actividades de monitoreo son llevadas a cabo en etapas X
apropiadas del proceso de realización del producto y de acuerdo a los
arreglos planeados.
Se mantiene la evidencia de conformidad con los criterios de X
aceptación.
Indican los registros la autoridad responsable de la liberación del X
producto.
Se asegura que la liberación del producto y la entrega del servicio no X
proceda hasta que todos los arreglos planeados hayan sido
completados satisfactoriamente, a menos que se haya aprobado de
otra manera por una autoridad relevante y cuando sea aplicable por el
cliente.
129
Requerimiento ISO 9001: 8 Medición, análisis y mejoras / 8.3 Control de producto no conforme.
Personal Auditado

Sí No N/A
Se asegura que el producto no esté conforme con los requerimientos X
es identificado y controlado para prevenir el uso o entrega no
intencionado.
Se tiene definidas las actividades de control, responsabilidad y X
autoridades relacionadas para tratar el producto no conforme en un
procedimiento documentado.
 ¿Se tienen identificados a los sistemas que no cumplen con X
los requisitos de documentación, de programación, y otros?
Se trata el producto no conforme por alguno o más de los siguiente X
métodos:
 Tomando acciones para eliminar la no conformidad
detectada.
 Autorizando su uso, liberación o aceptación bajo concesión
por una autoridad relevante y, cuando sea aplicable, por el
cliente.
 Tomando acciones para imposibilitar su uso o aplicación
original intencionada.
Se mantienen los registros d el as no conformidades y cualquier X

acción subsecuente tomada incluyendo concesiones obtenidas.
Es sujeto a una reverificación el producto no conforme corregido con X
la finalidad de demostrar su conformidad con los requerimientos.
Se toman acciones apropiadas a los efectos, o efectos potenciales de X Informal, de palabra únicamente
la no conformidad cuando el producto no conforme es detectado
después de la entrega o después de que su uso ha sido iniciado.
130
Requerimiento ISO 9001: 8 Medición, análisis y mejoras / 8.4 Análisis de datos

Personal Auditado

Sí No N/A
Lleva a cabo el área actividades para determinar, recolectar y analizar X
los datos apropiados para demostrar la adecuación y la efectividad
del sistema de administración de calidad y para evaluar en donde
puede ser efectuada la mejora continua de la efectividad del sistema
de administración de calidad, incluyendo los datos generados como
resultados de los procesos de monitoreo, medición y otras fuentes
relevantes.
 ¿Se establecen y mantienen procedimientos para implantar X
y controlar la aplicación de mediciones al software
(métricas), con efectos de cumplir algún requisito del cliente,
o de cumplir con un requisito interno que permita
objetivamente evaluar el software desarrollado?
Efectúa el área análisis de los datos antes mencionados para X
proporcionar información en cuanto a:
 La satisfacción del cliente.
 Conformidad con los requerimientos del producto.
 Características y tendencias de procesos y productos,
incluyendo oportunidades para ación preventiva.
 Proveedores.
 ¿Se les da un uso posterior a las métricas aplicadas al
software?
131
Requerimiento ISO 9001:

Personal Auditado

Sí No N/A
8.5.1 Mejora continua
El área mejora continuamente la efectividad del sistema de X
administración de calidad mediante el uso de la política de calidad,
objetivos de calidad, resultados de auditoría, análisis de datos, acción
correctiva y preventiva y revisión de la gerencia.

Se toman acciones para eliminar la causa de no conformidades con el X
fin de prevenir su recurrencia.
 ¿Se analiza el proceso completo, operaciones de trabajo,
registros de calidad, reportes de servicio, y quejas del cliente
para detectar y eliminar causas potenciales de no
conformidades en los productos?
Las acciones correctivas tomadas son apropiadas a los efectos de las X
no conformidades encontradas.
Mantiene un procedimiento documentado que defina los X
requerimientos para:
 Revisión de las no conformidades (incluyendo quejas del
cliente).
 Determinar las causas de las no conformidades.
 Evaluar la ncesidad de acciones para asegurar que las no
conformidades no vuelvan a ocurrir.
 Determinar e implantar la acción correctiva necesaria.
 Registrar los resultados de la acción tomada (Ver 4.2.4).
 Revisión de la acción correctiva tomada.
132

Sí No N/A
Se toman acciones preventivas para eliminar las causas de no X
conformidad potenciales para prevenir la recurrencia.
 ¿Se cuenta con un procedimiento de cambios a procesos en
la Gerencia?
Las acciones preventivas tomadas son apropiadas a los efectos de X

los problemas potenciales.
 ¿Se envía a la Gerencia para su revisión la información
relevante de las acciones tomadas incluyendo cambios a los
procedimientos y una matriz de seguimiento de los
requerimientos de acciones correctivas y preventivas?
Se tiene establecido un procedimiento documentado para definir los X

requerimientos para:
 Identificar las no conformidades potenciales y sus causas.
 Evaluar la necesidad de acciones para prevenir la ocurrencia
de las no conformidades.
 Determinar e implantar la acción preventiva necesaria.
 Registrar los resultados de la acción tomada (Ver 4.2.4).
 Revisar la acción preventiva tomada.
133
4.3 Comentarios.
Lo que se ha presentado anteriormente, en las tablas, corresponde a los criterios de la
norma ISO 9001:2000, en los casos en donde se presentó como no, el área deberá generar
los mecanismos y documentación para tener un proceso estable, sistemático que evite la
pérdida de seguimiento y mejora, es decir, para que cumpla los requerimientos del sistema
de calidad. En los casos marcados con sí se tienen las siguientes observaciones:
En el punto 4, Sistema de administración de calidad, específicamente en el 4.1, la Gerencia

ha identificado qué procesos desea sean administrados bajo el sistema de gestión de
calidad, que es el desarrollo de sistemas, esto lo hace bajo la metodología RUP, la cual
indica qué debe medirse y cómo, así como monitorearse y analizarse con la finalidad de
identificar acciones de mejora, esto lo realiza de manera parcial ya que el uso de esta
metodología de sistemas es relativamente nueva, sin embargo para efectos de la norma,
aún existen áreas de mejora de tal forma que no se tiene el cumplimiento deseado.
En el punto 4.2, que son Requerimientos de documentación, el área no cuenta con una
política de calidad expresa, se realizaron esfuerzos para establecer la misión, visión,
valores y objetivos de calidad, pero no así de una política para la Gerencia, por ende, no
existe ningún tipo de documentación que satisfaga los requerimientos de la norma, salvo
algunos artefactos generados por la metodología de desarrollo RUP, por lo que se tendrá
de realizar un esfuerzo de revisión de estos documentos y analizar cómo pueden satisfacer
este requerimiento.
Para el punto 5.1, Compromiso de la Gerencia, se tiene el apoyo por parte de la Gerencia,
sin embargo no se ha cuenta con ningún tipo de evidencia al respecto.
En el punto 5.4, Planeación, específicamente en 5.4.1, el área cuenta con tres objetivos
generales de calidad, que se desarrollaron en un taller en conjunto con otros directivos, por
otro lado falta la planeación de cómo llevarlos a cabo, así como la planeación del sistema de
gestión de calidad, lo cual genera un incumplimiento a este requisito de la norma.
En el punto 5.5, específicamente 5.5.1, Responsabilidad y autoridad, se tienen definidas las
responsabilidades y autoridades dentro de la organización, sin embargo no se tienen
debidamente documentadas, esto genera un incumplimiento a la norma,
En el punto 6.1, Provisión de recursos, se ha determinado y proporcionado los recursos
necesarios para implantar el sistema de administración de calidad, sin embargo no se tiene
evidencia escrita de esto, salvo lo expresado, por lo que se deberá hacer un esfuerzo en
este punto.
En el punto 6.2.1, en el apartado de Recursos humanos, en la sección de General,
efectivamente, el área se asegura que el personal que realiza actividades que afecta la
calidad del producto es competente ya que se le proporciona la capacitación que requieren,
sin embargo no se tiene esto bajo un mecanismo formal de capacitación, por lo que es
necesario enfocar algunos esfuerzos a este respecto.
En cuanto al 6.3, Infraestructura, el área cuenta con la infraestructura necesaria para
alcanzar la conformidad del producto, en cuanto a las áreas de trabajo, equipo y servicios
de comunicación.
Por otro lado, se cuenta con un cumplimiento al punto 6.4, Medio de trabajo, ya que el área
proporciona los medios de trabajo necesarios para alcanzar la conformidad de los
requerimientos del producto, éstos son productos de software, hardware, esto se tiene bajo
inventario y al alcance del personal que desarrolla sistemas.
En el punto 7.1, Planeación de la realización del producto, debido a la metodología de
desarrollo RUP, se lleva a cabo una planeación de los desarrollos a efectuar, en donde se
documenta a través de los artefactos generados, los objetivos y requerimientos de
producto, procesos y recursos a utilizar, así como actividades de verificación, monitoreo, e
inspección y pruebas.
En cuanto al punto 7.2.1, Determinación de requerimientos relacionados al producto, 7.2.2,
Revisión de requerimientos de producto, a través de la metodología de desarrollo RUP, con
la disciplina de requerimientos se cumplen algunos de los puntos de este apartado.
134
Similar al punto anterior, en el punto 7.3.1, Planeación del diseño y desarrollo, a través del
uso de la metodología RUP, se cumplen este requerimiento.
Respecto al punto 7.3.3, Salidas del diseño y desarrollo, 7.3.4, 7.3.5 y 7.3.6, por la misma
actividad de desarrollo de sistemas, es necesario llevar a cabo esta actividad antes de que
los sistemas sean liberados, por lo que es necesario probar el sistema siempre antes de su
entrega, sin embargo no siempre existe una evidencia en papel de esta actividad, por lo que
se deberá realizar un esfuerzo al respecto para formalizar esta actividad.
Al hacer uso de la metodología de desarrollo RUP, se cumplen con algunos puntos de la
sección 7.5.1, Control de producción y provisión del servicio, ya que al generar los
artefactos especificados en ella, se cuenta con la información que especifica las
características del producto, y obliga que se haga uso de el equipo adecuado para el
desarrollo de sistemas, de la misma forma sucede con el punto 7.5.3 y 8.2.4.
Por la naturaleza del desarrollo de sistemas, se cumple con lo especificado en el punto
8.5.2, Acción correctiva.
A manera general, muchos de los procesos que se tienen en el área funcionan, sin un
mecanismo formal, por lo que será necesario un análisis de los mismos para generar los
indicadores necesarios aplicables según el caso.
En el capítulo siguiente, se definirán algunos proyectos que deberán ser llevados a cabo
para cumplir con el sistema de gestión ISO 9000:2000.
135
CAPÍTULO V
PROPUESTA DE IMPLANTACIÓN DEL SISTEMA DE GESTIÓN ISO-9001:2000 PARA EL
PROCESO DE DESARROLLO DE SOFTWARE.
136
Capítulo V. PROPUESTA DE IMPLANTACIÓN DEL SISTEMA DE GESTIÓN ISO-

9001:2000 PARA EL PROCESO DE DESARROLLO DE SOFTWARE.
El objetivo de este capítulo, es mostrar en esencia, la guía para la aplicación de los

proyectos de calidad propuestos en esta tesis, es el planteamiento de una propuesta para la
implantación del sistema de calidad, con base en un diagnóstico del área. En este punto, se
tratarán los aspectos de los que trata la norma ISO 9001:2000, enfocándolos al proceso de
desarrollo de software que hace uso de la metodología RUP.
LA CALIDAD Y EL DESARROLLO DE SOFTWARE.
5.1 Implantación del sistema.

Para cualquier tipo de organización, es muy importante mantenerse en el mercado, o hacer
óptimos sus procesos, para el Banco de México aplica de la misma forma, aunque no sea
una empresa privada, de igual forma, su principal interés, es satisfacer las necesidades de
sus clientes, por lo que es necesario establecer estrategias que le ayuden en el
cumplimiento de su meta.
Una de las estrategias que se propone, es la implantación de un sistema de gestión de

calidad, esto, con la finalidad de normalizar la forma de hacer las cosas además de hacerlas
a través de un proceso de mejora continua en la Gerencia.
Se ha demostrado, a través de la implantación de sistemas de gestión de calidad, que las
empresas obtienen algunos de los siguientes beneficios:
 Mejora la productividad
 Disminuye costos de falla
 Facilita las relaciones cliente – proveedor
 Mejora la imagen de la empresa
 Facilita el acceso a nuevos mercados
 Propicia la mejora continua
 Ayuda a la adopción de una cultura de calidad
 Permite avanzar más rápido al implantar un sistema de calidad total
Después de haber tomado la decisión, se recomienda:

 Designar a un comité de calidad.
 Designar a un representante de la dirección.
 Informarse en cuestiones de calidad.
 Obtener información acerca de la familia ISO9000.
 Revisar y usar la norma ISO 9001:2000 para la generación de un sistema de
gestión.
 Definir el alcance deseado de la certificación.
 Realizar un diagnóstico de la organización.
 Planear la implantación del sistema de gestión.
 Comprometerse con el sistema de gestión.
 Documentar el sistema de gestión.
 Capacitar al personal sobre el sistema de gestión.
 Implantar el sistema de gestión.
 Realizar auditorías al sistema.
 Mantener el sistema.
137
5.2 Estrategia de implementación propuesta.

Para proponer una estrategia de implementación, es necesario conocer algunas fortalezas y
debilidades, éstas son:
Fortalezas.
 Personal con alta disposición a la mejora.
 Proyectos de mejora llevándose a cabo.
 Propuestas de mejora presentadas.
Debilidades.
 Recursos humanos escasos para el desarrollo de este proyecto.
 Falta de experiencia y capacitación en la implantación de la norma ISO-9001:2000.
Detalles de la estrategia.
La estrategia que se propone considera el aprovechar al máximo los logros obtenidos hasta
el momento, formalizándolos dentro del sistema de gestión de calidad y que el cambio en la
metodología de desarrollo, la organización y la cultura se den de forma simultánea para
tener avances tangibles en la implantación del sistema de calidad. Para lo cual, se
establecen las siguientes líneas de acción:
1. La creación de un comité de calidad, con la responsabilidad y autoridad necesarias para

lograr la implantación del sistema de gestión de calidad basado en ISO9001:2000. Se
pretende con esto formalizar el compromiso y la responsabilidad de las personas que
actualmente llevan a cabo acciones encaminadas a mejorar la calidad del proceso.
2. Realizar un diagnóstico, que nos permita visualizar el estado de la Gerencia en relación a
los requisitos que marca la norma ISO 9001:2000.
3. Elaborar un plan de calidad, de acuerdo a los resultados obtenidos del diagnóstico, en
donde se establezca qué acciones a tomar se necesitan para cumplir con los requisitos de
la norma.
5.3 Propuesta de implementación.

De acuerdo a la estrategia de implementación propuesta, se plantea lo siguiente:
Detalles de las líneas de acción.

Línea 1 . Estructura del equipo de calidad.
Para una mejor organización en la implantación de ISO 9001:2000, se propone establecer la
siguiente estructura del equipo de calidad:
 Comité de calidad
o Representante de la dirección (Gerente de Informática)
 Equipo central
 Equipo de procesos
El equipo central y de procesos, reportarán a la Dirección de sistemas operativos y de

pagos, así como a la Gerencia de Informática que será el Representante de la dirección.
El comité de calidad, tendrá las siguientes funciones:

 Revisar y aprobar los planes del desarrollo del sistema de calidad
 Colaborar en la definición de los proyectos de mejora
 Revisar el progreso de los proyectos de mejora
El Gerente de Informática como representante de la dirección tendrá las siguientes

funciones:
 Colaborar en el establecimiento de una política de calidad
138
 Establecer objetivos de calidad

 Asumir el liderazgo de la calidad en la Gerencia
 Aprobar planes del desarrollo del sistema de calidad
 Aprobar y apoyar la infraestructura relacionada con esfuerzos de calidad (equipos
de trabajo)
 Aprobar los principales indicadores de calidad en la Gerencia
 Aprobar un plan de difusión de las actividades de calidad
Bajo esta estructura, se propone visualizar a los requisitos de la norma como proyectos a
desarrollar.
Comité de
Calidad
C.C.
Equipo Equipo de
central procesos
E.C. E.P.
Analista de Sistemas
DIRECCIÓN DE GERENCIA DE
SISTEMAS INFORMÁTICA
OPERATIVOS Y DE “REPRESENTANTE
PAGOS DE LA DIRECCIÓN”
Equipo central
SUBGERENCIA DE SUBGERENCIA DE  Proyectos relacionados a los requisitos
DESARROLLO DE INFORMÁTICA DE 4.0, 5.0 y 6.0 de la norma ISO 9001:2000
INFRAESTRUCTURA ATENCIÓN A
INFORMÁTICA USUARIOS
Comité de Calidad
 Encargado de definir y dar seguimiento a
las actividades propias del sistema de
Analista de Sistemas
gestión de calidad.
Equipo de procesos
 Proyectos relacionados a los requisitos
7.0 y 8.0 de la norma ISO 9001:2000
Equipo de trabajo para la certificación bajo ISO 9001:2000
RMCG 04/09/2003 Banco de México
Figura 5.1. Estructura del equipo de calidad.
139
Definición
Diagnóstico de la
situación actual, bajo
el estándar ISO
9001:2000
Despliegue de
Auditorias al Certificación del Monitoreo del
documentación
Definición sistema de sistema de proceso y
del sistema de
calidad calidad mejora continua
de Alcance calidad
 Difundir la  Realizar  Seleccionar  Tener

política de auditorías certificador auditorías
Desarrollo de la
calidad internas al  Solicitar la cada de
documentación del
sistema de calidad  Implantar proceso certificación vigilancia
nuevos  Implantar  Agendar  Implantar
procesos de primeras auditoría proceso de
acuerdo a los acciones inicial mejora
 Desarrollar el requisitos correctivas y  Implantar continua
manual de que marca la preventivas acciones
calidad de la norma correctivas
Gerencia de  Implantar  Agendar
Informática instructivos y auditoría de
 Definir los registros de certificación
procesos de calidad  Obtener la
acuerdo a las  Reunir certificación
cláusulas de evidencia
la norma ISO
9001
 Desarrollar
instructivos y
Etapas para la certificación bajo ISO 9001:2000
registros de
calidad
Figura 5.2. Pasos para la certificación.
140
Definición
 Equipo
central
Diagnóstico de la  Equipo de
situación actual, bajo procesos
el estándar ISO
9001:2000  Comité de
calidad
Despliegue de
Auditorias al Certificación del Monitoreo del
documentación
Definición sistema de sistema de proceso y
del sistema de
calidad calidad mejora continua
de Alcance calidad
 Equipo  Equipo  Equipo  Equipo

central central central central
Desarrollo de la  Personal de  Personal de  Personal de
documentación del  Equipo de
procesos la gerencia la gerencia la gerencia
sistema de calidad
 Personal de  Organismo  Organismo
la Gerencia certificador certificador
 Equipo  Equipo
central central
 Comité de  Equipo de
calidad procesos
 Personal de
la Gerencia
Equipo de trabajo para la certificación bajo ISO 9001:2000
Figura 5.3. Pasos para la certificación con detalle de involucrados.
Línea 2 . Realizar un diagnóstico.

Un diagnóstico, es un examen, para determinar si las actividades de la Gerencia y sus
resultados cumplen las disposiciones establecidas en la norma ISO 9001:2000.
Con el diagnóstico se pretendió:

Objetivos del diagnóstico.
Detectar condiciones actuales del proceso de desarrollo de software.
Determinar el cumplimiento de requisitos establecidos en la norma ISO 9001:2000
Establecer puntos de mejora para cumplir con los requisitos establecidos.
El diagnóstico, se realizó a través de la metodología siguiente:

Preparación.
 Revisión documental
 Elaboración del plan del diagnóstico
 Elaboración del cuestionario
 Notificación del diagnóstico a la Gerencia
Realización del diagnóstico
 Aplicación del cuestionario
 Análisis de la información
Informe del diagnóstico
 Elaboración del informe
141
 Entrega del informe
De acuerdo al diagnóstico elaborado, cuyo detalle se muestra en el capítulo anterior, se

puede observar que la mayoría de los requisitos de la norma no se tienen, y los que se
tienen no se llevan a cabo bajo un mecanismo formal, por lo que es necesario realizar
planes de mejora encaminados a cubrir los requisitos, designando encargados por inciso de
la norma, lo cual se detalla a continuación.
Línea 3 . Elaborar un plan de calidad

El plan de calidad, se orientará a avanzar en aquellos requisitos que marca la norma, que no
son específicos del proceso, como lo es el Sistema de gestión de calidad, Responsabilidad
de la dirección y Gestión de recursos (Requisitos 4.0, 5.0, 6.0 de la norma ISO 9001:2000).
Esta medida permitiría empezar a observar avances concretos en la implantación del
sistema de gestión de calidad, para posteriormente, continuar con los requisitos
relacionados con el proceso que marca la norma, que es Realización del producto y
Medición, análisis y mejora (7.0 y 8.0 respectivamente), lo cual permitiría iniciar el
empalme del proceso de desarrollo de software y la norma.
Durante la implantación de la norma, nos apoyaríamos en las directrices que marca ISO
9000-3 (Directrices para la aplicación de la norma ISO9001:1994 en el diseño, desarrollo,
suministro, instalación y mantenimiento de software para computadoras), para el proceso
de desarrollo de software.
El plan general se muestra en las figuras 5.2 y 5.2; a continuación se presenta la secuencia
de actividades a realizar para cumplir con las especificaciones expuestas en los cinco
puntos del sistema de gestión de calidad ISO 9001:2000.
Utilizando gráficas de Gantt se muestran los periodos planeados y estimados de avance

para poder cubrir los requerimientos que plantea la norma ISO 9001:2000.
Antes de iniciar con los gráficos de Gantt, es necesario recordar que en la figura 5.1,
Estructura del equipo de calidad, se establecieron dos equipos, uno central (E.C.) y otro de
procesos (E.P.) así como un comité de calidad (C.C.) para llevar a cabo los proyectos que
cubrirán los requisitos establecidos en la norma ISO 9001:2000. aunado a esto, se utilizará
la siguiente nomenclatura:
142
TIEMPO EN MESES
PROYECTO DE MEJORA RESPONSABLE 1 2 3 4 5 6 7 8 9 10 1
1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1
DEFINICIÓN DE LA PROPUESTA.
La Gerencia debe:
Definir los objetivos y políticas del proyecto D.S.O.P.
INVOLUCRAMIENTO DEL PERSONAL.
La Gerencia debe:
Sensibilizar al personal C.C.
Capacitar al personal en la norma ISO 9001:2000 C.C.
DESARROLLO DE LA DOCUMENTACIÓN
La Gerencia debe:
Establecer el procedimiento para hacer procedimientos A.S.
Elaborar los procedimientos obligatorios, como lo son el procedimiento de:
Auditoría interna, Control de documentos, Control de registros, Material no
conforme, Acciones correctivas y Acciones preventivas. A.S.
Elaborar la documentación necesaria para la operación E.C., E.P.
Elaborar el Manual de calidad R.D.
DESPLIEGUE DE DOCUMENTACIÓN DEL SISTEMA DE CALIDAD
La Gerencia debe:
Dar a conocer el sistema documentado al personal D.S.O.P.
Aplicar el sistema documentado en La Gerencia C.C., E.C., E.P.
Generar registros de aplicación C.C., E.C., E.P.
AUDITORÍAS AL SISTEMA DE CALIDAD
La Gerencia debe:
Capacitar auditores internos C.C.
Realizar auditorías internas A.S.
CERTIFICACIÓN DEL SISTEMA R.D.
MONITOREO DEL PROCESO Y MEJORA CONTINUA D.S.O.P. - R.D.
143
TIEMPO EN MESES
CRITERIO DE LA NORMA RESPONSABLE 1 2 3 4 5 6 7 8 9 10 11 1
1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1
4.0 SISTEMA DE GESTIÓN DE LA CALIDAD G.I.
4.1 REQUISITOS GENERALES G.I.
4.2 Requisitos de la documentación E.C.
4.2.1 Generalidades E.C.
4.2.2 Manual de la Calidad R.D.
4.2.3 Control de los documentos A.S.
4.2.4 Control de los registros E.C.
5. RESPONSABILIDAD DE LA DIRECCIÓN D.S.O.P.
5.1 Compromiso de la dirección D.S.O.P.
5.2 Enfoque al cliente G.I.
5.3 Políticas de la calidad C.C.
5.4 Planificación E.C.
5.4.1 Ojbetivos de la calidad C.C.
5.4.2 Planificación del sistema de gestión de la calidad D.S.O.P. - E.C.
5.5 Responsabailidad, autoridad y comunicación E.C.
5.5.1 Responsabilidad y autoridad D.S.O.P. - E.C.
5.5.2 Representante de la dirección R.D.
5.5.3 Comunicación interna A.S.
5,6 Revisión por la dirección D.S.O.P.
5.6.1 Generalidades C.C.
5.6.2 Información para la revisión E.C.
5.6.3 Resultados de la revisión E.C.
6. GESTIÓN DE LOS RECURSOS E.C.
6.1 Provisión de recursos G.I.
6.2 Recursos humanos E.C.
6.2.1 Generalidades G.I.
6.2.2 Competencia, toma de conciencia y formación C.C.
6.3 Infraestructura G.I.
144
TIEMPO EN MESES
CRITERIO DE LA NORMA RESPONSABLE 1 2 3 4 5 6 7 8 9 10 11
1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2
6.4 Ambiente de trabajo G.I.
7. REALIZACIÓN DEL PRODUCTO E.P.
7.1 Planificación de la realización del producto S.D.I.I.
7.2 Procesos relacionados con el cliente E.P.
7.2.1 Determinación de los requisitos relacionados con el producto. A.S.
7.2.2 Revisión de los requisitos relacionados con el producto. S.D.I.I.
7.2.3 Comunicación con el cliente S.I.A.U.
7.3 Diseño y desarrollo E.P.
7.3.1 Planificación del diseño y desarrollo S.D.I.I.
7.3.2 Elementos de entrada para el diseño y desarrollo S.D.I.I.
7.3.2 Resultados del diseño y desarrollo A.S.
7.3.4 Revisión del diseño y desarrollo A.S.
7.3.5 Verificación del diseño y desarrollo S.D.I.I.
7.3.6 Validación del diseño y desarrollo S.D.I.I.
7.3.7 Control de los cambos del diseño y desarrollo S.D.I.I.
7.4 Compras E.P.
7.4.1 Proceso de compras C.C.
7.4.2 Información de las compras A.S.
7.4.3 Verificación de los productos comprados A.S.
7.5 Producción y prestación del servicio E.P.
7.5.1 Control de la producción y de la prestación del servicio S.D.I.I.
7.5.2 Validación de los procesos de la producción y de la prestación del
servicio S.D.I.I.
7.5.3 Identificación y trazabilidad S.D.I.I.
7.5.4 Propiedad del cliente S.I.A.U.
7.5.5 Preservación del producto A.S.
7.6 Control de los dispositivos de seguimiento y de medición A.S.
145
TIEMPO EN MESES
CRITERIO DE LA NORMA RESPONSABLE 1 2 3 4 5 6 7 8 9 10 1
1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1
8. Medición, análisis y mejora E.P.
8.1 Generalidades G.I.
8.2. Seguimiento y medición E.P.
8.2.1 Satisfacción del cliente S.I.A.U.
8.2.2 Auditoría interna G.I.
8.2.3 Seguimiento y medición de los procesos. G.I.
8.2.4 Seguimiento y medición del producto S.D.I.I.
8.3 Control del producto no conforme S.D.I.I. - A.S.
8.4 Análisis de datos C.C.
8.5 Mejora E.P.
8.5.1 Mejora continua C.C.
8.5.2 Acción correctiva C.C. - A.S.
8.5.3 Acción preventiva C.C. - A.S.
En las gráficas de Gantt arriba presentadas, se plasman las acciones a seguir para la implantación del sistema de gestión de calidad,
los siguientes pasos serán generar planes de acción por cada uno de los requisitos de la norma, con la finalidad de cubrirla; se puede
apoyar esto en el diagnóstico previamente presentado en la sección 4.2.
146
5.4 Recomendaciones de ISO 9000-3 para el proceso de

Una estrategia mundialmente adoptada, ha sido la implementación del modelo de evaluación
y mejora del proceso de software diseñado por ISO 9000, específicamente la guía "Guía
para la aplicación de ISO 9001 para el desarrollo, implementación y mantenimiento de
software", ISO 9000-3, en la cual se define como aplicar la ISO 9001 al proceso de
software.
Aunque esta guía se encuentre orientada específicamente a ISO 9001:1994, considero que
podemos tomar algunas recomendaciones aplicables a la organización con un sistema de
gestión bajo ISO 9001:2000, claro dependiendo de cada organización.
El nivel de calidad incluido en los productos, fruto de un sistema de gestión como lo es ISO
9001:2000, considera muchas actividades dentro del desarrollo de los proyectos software,
sin embargo, no existe un límite de mejora, por lo que a continuación propongo algunas
recomendaciones de ISO 9000-3 para éstos.
Pautas de la ISO 9000-3.

La ISO preparó 9000-3:1997, que son las pautas para ayudar a organizaciones para aplicar
el estándar de la ISO 9001 al software. ISO 9000-3 se usa si la empresa provee, instala, y
mantiene software.
La ISO 9000-3:1997 es realmente una versión ampliada del viejo estándar de la ISO
9001:1994. La ISO ha tomado el texto de ISO 9001 y lo ha apegado en la nueva versión de
ISO 9000-3, y después ha agregado un poco de texto nuevo que se refiere solamente al
software.
Para el desarrollo de sistemas en la Gerencia, se propone lo siguiente, de acuerdo a su
situación.
A continuación, se citará a la norma ISO 9001:1994 y en esa parte se enfocará la

recomendación de ISO 9000-3 aplicable a la Gerencia.
ISO 9000-3: 4.1 Responsabilidades de la gerencia

ISO 9001:1994.
 Defina una política de la calidad. Su política debe describir la actitud de su
organización hacia calidad.
 Defina la estructura de organización que usted necesitará para manejar su sistema
de calidad.
o Defina las responsabilidades del sistema de calidad, dé a personal del
sistema de calidad la autoridad para realizar estas responsabilidades, y
asegúrese de que las interacciones entre este personal están especificadas
claramente. También, cerciórese de que todo el esto esté documentado bien.
o Identifique y proporcione los recursos que la gente necesitará para manejar,
para realizar, y para verificar el trabajo del sistema de calidad.
o Designe a ejecutivo "senior" para manejar su sistema de calidad y para dar
la autoridad necesaria.
 Defina un procedimiento que sus encargados mayores puedan utilizar para repasar
la eficacia de su sistema de calidad.
ISO 9000-3: 4.2 Requisitos del sistema de calidad

ISO 9001:1994.
147
 Desarrolle un sistema de calidad y un manual que lo describa.

 Desarrolle y ponga los procedimientos de sistema en ejecución de calidad que son
constantes con su política de la calidad.
 Desarrolle los planes de la calidad que demuestran cómo usted se propone
satisfacer requisitos del sistema de calidad. Desarrolle los planes de la calidad para
los productos, los procesos, los proyectos, y los contratos del cliente.
ISO 9000-3.
 Desarrolle los planes de la calidad a los proyectos del desarrollo del software de
control.
 Desarrolle un plan de la calidad siempre que usted necesite controlar la calidad de
un proyecto, de un producto, o de un contrato específico.
o Su plan de la calidad debe explicar cómo usted se propone adaptar su
sistema de calidad de modo que se aplique a su proyecto, producto, o
contrato específico.
o Desarrolle los planes y los procedimientos detallados de la calidad para
controlar la gerencia de la configuración, la verificación del producto, la
validación del producto, productos no conformes, y acciones correctivas.
ISO 9000-3: 4.3 Requisitos de la revisión de contrato

ISO 9001:1994.
 Desarrolle los procedimientos para coordinar la revisión de las órdenes de las
ventas y de los contratos del cliente. Cerciórese de incluir al cliente en el proceso
de la revisión.
ISO 9000-3.
o Desarrolle y documente los procedimientos para coordinar la revisión de los
contratos del desarrollo del software.
ISO 9001:1994.
 Los procedimientos de la revisión de contrato deben asegurarse de que todos los
requisitos contractuales sean aceptables antes de que usted acuerde proporcionar
productos o servicios a sus clientes.
ISO 9000-3.
o Cerciórese de que usted y su cliente del software convengan:
 Cómo los términos serán definidos.
 Cómo los productos serán aceptados.
 Cómo participará el cliente.
 Cómo capacitarán a los usuarios del software.
 Cómo las mejoras del software serán manejadas.
 Cómo las revisiones del progreso del empalme serán conducidas.
 Cómo los cambios en requisitos del cliente serán manejados.
 Cómo los problemas serán manejados después de la aceptación del
producto.
o Cerciórese de que usted y sus clientes convengan que:
 El proyecto es factible.
 Los derechos legales de otros serán respetados.
 El cliente puede sostener todas las obligaciones contractuales.
o Cerciórese de que usted tenga:
 Estableció un horario del proyecto.
 Riesgos y contingencias significativos identificados.
 Especificó todas las responsabilidades contractuales y penas.
 Definió sus procedimientos del desarrollo del software.
 Confirmado que los recursos estarán disponibles cuando sean
necesitados.
148
 Clarificó el grado de su responsabilidad de subcontratistas.

ISO 9001:1994.
 Desarrolle los procedimientos que especifican cómo se enmiendan los contratos del
cliente, y que asegúrese de que los cambios en contratos estén comunicados a
través de la organización.
 Desarrolle un sistema el guardar de registro que usted pueda utilizar para
documentar la revisión de las pedidos y de los contratos del cliente.
ISO 9000-3: 4.4 Requisitos del diseño de producto

ISO 9001:1994.
 Desarrolle los procedimientos para controlar el proceso del diseño y del desarrollo
de producto. Estos procedimientos deben asegurarse de que se estén resolviendo
todos los requisitos.
ISO 9000-3.
o Controle sus proyectos del desarrollo del software y cerciórese de que
están ejecutados de una manera disciplinada.
o Controle su proceso del diseño del software y cerciórese de que está
realizado en una manera sistemática.
ISO 9001:1994.
 Desarrolle los procedimientos del diseño de producto y del planeamiento del
desarrollo.
ISO 9000-3.
o Prepare un plan de desarrollo del software. Su plan debe ser documentado y
ser aprobado antes de que se ponga en ejecución. Su plan debe incluir:
 Defina su proyecto.
 Enumere los objetivos del proyecto.
 Presente su horario del proyecto.
 Defina las entradas y las salidas del proyecto.
 Identifique los planes y los proyectos relacionados.
 Explique cómo su proyecto será organizado.
 Discuta los riesgos del proyecto y los problemas potenciales.
 Identifique los aspectos importantes del proyecto.
 Identifique todas las estrategias relevantes del control.
ISO 9001:1994.
 Identifique a grupos que deben estar implicados rutinariamente en el proceso del
diseño y del desarrollo de producto, y asegúrese de que la entrada del diseño está
documentada, difundida, y verificada correctamente.
ISO 9000-3.
o Cerciórese de que su plan de desarrollo del software defina:
 Cómo la responsabilidad del desarrollo del software será distribuida
entre todos los participantes.
 Cómo la información técnica será compartida y transmitida entre
todos los participantes.
o Cerciórese de que su cliente haya aceptado la responsabilidad de cooperar y
de apoyar su proyecto del desarrollo del software.
o Cerciórese de programar revisiones del proyecto para evaluar las
actividades y los resultados alcanzados por todos los participantes.
ISO 9001:1994.
 Desarrolle los procedimientos para asegurarse de que todos los requisitos de la
entrada del diseño están identificados, documentados, y verificados; y que todos los
defectos de diseño, ambigüedades, contradicciones, y deficiencias están resueltos.
ISO 9000-3.
149
Los requisitos de la entrada del diseño se deben especificar por el cliente.

o
Sin embargo, el cliente esperará a veces que usted desarrolle la
especificación de entrada. En este caso usted debe hacer lo siguiente:
 Elabore los procedimientos que usted pueda utilizar para desarrollar
especificaciones de la entrada.
 Trabaje de cerca con su cliente para evitar malentendidos y
asegurarse de que la especificación resuelva las necesidades y las
expectativas de cliente.
 Exprese su especificación usando los términos que harán fácil validar
la aceptación del producto.
 Pida que su cliente apruebe la especificación de entrada resultante.
ISO 9001:1994.
 Desarrolle los procedimientos para controlar salidas del diseño.
ISO 9000-3.
o Elabore el diseño para generar documentos usando métodos estandardizados
y para cerciorarse de que sus documentos son correctos y completos.
ISO 9001:1994.
 Desarrolle los procedimientos que especifican cómo las revisiones de diseño de
producto deben ser planeadas y realizadas.
ISO 9000-3.
o Planee y realice las revisiones de diseño de producto para sus proyectos del
desarrollo del software.
o Desarrolle y documente los procedimientos de la revisión de diseño del
software.
ISO 9001:1994.
 Desarrolle los procedimientos que especifican cómo las salidas del diseño, en cada
etapa del proceso del diseño y del desarrollo de producto, deben ser verificadas.
ISO 9000-3.
o Verifique sus salidas del diseño del software realizando revisiones de
diseño, demostraciones, y pruebas.
o Mantenga un expediente de sus verificaciones del diseño.
ISO 9001:1994.
 Desarrolle los procedimientos que validan la asunción que sus productos
nuevamente diseñados resolverán necesidades de cliente.
ISO 9000-3.
o Pruebe que su producto es listo para su uso previsto antes de que usted
pida que su cliente lo acepte.
o Acepte los productos validados para el uso subsecuente solamente si se han
verificado y solamente si se han tomado todas las acciones preventivas.
o Mantenga un expediente de sus validaciones del diseño.
ISO 9001:1994.
 Desarrolle los procedimientos para asegurarse de que todas las modificaciones de
diseño de producto están documentadas, revisadas, y autorizadas formalmente antes
de que se circulen los documentos y los cambios estén puestos en ejecución.
ISO 9000-3.
o Desarrolle los procedimientos a los cambios del diseño del software de
control que puedan ocurrir durante el ciclo vital del producto.
ISO 9000-3: 4.5 Control de documentos y de datos

ISO 9001:1994.
 Desarrolle los procedimientos para controlar documentos y datos del sistema de
calidad.
ISO 9000-3.
150
o Identifique todos los documentos y datos que deban ser controlados.

o Desarrolle los procedimientos para controlar sus documentos y datos.
ISO 9001:1994.
 Desarrolle los procedimientos para repasar, para aprobar, y para manejar todos sus
documentos y datos del sistema de calidad.
ISO 9000-3.
o Desarrolle los procedimientos para controlar documentos y datos
electrónicos.
ISO 9001:1994.
 Desarrolle los procedimientos a los cambios de control a los documentos y a los
datos.
ISO 9000-3: 4.6 Requisitos de compras

ISO 9001:1994.
 Desarrolle los procedimientos para asegurarse de que los productos comprados
resuelven todos los requisitos. Estos procedimientos deben controlar la selección
de subcontratistas, el uso de datos que compran, y la verificación de productos
comprados.
ISO 9000-3.
o Los productos comprados terminados incluyen productos y servicios.
ISO 9001:1994.
 Desarrolle los procedimientos para seleccionar, para evaluar, para supervisar, y
para controlar a sus subcontratistas. Cerciórese de que los expedientes de la
calidad estén guardados. Sus expedientes deben identificar los subcontratistas
aceptables y los productos y los servicios que proporcionan.
 Desarrolle los procedimientos para asegurarse de que sus documentos de compra
describen exacto lo que usted desea comprar.
 Desarrolle los procedimientos que permiten que usted o sus clientes verifique la
aceptabilidad de productos que usted ha comprado.
ISO 9000-3: 4.7 Control de productos proporcionados por el cliente

ISO 9001:1994.
 Desarrolle los procedimientos para controlar los productos provistos a usted por los
clientes. Estos procedimientos deben asegurar que se:
o Examine el producto cuando usted la recibe para confirmar que los artículos
derechos fueron enviados sin pérdida o daño.
o Prevenga la pérdida, el uso erróneo, el daño, o la deterioración del producto
con el almacenaje y la seguridad apropiados.
o Expediente, e informe al cliente, sobre cualquier pérdida del producto, uso
erróneo, daño, o la deterioración.
o Clarifique quién es responsable del mantenimiento y del control del producto
mientras que está en su posesión.
ISO 9000-3.
o Controle los productos, los servicios, los documentos, y los datos provistos
por los clientes.
ISO 9000-3: 4.8 Identificación y trazabilidad de los productos

ISO 9001:1994.
151
 Desarrolle los procedimientos del documento para identificar y para rastrear

productos del comienzo al final. Cuando son apropiados, estos procedimientos
deben asegurarse de que usted:
o Identifique los productos y documente a cada paso la manera de la compra
de insumo y de materiales a través de todas las etapas; de la dirección, del
almacenaje, de la producción, de la entrega, de la instalación, y del
mantenimiento.
o Identifique el producto por medio de identificadores únicos y guarde el
registro conveniente.
ISO 9000-3.
o Desarrolle procedimientos para asignar identificadores únicos a sus
productos de software y componentes. Usted debería asignar identificadores
durante la fase de definición de producto y ser capaz de mantener estas
identidades a través del ciclo de vida de producto.
o Desarrolle procedimientos para rastrear sus productos de software y
componentes. Usted debería ser capaz de rastrear su software en todas
partes de su ciclo de vida.
 Use métodos de dirección de configuración para identificar y rastrear
sus productos y componentes de software.
ISO 9000-3: 4.9 Control del proceso

ISO 9001:1994.
 Desarrolle y documente procedimientos para planificar, supervisar, y controlar su
producción, instalación, y procesos de servicio.
 Diseñe un sistema de mantenimiento del registro para supervisar y controlar los
procesos, personal y el equipo. Asegúrese que todas las características importantes
de calidad en el proceso son supervisadas y registradas.
ISO 9000-3.
 Desarrolle procedimientos para controlar el proceso de réplica de software.
 Desarrolle procedimientos para controlar el proceso de liberación de software.
 Desarrolle procedimientos para controlar el proceso de instalación de software.
ISO 9000-3: 4.10 Inspección y prueba
ISO 9001:1994.
 Desarrolle procedimientos para inspeccionar, probar, y verificar que los suministros
en el proceso, y productos finales cuentan con todas las exigencias especificadas.
También asegure que la inspección de producto es apropiada y que sus registros de
prueba, son desarrollados, y que sus procedimientos aseguran que estos registros
son correctamente mantenidos.
ISO 9000-3.
 Desarrolle y documente sus planes de prueba para el software.
ISO 9001:1994.
 Desarrolle procedimientos que aseguren que los insumos no son usados antes de
que se haya verificado que cumplen con todas las exigencias especificadas.
ISO 9000-3.
o Desarrolle y documente los procedimientos para verificar los productos de
software así como los datos que son proporcionados por terceras partes y
que se vayan a construir en su producto de software. Incluya a sus clientes
y proveedores como terceras partes.
ISO 9001:1994.
 Desarrolle procedimientos que aseguren que el trabajo del proceso cubre todas las
exigencias antes de continuar con el trabajo.
 Desarrolle procedimientos que aseguren que los productos finales cubren todas las
exigencias antes de que estén disponibles para la venta.
152
ISO 9000-3.
o Realice pruebas de validación de software y pruebas de aceptación de
software.
ISO 9001:1994.
 Desarrolle un sistema de registro para que personal pueda documentar todas las
pruebas de producto y actividades de inspección.
ISO 9000-3: 4.11 Control de los equipos de inspección, medición y prueba

ISO 9001:1994.
 Desarrolle procedimientos para controlar, calibrar, y mantener la inspección, la
medición, y el equipo de prueba usado para demostrar que sus productos se
conforman para exigencias específicas (por favor note que el término “equipo” de
incluye, y hardware y el software).
ISO 9000-3.
o Use herramientas, técnicas, y el equipo para probar si sus productos de
software alcanzan las exigencias especificadas.
ISO 9001:1994.
 Desarrolle procedimientos para asegurar que su equipo de calibración es apropiado,
eficaz, y seguro.
 Desarrolle procedimientos para detectar la calidad de calibración de sus equipos de
medición, y prueba.
ISO 9000-3.
o Desarrolle procedimientos para calibrar el hardware e instrumentos usados
para probar y validar sus productos de software.
ISO 9000-3: 4.12 Estado de inspección y prueba

ISO 9001:1994.
 Desarrolle procedimientos para controlar el estado de prueba de sus productos.
Estos procedimientos deberían asegurar que:
o Cada producto es identificado como pasa o no pasa, en las pruebas
requeridas e inspecciones.
o El estado de prueba de cada producto es documentado y respetado en todas
partes de la producción, la instalación, y revisión del proceso. ·
o Sólo los productos que han pasado todas las pruebas e inspecciones son
usados o vendidos a clientes posteriormente.
ISO 9000-3.
 Desarrolle métodos de identificar y controlar el estado de prueba de
sus productos de software y componentes.
ISO 9000-3: 4.13 Control de productos no conformes

ISO 9001:1994.
 Desarrolle procedimientos para prevenir el empleo inadecuado de productos no
conformes. También asegúrese que todos son notificados cuando sus productos no
cumplen con las especificaciones.
ISO 9000-3.
o Segregue su software no conforme colocándolo en un ambiente separado.
o Controle la investigación y resolución de los defectos de software y las no
conformidades.
ISO 9001:1994.
153
 Desarrolle procedimientos para controlar como sus productos no conformes son

revisados, adaptados, clasificados de nuevo, re probados, registrados, y discutidos.
ISO 9000-3.
o Controle la disposición de productos y componentes de software no
conformes.
o Vuelva a probar los productos de software que han sido modificados.
ISO 9000-3: 4.14 Acciones correctivas y preventivas

ISO 9001:1994.
 Desarrolle procedimientos para corregir o prevenir no conformidades.
ISO 9000-3.
o Use procedimientos de gestión de configuración para controlar las acciones
correctivas y preventivas que afectan artículos de software y productos.
o Use documentos y procedimientos de control de datos para controlar las
acciones correctivas y preventivas que afectan los procesos del ciclo de
vida del software.
ISO 9001:1994.
 Desarrolle procedimientos para asegurar que las no conformidades son identificadas
y corregidas sin retraso.
 Desarrolle procedimientos para asegurar que las no conformidades potenciales son
detectadas y prevenidas rutinariamente.
ISO 9000-3.
o Desarrolle acciones preventivas, analizando las causas raíces de las no
conformidades.
o Desarrolle acciones preventivas, analizando en las métricas los niveles y
tendencias desfavorables.
ISO 9000-3: 4.15 Manipulación, almacenamiento, embalaje, conservación y entrega

ISO 9001:1994.
 Desarrolle y documente los procedimientos para manipular, almacenar, embalaje,
conservación y entrega de sus productos.
 Desarrolle métodos y procedimientos para el manejo del producto que prevengan su
daño o deterioro.
ISO 9000-3.
o Los procedimientos para el manejo de su producto deberían ayudar prevenir
el daño a sus productos de software y evitar el deterioro.
ISO 9001:1994.
 Designe áreas seguras para guardar y proteger su producto.
 Desarrolle procedimientos que especifiquen como sus productos serán colocados y
quitados del almacenaje.
 Desarrolle procedimientos que especifique como sus productos serán protegidos del
daño o la deterioración durante el almacenaje.
ISO 9000-3.
o Desarrolle procedimientos para controlar como sus productos y
componentes de software serán almacenados y protegidos.
 Guarde originales y copias de software en un ambiente seguro.
ISO 9001:1994.
 Desarrolle procedimientos que especifican como sus productos serán supervisados
y evaluados para detectar el daño o la deterioración mientras están almacenados.
 Desarrolle métodos y procedimientos de empaque, embalaje y rastreo para proteger
y controlar la calidad de productos y materiales de empaque.
154
 Desarrolle métodos y procedimientos para proteger y preservar la calidad de los

productos previos a la entrega y mientras el producto se encuentra bajo su control.
ISO 9000-3.
o Desarrolle métodos para proteger y preservar la calidad de los productos de
software previo a la entrega y mientras el producto se encuentra bajo su
control.
ISO 9001:1994.
 Desarrolle procedimientos para proteger sus productos después de las pruebas
finales, inspecciones y durante la entrega.
ISO 9000-3.
o Proteja el software durante la entrega.
 Desarrolle y documente procedimientos para preservar la integridad
del producto de software y protegerlo contra virus.
ISO 9000-3: 4.16 Control de los registros de calidad

ISO 9001:1994.
 Identifique y defina la calidad de la información que debe ser recolectada.
 Desarrolle un sistema de registro de calidad, y desarrolle procedimientos para
mantenerlo y controlarlo. Desarrolle procedimientos para:
o Colecte y registre información de calidad (genere registros).
o Archive, liste, guarde, y mantenga registros de calidad.
o Quite, archive, y destruyen registros de calidad viejos.
o Proteja los registros de calidad de accesos no autorizados.
o Impida que los registros de calidad sean cambiados sin una aprobación.
o Salvaguarde los registros del daño o deterioro.
ISO 9000-3.
 Los registros de calidad de software son documentos y archivos que demuestran
que las actividades de calidad han sido realizadas y los resultados de calidad han
sido alcanzados.
ISO 9000-3: 4.17 Auditorías de calidad internas

ISO 9001:1994.
 Desarrolle procedimientos para auditorías internas de calidad, que:
o Determinen si las actividades y resultados de calidad cumplen con los
proyectos, procedimientos, y programas de calidad.
o Evalúe el rendimiento de su sistema de calidad.
o Verifique la eficacia de sus acciones correctivas.
 Estos procedimientos también deberían asegurar que:
o Las actividades de auditoría son propiamente planificadas.
o Los auditores son independientes del personal a auditar.
o Los resultados de las auditorías, de las acciones correctivas, los resultados
de las acciones correctivas, y consecuencias son registradas correctamente.
o Las conclusiones de las auditorías son discutidas con la gente cuyas
actividades y resultados son revisados, y las deficiencias son corregidas.
o Los informes de auditoría son retroalimentados en el proceso de revisión del
sistema de calidad.
ISO 9000-3.
 Desarrolle un plan interno de auditoría o un programa para proyectos de software.
155
ISO 9000-3: 4.18 Capacitación

ISO 9001:1994.
 Desarrolle procedimientos de capacitación sobre calidad. Estos procedimientos
deben asegurar que:
o Las necesidades de capacitación de calidad son identificadas.
o El programa de calidad es proporcionado a aquellos que lo necesitan.
o El personal es capaz de ejecutar trabajos del sistema de calidad.
o El personal tiene las cualidades que necesita para desempeñar el trabajo.
o Se guardan registros de capacitación exactos y apropiados.
o Todos entienden como funciona su sistema de calidad.
ISO 9000-3.
 Identifique las necesidades de capacitación que se necesitarán para desarrollar
productos de software y para administrar proyectos de desarrollo de software.
 Identifique sus necesidades de capacitación, estudiando cómo se desarrollará
software y cómo se administrarán los proyectos.
ISO 9000-3: 4.19 Servicio post-venta

ISO 9001:1994.
 Desarrolle y documente los procedimientos de servicio. Sus procedimientos deberán
especificar como:
o Los productos deben ser entregados.
o Las actividades de servicio de los productos son reportadas.
o La calidad del servicio del producto es verificado.
ISO 9000-3.
 Desarrolle procedimientos para controlar su proceso de mantenimiento de software.
 Desarrolle planes para controlar sus proyectos de mantenimiento de software.
 Conserve un registro de sus actividades de mantenimiento.
ISO 9000-3: 4.20 Técnicas estadísticas

ISO 9001:1994.
 Seleccione técnicas estadísticas que necesitará para establecer, controlar y
verificar las capacidades de su proceso y características del producto.
 Desarrolle procedimientos para explicar como se aplicarán sus técnicas
estadísticas.
 Desarrolle procedimientos para monitorear y controlar como se usan las técnicas
estadísticas.
 Asegúrese que todos sus procedimientos estadísticos están documentados.
 Asegúrese que se mantienen propiamente los registros estadísticos.
ISO 9000-3.
 Use técnicas estadísticas para analizar los procesos de desarrollo de software.
 Use técnicas estadísticas para analizar las características de un producto de
software.
 Use técnicas estadísticas para evaluar la calidad del proceso y del producto.
5.5 Propuesta de algunos documentos requeridos por ISO

9001:2000.
La documentación dentro de ISO 9000, es de suma importancia ya que permite que el
proceso a ser certificado sea comprendido por la organización y llevado a cabo de acuerdo
156
a lo establecido para que de esta forma se asegure que como resultado tendremos un
servicio o un producto con la calidad deseada. Por lo que la norma ISO 9001:2000
establece cierta documentación a ser desarrollada que nos soporte el proceso.
Los documentos requeridos por ISO 9001:2000, son: El manual de calidad, y los siguientes
procedimientos básicos como lo son, el de Auditoría interna, Control de documentos,
Control de registros, Material no conforme, Acciones correctivas y Acciones preventivas.
Para efectos de muestra en este trabajo se elaboraron los siguientes documentos:

 Manual de calidad
 Procedimiento de auditoría interna
 Procedimiento de acciones correctivas y preventivas
A continuación se presenta una propuesta para estos tres documentos.
157
158
1.0. Alcance del Sistema de Gestión de la Calidad
El alcance del Sistema de Gestión de la Calidad de la Gerencia de informática, incluye los

procesos necesarios para la prestación del servicio de desarrollo de software que
requieren sus clientes con objeto de cumplir con sus requisitos y expectativas, soportados
por la Gerencia bajo la norma ISO 9001, entre estos procesos se encuentran los
siguientes:
1. Proceso de desarrollo de software.

2. Proceso mantenimiento de sistemas.
Siendo los procesos internos de soporte los siguientes:

3. Proceso de monitoreo de sistemas.
4. Proceso de soporte a usuarios.
Los procesos de soporte realizados por departamentos “externos” a la Gerencia son:
5. Proceso de compras.
6. Proceso de reclutamiento.
La interacción de los procesos se puede observar en la sección 9.0 se este manual:
De la misma manera el Sistema de Gestión de la Calidad aplica en las instalaciones

siguientes:
 Edificio de Madero
 Edificio de Condesa
 Edificio Principal
159
1.1 Declaración de la Política de Calidad
Nuestra directriz máxima a seguir, está constituida por la siguiente Política de Calidad:
Nuestra política de Calidad está para proporcionar una alta calidad de servicios a
nuestros clientes, de tal forma que mantengamos su lealtad. Proporcionando
servicios informáticos que satisfagan sus necesidades con recursos altamente
calificados.
Ing. .........................
Gerente de Informática
160
1.2 Objetivos de calidad
Nuestra política de calidad está sustentada por los siguientes objetivos:
 Alcanzar la certificación ISO 9001 versión 2000 durante el año 2003.
 Reducir las reclamaciones de los clientes en un 15% con respecto al año anterior
como contribución a la creación de lealtad del cliente.
 Reducir el tiempo de respuesta en un 5% con respecto al año anterior para

contribuir a crear lealtad del cliente.
 Formar un equipo de trabajo en permanente crecimiento personal y profesional,

acorde con el crecimiento de la Gerencia.
161
2.0 Normas de referencia.
Las siguientes normas se toman como referencia para el Sistema de Gestión de la Calidad:
ISO 9000:2000 Sistema de gestión de la calidad. Fundamentos y vocabulario.
ISO 9001:2000 Sistema de gestión de la calidad. Requisitos.
ISO 9004:2000 Sistema de gestión de la calidad. Directrices para la mejora continua

del desempeño.
3.0 Definiciones
3.1 Definiciones generales del sistema de gestión de calidad
Este documento utiliza las definiciones del vocabulario incluido en la norma ISO 9000:2000
y las propias de la Gerencia, las cuales se describen a continuación.
Acción correctiva:
Acción tomada para eliminar la causa de una no conformidad detectada u otra situación
indeseable.
Acción preventiva:
Acción tomada para eliminar la causa de una no conformidad potencial u otra situación
potencialmente indeseable.
Ambiente de trabajo:
Conjunto de condiciones bajo las cuales se realiza el trabajo.
Auditoria:
Proceso sistemático, independiente y documentado para obtener evidencias de la auditoria
y evaluarla de manera objetiva con el fin de determinar la extensión en que se cumplen los
criterios de auditoria.
Backlog:
Órdenes de servicio pendientes de ser completadas.
Calidad:
Grado en el que un conjunto de características inherentes cumple con los requisitos.
Cliente:
Gerencia o persona que recibe un servicio o servicio.
Documento:
Información (datos que poseen significado) y su medio de soporte
Eficacia:
Extensión en la que se realizan las actividades planeadas y se alcanzan los resultados
planeados.
Eficiencia:
Relación entre el resultado alcanzado y los recursos utilizados.
162
Estructura de la Gerencia:
Disposición de responsabilidades, autoridades y relaciones entre el personal.
Evidencia objetiva:
Datos que respaldan la existencia o veracidad de algo.
Gestión de la calidad:
Actividades coordinadas para dirigir y controlar una Gerencia en lo relativo a la calidad.
Hallazgos de la auditoria:
Resultados de la evaluación de la evidencia de la auditoria recopilada frente a los criterios
de auditoria.
Instrumento:
Instrumento o equipo de prueba o medición para el que el cliente solicita su reparación o
calibración.
Infraestructura:
Sistema de instalaciones, equipo y servicios necesarios para el funcionamiento de una
Gerencia.
Manual de calidad:
Documento que especifica el sistema de gestión de la calidad de una Gerencia.
Matriz de documentos:
Documento que describe como a través de los documentos del Sistema de Gestión de la
Calidad se cumple con los requisitos de la norma ISO 9001:2000.
Mejora continua:
Actividad recurrente para aumentar la capacidad para cumplir los requisitos.
No conformidad:
Incumplimiento de un requisito.
Objetivo de calidad:
Algo ambicionado, o pretendido, relacionado con la calidad.
Plan de calidad:
Documento que especifica qué procedimientos y recursos asociados deben aplicarse, quién
debe aplicarlos y cuando deben aplicarse a un proyecto, proceso, servicio o contrato
específico.
Planeación de la calidad:
Parte de la gestión de la Calidad enfocada al establecimiento de los objetivos de la calidad
y a la especificación de los procesos operativos necesarios y de los recursos relacionados
para cumplir los objetivos de Calidad.
Política de calidad:
Intenciones globales y orientación de una Gerencia relativas a la calidad tal como se
expresan formalmente por la alta dirección.
Procedimiento:
Forma especifica para llevar a cabo una actividad o un proceso.
Proceso:
163
Conjunto de actividades mutuamente desarrolladas o que interactúan, las cuales

transforman elementos de entrada en resultados.
Proceso de medición:
Conjunto de operaciones que permiten determinar el valor de una magnitud.
Servicio o servicio:
Resultado de un proceso.
Proveedor:
Gerencia o persona que proporciona un servicio.
Registro:
Documento que presenta resultados obtenidos o proporciona evidencia de actividades
desempeñadas.
Requisito:
Necesidad o expectativa establecida, generalmente implícita u obligatoria.
Satisfacción del cliente:

Percepción del cliente sobre el grado en que se han cumplido sus requisitos.
Sistema de gestión de la calidad:

Sistema de gestión para dirigir y controlar una Gerencia con respecto a la calidad.
Trazabilidad:
Capacidad para seguir la historia, la aplicación o la localización de todo aquello que está
bajo consideración.
164
4.0 Sistema de gestión de la calidad
4.1 Requisitos generales
La Gerencia tiene un sistema de gestión de la calidad establecido, documentado

implantado y mantenido, cuya eficacia se mejora continuamente de acuerdo con los
requisitos de la norma ISO9001:2000.
La Gerencia:
a) tiene identificados los procesos necesarios para el sistema de gestión de la calidad

y su aplicación a través de la Gerencia, se incluyen los procesos para las
actividades de la realización del servicio de reparación y calibración de
instrumentos electrónicos, y procesos de soporte internos y externos (ver sección
1.0);
b) tiene identificada la interacción de estos procesos;
c) tiene definidos los métodos y criterios necesarios para asegurar que tanto la
operación como el control de estos procesos sean eficaces;
d) asegura la disponibilidad de recursos e información necesarios para apoyar la
operación y el control de los procesos;
e) realiza el monitoreo y la medición de estos procesos; e
f) implanta las acciones necesarias para alcanzar los resultados planeados y la mejora
continua de los procesos (ver sección 9.0). Se registran los resultados de las
acciones tomadas.
La Gerencia gestiona sus procesos de acuerdo con los requisitos de la norma

ISO9001:2000. En caso de contratar cualquier proceso que afecte la conformidad del
servicio con los requisitos, la Gerencia asegura el control de tales procesos.
165
4.2 Requisitos de la documentación
4.2.1 Generalidades
El sistema de calidad de la Gerencia se compone de varios niveles de documentación que

incluyen política y objetivos de la calidad, información sobre los muchos procesos utilizados
en y las instrucciones de trabajo clave necesarias para completar las tareas asignadas. La
combinación agregada de la documentación de calidad, política, responsabilidades,
procesos, instrucciones del trabajo, manuales técnicos, y procedimientos, componen
nuestra documentación del sistema de calidad que se encuentra en forma impresa y en la
página Web.
La documentación del sistema de gestión de la calidad incluye:
a) declaraciones documentadas de la política de calidad y de los objetivos de calidad

(ver sección 1.1 y 1.2);
b) un Manual de Calidad;
c) los procedimientos documentados requeridos en la norma ISO9001:2000 (Control de
documentos, Control de registros, Auditorias internas, Control de servicio no
conforme, Acciones correctivas y preventivas);
d) los documentos necesitados por la Gerencia para asegurar una planeación,
operación y control de procesos eficaz; tales como: procedimientos e instructivos
para las diversas operaciones para proporcionar el servicio de reparación y
calibración de instrumentos, manuales de instrumentos, software de calibración y
control, y;
e) los registros requeridos por la norma ISO9001:2000 (ver sección 4.2.4). Los
registros incluidos son sin ser limitativos: capacidades laborales de los empleados,
evidencias de conformancia del servicio proporcionado, revisión de los requisitos
del cliente y acciones tomadas, cambios realizados por la Gerencia para
proporcionar el servicio, daño o pérdida de instrumentos de clientes, resultados de
calibración y verificación, registros de reparación, retroalimentación del cliente,
satisfacción del cliente, auditorias internas, liberación del servicio, acciones
correctivas, acciones preventivas, calibración de instrumentos y patrones utilizados
para proporcionar el servicio.
166
La extensión de la documentación del Sistema de Gestión de la Calidad en cuanto a su

alcance y detalle, considera: el tamaño de la Gerencia; la complejidad de las
operaciones de prestación de servicios; y la competencia de nuestro personal.
f) A continuación se muestra la estructura de la documentación del sistema de calidad:
Requerimientos de clientes
Nivel 0 y normas ISO9001:2000
Manual
Nivel 1 de
calidad
Procedimientos
Nivel 2 del sistema de
calidad y de operación.
Manuales de instrumentos
Nivel 3 Instructivos de operación
Nivel 4 Registros de calidad
4.2.2 Manual de calidad
La Gerencia tiene establecido y mantiene un manual de calidad que incluye:

a) el alcance del sistema de gestión de la calidad (ver sección 1.0);
b) los detalles y la justificación de cualquier exclusión permitida por la norma ISO
9001:2000 (ver sección 7.3);
c) la referencia a los procedimientos documentados establecidos para el sistema de
gestión de la calidad;
d) y una descripción de la interacción entre los procesos del sistema de gestión de la
calidad (ver sección 9.0).
4.2.2.1 Procedimientos del sistema de calidad y de operación

Son los procedimientos documentados establecidos para soportar el sistema de gestión
de la calidad y la operación y la documentación necesaria para proporcionar el servicio
como los manuales de los instrumentos que se encuentran impresos o en la página Web.
4.2.2.2 Instructivos de operación

Son los instructivos necesarios para soportar los procedimientos del sistema de calidad,
que incluyen los procedimientos e instrucciones detalladas para realizar las tareas .
4.2.3 Control de los documentos
Todos los documentos requeridos por el sistema de gestión de la calidad están controlados.
Los registros como tipo especial de documento se controlan de acuerdo con los requisitos
citados en 4.2.4.
167
Se tiene establecido el procedimiento XXX1 de Control de Documentos que define los

controles necesarios para:
a) aprobar los documentos en cuanto a su adecuación antes de su emisión;

b) revisar y actualizar los documentos cuando sea necesario y aprobarlos nuevamente;
c) asegurar que se identifiquen los cambios y el estado de revisión actual de los
documentos;
d) asegurar que las versiones pertinentes de los documentos aplicables se encuentran
disponibles en los puntos de uso;
e) asegurar que los documentos permanecen legibles y fácilmente identificables;
f) asegurar que se identifican los documentos de origen externo y se controle su
distribución; y
g) prevenir el uso no intencionado de documentos obsoletos, y aplicarles una
identificación adecuada en el caso de que se mantengan por cualquier razón.
4.2.4 Control de los registros
Se tienen registros establecidos y se mantienen para proporcionar evidencia de la

conformidad con los requisitos de la norma ISO 9001:2000 así como de la operación eficaz
del sistema de gestión de la calidad. Los registros permanecen legibles, fácilmente
identificables y recuperables. Se tiene establecido el procedimiento XXX2 de Control de
Registros para definir los controles necesarios para la identificación, el almacenamiento, la
preservación, la recuperación, el tiempo de retención y la disposición de los registros.
168
5.0 Responsabilidad de la dirección
5.1 Compromiso de la dirección
El Gerente de informática mantiene evidencia de su compromiso con el desarrollo e

implantación del sistema de gestión de la calidad, así como con la mejora continua de su
eficacia como sigue:
a) establece objetivos estratégicos y políticas en el marco de una planeación anual;

b) asegura la disponibilidad de recursos y estructura necesarios;
c) comunica al personal de la Gerencia de la importancia de satisfacer tanto los
requisitos del cliente como los legales y reglamentarios;
d) tiene establecida una política de calidad;
e) establece objetivos de calidad;
f) y realiza revisiones gerenciales del desempeño del sistema de calidad al menos una
vez al año, incluyendo la revisión de la adecuación de la política de calidad.
5.2 Enfoque al cliente
El Gerente de informática asegura que se identifiquen las necesidades y expectativas del

cliente, se transformen en requisitos y se cumplan con el propósito de lograr la satisfacción
del cliente y su mejora.
Entre las expectativas y necesidades del cliente, se incluyen las siguientes: conformidad
del servicio bajo especificaciones incluidas en el reporte, disponibilidad en atención,
garantía y precio adecuado.
5.3 Política de calidad
La política de calidad establecida por el Gerente de la Gerencia asegura que (ver sección
1.1):
a) es adecuada al propósito de la Gerencia;

b) incluye el compromiso de cumplir con los requisitos del cliente y de mejorar
continuamente la eficacia del sistema de gestión de la calidad;
c) proporciona un marco de referencia para establecer y revisar los objetivos de
calidad;
d) es comunicada y entendida dentro de la Gerencia;
e) es revisada al menos una vez al año para su continua adecuación.
5.4 Objetivos de calidad
El Gerente de informática, asegura que los objetivos de calidad, incluyendo aquellos

necesarios para cumplir con los requisitos del servicio, se establecen en las funciones y
niveles pertinentes dentro de la Gerencia. Los objetivos de la calidad son medibles y
coherentes con la política de calidad (ver sección 1.2).
5.4.2 Planeación del sistema de gestión de la calidad
El Gerente de informática asegura que:
169
a) al menos una vez al año se realiza la Planeación del sistema de gestión de la calidad
con el fin de cumplir los requisitos citados en 4.1, así como los objetivos de calidad;
y
b) se mantiene la integridad del sistema de gestión de la calidad cuando se planean e
implantan cambios a éste.
Como entradas para la Planeación de la calidad se pueden incluir algunas de las siguientes:
a) las necesidades y expectativas de los clientes establecidas en los contratos o

pedidos de servicio;
b) el desempeño de los servicios identificadas con encuestas, quejas e
incumplimientos;
c) el desempeño de los procesos del sistema de calidad indicada en el Backlog;
d) las lecciones aprendidas de experiencias previas;
e) las oportunidades de mejora; y
f) los riesgos probables.
En la Planeación se pueden incluir:
a) los procesos del sistema de gestión de la calidad, considerando las exclusiones

permitidas;
b) los recursos necesarios;
c) la mejora continua del sistema de gestión de la calidad;
Cómo salidas de la Planeación de la calidad se pueden identificar entre otros:
a) la responsabilidad y autoridad para la ejecución de los planes de mejora;

b) las habilidades y conocimientos necesarios;
c) los enfoques, la metodología y las herramientas para la mejora;
d) los recursos necesarios;
e) los indicadores necesarios;
f) la necesidad de documentación y registros.
El Gerente de la Gerencia asegura que las responsabilidades y autoridades estén definidas

y se comuniquen dentro de esta Gerencia (ver sección 0.5).
5.5.2 Representante de Calidad de la dirección
El Gerente de informática designa al representante de la dirección, quién con independencia

de otras responsabilidades, tiene la autoridad y responsabilidad para:
a) asegurar que se implanten y mantengan los procesos necesarios para el sistema de

gestión de la calidad;
b) informar al Gerente de la Gerencia sobre el desempeño del sistema de gestión de la
calidad y de cualquier necesidad de mejora resultado de auditorias y acciones
correctivas y preventivas; y
c) asegurar que se promueva la toma de conciencia de los requisitos del cliente en
todos los niveles de la Gerencia.
170
El Gerente de informática asegura que haya una comunicación adecuada entre los
diferentes niveles y funciones sobre los procesos del sistema de gestión de la calidad y su
eficacia. Se usa el correo electrónico para tal efecto.
5.6 Revisión por la dirección
5.6.1 Generalidades
El Gerente de informática revisa al menos una vez al año, el sistema de gestión de la

calidad de La Gerencia, para asegurarse de su conveniencia, adecuación y eficacia
continuas. La revisión incluye la evaluación de las oportunidades de mejora y la necesidad
de efectuar cambios en el sistema de gestión de la calidad, incluyendo la política de
calidad y los objetivos de calidad.
Se mantienen registros de las revisiones por la dirección (ver sección 4.2.4).
5.6.2 Información para la revisión
La información de entrada para revisión por la dirección puede incluye:
a) resultados de auditorias realizadas internamente y por organismos externos;

b) retroalimentación del cliente incluyendo encuestas y las reclamaciones;
c) desempeño de los procesos y conformidad del servicio incluyendo idoneidad de
políticas y procedimientos;
d) estado de las acciones correctivas y preventivas;
e) acciones de seguimiento de revisiones por la gerencia previas;
f) cambios que podrían afectar al sistema de gestión de la calidad como el cambio en
volumen o tipo de trabajo;
g) recomendaciones para la mejora e información de otros factores relevantes.
5.6.3 Resultados de la revisión
Los resultados de la revisión por la dirección incluyen todas las decisiones y acciones
relacionadas con:
a) La mejora de la eficacia del sistema de gestión de la calidad y sus procesos;

b) la mejora del servicio en relación con los requisitos del cliente; y
c) las necesidades de recursos.
Los resultados y las acciones correspondientes con fechas sin determinar son recopiladas
en las actas de las reuniones de revisión por la Gerencia.
171
6.0 Gestión de los recursos
6.1 Provisión de recursos
El Gerente de informática determina y proporciona los recursos necesarios para:
a) implantar y mantener el sistema de gestión de la calidad y mejorar continuamente

su eficacia; y
b) aumentar la satisfacción del cliente mediante el cumplimiento de sus requisitos.
Entre los recursos se incluyen algunos de los siguientes de acuerdo al caso específico, sin
ser limitativos:
a) recursos tangibles como las instalaciones para la realización del servicio y soporte.;
b) recursos y mecanismos para alentar la mejora continua innovadora;
c) estructura organizacional;
d) incremento de la competencia a través de la capacitación, educación y aprendizaje;
e) planeación de los recursos futuros.
6.2 Recursos Humanos
6.2.1 Generalidades
El personal que realiza trabajos que afectan a la calidad del servicio es competente en
relación con los requerimientos de su educación, formación, habilidades y experiencia
apropiadas. Se promueve la participación del personal a través de algunos de los aspectos
siguientes, sin ser limitativo:
a) identificación de necesidades de competencia para cada actividad del proceso que

afecte la calidad;
b) capacitación periódica de acuerdo a las requerimientos del proceso;
c) definición de responsabilidades y autoridades;
d) establecimiento de objetivos individuales y de equipo, gestionado su operación y
evaluando los resultados;
e) la revisión abierta continua de las necesidades del personal;
f) la creación de condiciones que promuevan la innovación;
g) el uso de mediciones de la satisfacción del personal para su mejoramiento;
h) realizar actividades de verificación para asegurar que se mantiene la competencia
ante requerimientos cambiantes del puesto.
6.2.2 Competencia, toma de conciencia y formación
La Gerencia realiza lo siguiente:
a) determina la competencia necesaria para el personal que realiza trabajos que

afectan a la calidad del servicio;
b) proporciona formación o toma otras acciones para satisfacer dichas necesidades;
c) evalúa la eficacia de las acciones tomadas;
d) se asegura de que el personal es consciente de la pertinencia e importancia de sus
actividades y de cómo contribuyen al logro de los objetivos de la calidad, generando
evidencia de que esta actividad se cumple; y
e) mantiene los registros apropiados de la educación, formación, habilidades y
experiencia (ver sección. 4.2.4)
172
6.3 Infraestructura
La Gerencia determina, proporciona y mantiene la infraestructura necesaria para lograr la

conformidad con los requisitos del servicio. La infraestructura incluye:
a) edificios, espacio de trabajo y servicios asociados;

b) equipo para los procesos (software y hardware);
c) servicios de soporte;
d) los presupuestos de operación donde se incluye la adquisición de los recursos y su
seguimiento.
6.4 Ambiente de trabajo
La Gerencia determina y gestiona el ambiente de trabajo necesario para lograr

conformidad con los requisitos, considerando algunos de los siguientes factores humanos y
físicos:
a) métodos de trabajo creativos para la realización del potencial del personal;

b) guías y reglas se seguridad, incluyendo el uso de equipo de seguridad;
c) ergonomía;
d) lugar de trabajo ordenado y delimitado;
e) lugares para guardar documentos, accesorios e instrumentos;
f) interacción social;
g) facilidades para el personal en la Gerencia;
h) calor, humedad, luz, ventilación, e
i) higiene, limpieza ruido, vibración y contaminación.
173
7.0 Realización del servicio
7.1 Planeación de la realización del servicio
El Gerente de informática planea en forma coherente con los otros procesos del sistema
del sistema de gestión de la calidad y desarrolla los procesos necesarios para la
realización del servicio.
Durante la Planeación de la realización del servicio, la Gerencia determina cuando se

apropiado, lo siguiente:
a) los objetivos de calidad y los requisitos del servicio;

b) la necesidad de establecer procesos, documentos y de proporcionar recursos
específicos para el servicio;
c) las actividades requeridas de verificación, validación, monitoreo, inspección y
ensayo / prueba específicas para el servicio así como los criterios para la
aceptación del mismo; y
d) los registros que sean necesarios para proporcionar evidencia de que los procesos
de realización y el servicio resultante cumplen los requisitos (ver sección 4.2.4),
El resultado de esta Planeación se presenta en forma adecuada para la metodología de

operación de la Gerencia como sigue:
a) se tienen procedimientos que definen objetivos y requerimientos del servicio

preparados para cada tipo de servicio, considerando la retroalimentación del cliente
como parte del plan;
b) se cuenta con procedimientos para la verificación del servicio, su validación,
monitoreo inspección y prueba;
c) en los procedimientos se han identificado los registros necesarios para asegurar
que el servicio cumple con los criterios establecidos para el servicio y su proceso.
7.2.1 Determinación de los requerimientos relacionados con el servicio
La Gerencia determina lo siguiente:
a) los requisitos especificados por el cliente, incluyendo los requisitos para las
actividades de entrega y las posteriores a la misma;
b) los requisitos no establecidos por el cliente pero necesarios para el uso
especificado o para el uso previsto, cuando sea conocido;
c) los requisitos legales y reglamentarios relacionados con el servicio; y
d) cualquier requisito adicional determinado por la Gerencia.
7.2.2 Revisión de los requisitos relacionados con el servicio
La Gerencia revisa los requisitos relacionados con el servicio antes de comprometerse a

proporcionar un servicio al cliente ( por ejemplo, la aceptación de contratos o pedidos y
aceptación de cambios en los contratos) y se asegura que:
a) están definidos los requisitos del servicio;

b) están resueltas las diferencias existentes entre los requisitos del contrato o pedido
y los expresados previamente; y
174
c) que la Gerencia tiene la capacidad de cumplir con los requisitos definidos de ser
necesario apoyándose en la contratación de servicios externos.
Se mantienen registros de los resultados de la revisión de contratos o pedidos y de las

acciones originadas por la misma (ver sección 4.2.4).
Cuando el cliente no proporcione una declaración documentada de los requisitos, la

Gerencia confirma los requisitos del cliente antes de su aceptación.
Cuando se cambien los requisitos del servicio, la Gerencia correspondiente sea consciente
de los requisitos modificados.
La Gerencia determina e implanta disposiciones eficaces para la comunicación con los

clientes, relativas a:
a) la información sobre el servicio;

b) las consultas, contratos o pedidos, incluyendo las modificaciones a los mismos,
c) la retroalimentación del cliente, incluyendo sus quejas, de lo cual se mantienen
registros y acciones correctivas y preventivas si fueron establecidas.
7.3.1 Planificación del diseño y desarrollo
La Gerencia determina lo siguiente:
a) las etapas del diseño y desarrollo,

b) la revisión, verificación y validación apropiadas para cada etapa del diseño y
desarrollo y,
c) las responsabilidades y autoridades para el diseño y desarrollo.
7.3.7 Control de cambios de diseño
La Gerencia identifica los cambios en el diseño realizados y mantiene registros de los

mismos como sigue:
a) los cambios al servicio se identifican, documentan y revisan antes de su

implantación;
b) en la revisión se considera el efecto de los cambios en los clientes o que ya se han
liberado a estos;
c) se mantienen los registros de lo cambios.
7.4 Compras
7.4.1 Proceso de compras
La Gerencia se asegura de que el producto o servicio adquirido cumple con los requisitos
de compra especificados, con un tipo y amplitud de control dependiente de su impacto en la
calidad de la posterior realización del servicio final al cliente.
175
a) Las requisiciones y órdenes de compra describen claramente el producto para

asegurar que el producto comprado este conforme a los requerimientos de compra
especificados.
b) La valoración del proveedor, cuando se requiera, se hará mediante la ayuda del
personal de calidad de la Gerencia.
7.4.2 Información de las compras
La Gerencia se asegura de que las órdenes de compra de productos que influyan en la

calidad del servicio al cliente, sean revisadas y aprobadas por personal responsable para
asegurar que los requerimientos especificados de compra sean adecuados, antes de emitir
el pedido al proveedor.
La información de las compras describe el producto a comprar, incluyendo, cuando sea

apropiado:
a) requisitos para la aprobación del producto, procedimientos, procesos y equipos;

b) requisitos para la calificación del personal;
c) requisitos del sistema de gestión de la calidad.
Se mantienen registros de las órdenes de compra y de sus requerimientos.
7.4.3 Verificación de los servicios comprados
La Gerencia asegura que el producto o servicio comprado cumple con los requisitos de
compra especificados.
a) Se mantienen registros de la verificación y/o inspección de los productos

comprados.
b) En caso necesario se establecen en las órdenes de compra los métodos de
verificación y de liberación del producto.
En caso de que la Gerencia o su cliente quieran llevar a cabo la verificación en las

instalaciones del proveedor, se establecerá en la información de compra las disposiciones
para la verificación pretendida y el método para la liberación del producto.
7.5 Producción y prestación del servicio
La Gerencia planea y lleva a cabo la producción y la prestación del servicio bajo

condiciones controladas. Las condiciones controladas incluyen cuando sea aplicable:
a) la disponibilidad de información en el punto apropiado que describa las

características del servicio, incluyendo los resultados esperados de prueba y
operacionales;
b) la disponibilidad de instrucciones de trabajo en el punto apropiado, cuando sea
necesario;
c) la disponibilidad y uso de dispositivos de monitoreo y medición;
d) la implantación del monitoreo y medición; y
e) la implantación de actividades de liberación, entrega y posteriores a la entrega.
7.5.2 Validación de los procesos de la producción y de la prestación del servicio
176
La Gerencia valida aquellos procesos de producción y prestación de servicio donde los

servicios resultantes no puedan verificarse mediante actividades de monitoreo o medición
posteriores. Esto incluye a cualquier proceso en el que las deficiencias se hagan aparentes
únicamente después de que le servicio esté siendo utilizado o se haya prestado el servicio.
La validación demuestra la capacidad de estos procesos para alcanzar los resultados

planeados.
La Gerencia establece para estos procesos, incluyendo cuando sea aplicable:
a) los criterios para la revisión y aprobación de los procesos;

b) el uso de métodos y procedimientos específicos;
c) los requisitos de los registros (ver sección 4.2.4); y
d) los requerimientos de los procesos, su definición, aprobación y re – revalidación
periódica.
7.5.3 Identificación y trazabilidad
La Gerencia cuando sea apropiado:
a) Identifica al servicio por medios adecuados, a través de toda su realización, en los

puntos identificados del proceso donde se requiera identificación y rastreabilidad
del servicio.
b) Identifica el estado del servicio con respecto a los requisitos de monitoreo y
medición.
c) Cuando la trazabilidad sea un requisito, controla y mantiene registros de la
identificación única del servicio (ver sección 4.2.4).
7.5.4 Propiedad del cliente
La Gerencia cuida los bienes que son propiedad del cliente mientras estén bajo su control o
estén siendo utilizados por la misma:
a) Identifica, verifica, protege y salvaguarda de pérdida los bienes que son propiedad
del cliente suministrados para su utilización o incorporación dentro del servicio.
b) Cualquier bien que sea propiedad del cliente que se pierda, deteriore o que de algún
modo se considere inadecuado para su uso debe ser registrado (ver sección 4.2.4) y
reportado al cliente.
7.5.5. Preservación del producto
La Gerencia preserva la conformidad del servicio a los instrumentos del cliente durante
todo el proceso interno hasta la entrega al destino previsto. La preservación incluye:
a) La identificación, manejo, embalaje, almacenamiento y protección.

b) La preservación se aplica también a las partes constitutivas del producto.
7.6 Control de los dispositivos de monitoreo y medición
La Gerencia determina el monitoreo y la medición a realizar y los dispositivos de medición

y monitoreo necesarios para proporcionar la evidencia de la conformidad del servicio con
los requisitos determinados (ver sección 7.2.1).
177
La Gerencia tiene un procedimiento de estándares para asegurar que el monitoreo y

medición puede y sea realizados de una manera coherente con los requisitos de monitoreo
y medición.
Cuando sea necesario asegurarse de la validez de los resultados el instrumento y/o patrón
de medición se:
a) calibra o verifica a intervalos especificados o antes de su utilización, comparado con

patrones de medición trazables a patrones de medición nacionales o internacionales;
cuando no existan tales patrones se registra la base para la calibración o la
verificación;
b) ajusta o reajusta según sea necesario;
c) identifica para poder determinar el estado de la calibración;
d) protege contra ajustes que pudieran invalidar el resultado de la medición; y
e) protege contra los daños y el deterioro durante la manipulación, el mantenimiento y
el almacenamiento.
La Gerencia cuando detecta que el equipo no está conforme con los requisitos, hace lo
siguiente:
a) evalúa y registra la validez de los resultados de las mediciones anteriores a la

detección;
b) se toman acciones apropiadas sobre los instrumentos y cualquier servicio afectado;
c) se verifica el mantenimiento de los registros de los resultados de la calibración y de
la verificación;
d) y se inician y toman acciones correctivas para las no conformidades encontradas
durante la prueba y calibración.
Se confirma la capacidad de los programas informáticos para satisfacer su aplicación

prevista cuando éstos se utilicen en las actividades de monitoreo y medición de los
requisitos especificados. Esto se realiza antes de iniciar su utilización y se confirma de
nuevo cuando sea necesario.
178
8.0 Medición, análisis y mejora
8.1 Generalidades
La Gerencia planea e implanta los procesos de monitoreo, medición, análisis y mejora

necesarios para:
a) demostrar la conformidad del servicio

b) asegurarse de la gestión del sistema de gestión de la calidad; y
c) mejorar continuamente la eficacia del sistema de gestión de la calidad.
Esto comprende la determinación de los métodos aplicables, incluyendo las técnicas

estadísticas, y el alcance de su utilización.
Para lograr lo anterior, la Gerencia realiza lo siguiente:
a) planea e implanta actividades específicas para asegurar que el servicio cumpla con
los requerimientos;
b) monitorea la efectividad del sistema de calidad con objeto de establecer una mejora
continua; y
c) aplica donde sea apropiado, las técnicas estadísticas para verificar la capacidad del
servicio en las características importantes definidas previamente.
8.2 Monitoreo y medición
8.2.1. Satisfacción del cliente
La Gerencia como una medida del desempeño del sistema de gestión de la calidad, realiza
el monitoreo de la información relativa a la percepción del cliente con respecto al
cumplimiento de sus requisitos por parte de la Gerencia. Se tiene el procedimiento XXX3
para la obtención, proceso y utilización de esa información.
Los clientes son notificados oportunamente de los retrasos en los plazos originalmente
fijados para la realización del servicio. La información de nuestros clientes se obtiene a
través de varios métodos, tales como encuestas por carta, encuestas aleatorias por
teléfono, etc.
8.2.2 Auditoria interna
La Gerencia lleva a cabo a intervalos planeados auditorias internas para determinar si el

sistema de gestión de la calidad:
a) es conforme con las disposiciones planeadas (ver sección 7.1), con los requisitos de
la norma ISO9001:2000 y con los requisitos del Sistema de Calidad establecido por
la corporación; y
b) se ha implantado y se mantiene de manera eficaz.
Se cuenta con un programa anual de auditorias tomando en consideración el estado y la

importancia de los procesos y las áreas a auditar, así como los resultados de las auditorias
previas. Se tienen definidos los criterios de auditoria, el alcance de la misma, su frecuencia
y metodología, la selección de auditores y la realización de auditorias asegura la objetividad
e imparcialidad del proceso de auditoria. Los auditores no auditan su propio trabajo.
179
Se han definido en el procedimiento 0004, las responsabilidades y requisitos para la

planeación y la realización de auditorias, para informar de los resultados y para mantener
los registros (ver sección 4.2.4).
El responsable del área que esté siendo auditada se asegura que se toman las acciones sin
demora injustificada para eliminar las no conformidades detectadas y sus causas. Las
actividades de seguimiento incluyen la verificación de las acciones tomadas y el informe de
los resultados de la verificación (ver sección 8.2.5).
8.2.3 Monitoreo y medición de los procesos
La Gerencia aplica métodos apropiados para el monitoreo, y cuando sea aplicable la

medición de los procesos del sistema de gestión de la calidad. Estos métodos demuestran la
capacidad de los procesos para alcanzar los resultados planeados. Cuando no se alcanzan
los resultados planeados, se llevan a cabo correcciones y acciones correctivas, según sea
conveniente, para asegurarse de la conformidad del servicio.
8.2.4 Monitoreo y medición del servicio
La Gerencia monitorea y mide las características del servicio para verificar que se
cumplen los requisitos del mismo, durante las etapas apropiadas del proceso para su
realización de acuerdo con las disposiciones planeadas (ver sección 7.1).
Se mantiene evidencia de la conformidad con los criterios de aceptación. Los registros

indican a la(s) persona(s) que autoriza(n) la liberación del servicio (ver sección 4.2.4).
La liberación de los instrumentos y la prestación del servicio no se lleva a cabo haya que
se haya completado satisfactoriamente las disposiciones planeadas (ver sección 7.1), a
menos que sean aprobados de otra manera por una autoridad pertinente y, cuando cuándo
sea aplicable, por el cliente.
8.3 Producto no conforme
La Gerencia se asegura que el producto que no sea conforme con los requisitos, sea
identificado y controlado para prevenir su uso o entrega no intencional. Los controles, las
responsabilidades y autoridades relacionadas con el tratamiento del producto no conforme
están definidas en el procedimiento XXX5.
La Gerencia trata los servicios de calibración no conformes mediante una o más de las
siguientes maneras:
a) tomando acciones para eliminar la no conformidad detectada;

b) autorizando su uso, liberación o aceptación bajo concesión por una autoridad
pertinente y cuando sea aplicable, por el cliente; y
c) tomando acciones para impedir su uso o aplicación originalmente previsto.
Se mantienen registros (ver sección 4.2.4) de la naturaleza de las no conformidades y de

cualquier acción tomada posteriormente, incluyendo las concesiones que se hayan obtenido.
Cuando se corrige el servicio de calibración no conforme se somete a una nueva

verificación para demostrar su conformidad con los requisitos.
Cuando se detecta un servicio de calibración no conforme después de la entrega o cuando

ha comenzado su uso, la Gerencia toma acciones apropiadas respecto a los efectos, o
efectos potenciales de la no conformidad.
180
8.4 Análisis de datos
La Gerencia determina, recopila y analiza los datos apropiados para demostrar la idoneidad
y la eficacia del sistema de gestión de la calidad y para evaluar dónde puede realizarse la
mejora continua de la eficacia del sistema de gestión de la calidad. Esto incluye los datos
generados del resultado del monitoreo y medición y de cualesquiera otras fuentes
pertinentes.
El análisis de datos proporciona información sobre:
a) la satisfacción del cliente (ver sección 8.2.1) para identificar oportunidades de

mejora;
b) la conformidad con los requisitos del servicio (ver sección 7.2.1) para identificar
oportunidades de mejora;
c) las características y tendencias de los procesos y de los servicios, incluyendo las
oportunidades para llevar a cabo acciones preventivas; y
d) los proveedores, como base para evaluar su desempeño.
8.5 Mejora
8.5.1 Mejora continua
La Gerencia mejora continuamente la eficacia del sistema de gestión de la calidad

mediante el uso de:
a) la política de calidad;
b) los objetivos de calidad;
c) los resultados de las auditorias;
d) el análisis de datos;
e) las acciones correctivas y preventivas;
f) y la revisión por la gerencia.
La Gerencia toma acciones para identificar y eliminar la causa de no conformidades con

objeto de prevenir que vuelva a ocurrir. Las acciones correctivas deben ser apropiadas a
los efectos de las no conformidades encontradas.
Se tiene establecido el procedimiento 0006 donde se establecen los requisitos para:
a) revisar las no conformidades (incluyendo las quejas de los clientes);

b) determinar las causas de las no conformidades;
c) evaluar la necesidad de adoptar acciones para asegurarse de que las no
conformidades no vuelvan a ocurrir;
d) determinar e implantar las acciones necesarias, verificando su implantación
efectiva;
e) registrar los resultados de las acciones tomadas (ver sección 4.2.4); y
f) revisar las acciones correctivas tomadas, verificando su efectividad.
181
La Gerencia determina acciones para eliminar las causas de no conformidades potenciales

para prevenir su ocurrencia. Las acciones preventivas deben ser apropiadas a los efectos
de los problemas potenciales.
Se tiene establecido el procedimiento XXX7 donde se establecen los requisitos para:
a) determinar las no conformidades potenciales y sus causas;

b) evaluar la necesidad de actuar para prevenir la ocurrencia de no conformidades;
c) determinar e implantar las acciones necesarias;
d) registrar los resultados de las acciones tomadas (ver sección 4.2.4); y
e) revisar las acciones preventivas tomadas verificando su efectividad.
9.0 Procesos de la Gerencia y sus interrelaciones
Diagramas de flujo de los procesos

Descripción general de las funciones de cada proceso
Nombre del Responsable Propósito general:

proceso:
Proceso de Subgerencia de Proceso clave, para el desarrollo de sistemas
desarrollo de Desarrollo de informáticos que requieren los clientes de la
software Infraestructura Gerencia.
Informática
Proceso de Subgerencia de Proceso clave para el buen funcionamiento de los
mantenimiento Desarrollo de sistemas desarrollados en la Gerencia.
de sistemas Infraestructura
Informática
Proceso de Subgerencia de Proceso de soporte a los procesos claves, cuya
monitoreo de Informática de Atención a finalidad es vigilar el buen funcionamiento de los
sistemas Usuarios sistemas a cargo de la Gerencia de informática.
Proceso de Subgerencia de Proceso de soporte a los procesos claves, cuya
soporte a Informática de Atención a finalidad es proporcionar la asistencia que requieran
usuarios Usuarios nuestros clientes para el buen aprovechamiento de
los sistemas.
Proceso de Gerencia de informática- Proceso de soporte a los procesos claves; el cual se
compras Área de compras del lleva a cabo en coordinación con el área de compras
Banco de México del Banco, ya que por su naturaleza, las compras se
llevan a cabo por licitación y cuya finalidad es
proveer los recursos que se requieran en la Gerencia
para el desarrollo de sistemas.
Proceso de Gerencia de informática- Proceso de soporte a los procesos claves; el cual se
reclutamiento Área de reclutamiento y lleva a cabo en coordinación con el área de
selección del Banco de reclutamiento y selección del Banco, ya que no
México importa que la selección se lleve de acuerdo a las
necesidades de la Gerencia, es obligatorio que los
candidatos sean aprobados en ésta área. Su finalidad
es proveer los recursos humanos que se requieran en
la Gerencia para el desarrollo de sistemas.
10.0 Matriz de procedimientos
182
Lista de todos los procedimientos utilizados por el sistema de gestión de calidad.
 Procedimiento de auditoría interna

 Procedimiento de acciones correctivas
183
0004
PROCEDIMIENTO (PROPUESTO) DE
AUDITORIAS INTERNAS DE CALIDAD
1. Propósito
Definir un sistema de auditorias internas de calidad para planear, implementar y
documentar el cumplimiento a los procedimientos y estándares de calidad, determinando la
efectividad del Sistema de Calidad.
2.0 Alcance
Este procedimiento aplica a la programación, planeación (incluyendo la selección de

auditores para auditorias internas), estándares de calidad y procesos que directamente
afectan a las partes involucradas incluyendo a la administración, generación de acciones
correctivas y preventivas y su validación.
3.0 Requerimientos
3.1 El Gerente de informática debe incluir en las Juntas Periódicas de Calidad, la

revisión de los resultados de las auditorias internas y la verificación de su
efectividad en las acciones correctivas para mejorar el desempeño del Sistema de
Calidad.
3.2 El Gerente de informática debe asegurarse que se toman acciones sin demora
injustificada para eliminar las No Conformidades y sus causas.
4.0 Responsables de la Implementación
Los responsables de la implementación son:
4.1 El representante de calidad para lo referente a emisión, control, actualización y

seguimiento de los planes y calendarios de auditorias.
4.2 Los auditores internos y los responsables de todas las áreas, serán responsables de
participar en forma comprometida en el cumplimiento de realización de las
auditorias internas en las fechas planeadas.
5.0 Áreas Involucradas
Todas las áreas.
6.0 Definición de términos.
Auditoria.- Proceso sistemático, independiente y documentado para obtener

evidencias de la auditoria y evaluarlas de manera objetiva con el fin de determinar
la extensión en que se cumplen los criterios de auditoria.
Auditado.- Organización que es auditada.
Auditor.- Persona con la competencia para llevar a cabo una auditoria.
Lista de verificación.- Documento que enlista aspectos específicos de
importancia para ser analizados durante la auditoria.
Solicitud de Acción Correctiva (SAC). - Documento que define una no-
conformidad específica resultante de la auditoria y la fecha en la cual se solicita al
184
auditado indique la causa de la no-conformidad y un plan de acciones correctivas

o un sumario de acciones correctivas implementadas.
Acción correctiva.- Acción tomada para eliminar la causa de no-conformidad
detectada u otra situación indeseable.
Observación.- Declaración de un hecho efectuado durante una auditoria de calidad
y soportado por evidencia objetiva.
Auditor líder.- Individuo asignado con responsabilidad administrativa para
asegurar que se cumplan todas las fases de una auditoria.
No-conformidad.- Incumplimiento de un requisito.
Evidencia objetiva.- Información que puede ser probada como verdadera, basada
en hechos obtenidos por medio de observación, medición, prueba u otros medios.
7.0 Clases o tipos de Documentación
_____Entradas_____ _____Salidas____
Lista de Verificación Normas ISO 9000:2001 Formato Reporte de Auditorias
Formato del Plan de Auditorias Solicitud de Acción Correctiva
8.0 Políticas
8.1 Es requisito que los auditores estén calificados para tal efecto.
8.2 El personal de auditoria no puede auditar su propia área de trabajo o donde

tenga responsabilidad directa.
9.0 Procedimiento
9.1 Selección de Auditores

La calificación y selección de auditores se basa en la experiencia de las auditorias
realizadas y el entrenamiento en el conocimiento de la norma ISO 9000:2000
cursado en alguna organización nacional o internacional.
El auditor líder deberá contar con un nivel de escolaridad mínimo de licenciatura en

adición a lo requerido a los auditores; o bien, contar con certificado de auditor líder
registrado.
9.2 Procedimiento de Auditoria
9.2.1 El representante de calidad dará una plática sobre los requisitos a auditar
dirigida a los auditores internos, con la finalidad de explicar su contenido.
9.2.2 El representante de calidad asignará la responsabilidad para la programación

y conducción de las auditorias identificadas.
9.2.3 Todos los elementos aplicables del Manual de Calidad serán auditados
anualmente. Las auditorias adicionales serán programadas como sea necesario
basándose en el estado e importancia de la actividad.
9.2.3 Los auditores serán seleccionados basándose en su independencia del área a

ser auditada y compromisos preexistentes. El número de auditores involucrados es
dependiente del tamaño y complejidad del área.
9.2.4 Los planes de auditoria y sus detalles serán desarrollados por él(los)
auditor(es) designado(s) y aprobados por el Auditor Líder o el representante de
calidad.
185
9.2.5 El auditor designado efectuará la coordinación de la auditoria (incluyendo la

notificación a los departamentos relacionados.
9.2.6 Se empleará la lista de verificación, complementándola con elementos

resultantes de la revisión de procedimientos por el auditor, reportes de auditoria
anteriores.
9.2.7 El método de conducir una auditoria inicia con la revisión de la

documentación relevante del sujeto de la auditoria y el desarrollo del Plan de
Auditoria, siguiendo la estructura mostrada en el Anexo 1. La complejidad de la
auditoria puede requerir, asignar tareas específicas a los miembros del equipo de
auditoria. Una junta previa a la auditoria con el coordinador del área(s)
relacionado, fijar el tiempo de la auditoria y la disponibilidad del personal
involucrado. La auditoria seguirá el plan de control de procesos o procedimientos
para determinar el cumplimiento de las funciones, anotando cualquier desviación.
El equipo auditor se apoyará en el representante de calidad en cuanto a la provisión

de recursos necesarios para llevar a cabo la auditoria. Sin embargo, el
representante de calidad no puede guiar o proveer todas las respuestas a las
preguntas de auditoria. El personal auditado del área será motivado a participar en
el libre intercambio de información. El cuestionamiento seguirá los lineamientos
proveídos al gerente de la Organización en la junta previa a la auditoria. Sin
embargo, el auditor tiene que ser libre de seguir una línea de búsqueda si se
encuentra un punto con problemas potenciales. La auditoria será conducida en una
atmósfera mutua de respeto, sin adversidad.
9.2.8 La consolidación de los resultados de la auditoria será formulado por el

auditor en el reporte de la auditoria final siguiendo la estructura del Anexo 2.
9.2.9 El auditor es responsable de notificar los resultados de la auditoria en la

junta posterior a la misma, hacer el reporte de auditoria, emisión de SACs (Anexo
3). El representante de calidad es el encargado de emitir el SACs (anexo 3) para
las no conformidades reportadas durante la auditoria. El gerente de la Organización
auditada, será responsable de indicar la causa de la no conformidad en la sección 2
y el plan de acciones correctivas en la sección 3 de la solicitud de acción correctiva,
enviándola al auditor.
9.2.10 La validación de las respuestas a las acciones correctivas como un resultado

de una no-conformidad detectada durante la auditoria será analizada por el auditor,
quien en caso de no estar de acuerdo, coordinará con el gerente. La verificación
de la efectividad de la acción correctiva implantada será avalada por el auditor líder
y por el representante de calidad en la sección 4 de la solicitud de acción
correctiva. Cuando no exista cumplimiento a las fechas compromiso acordadas, se
notificará al Gerente para reforzar el seguimiento.
9.2.11 La auditoria se termina después de la junta posterior a la auditoria, y

después de que se han emitido el reporte de auditoria y las SAC's aplicables. No
obstante, el archivo de auditoria quedará "abierto" todo el tiempo que exista SAC's
abiertas. El representante de calidad es responsable del seguimiento de las SAC's
abiertas hasta que se verifique y se acepte la efectividad de la acción correctiva y
su posterior notificación oficial al auditor líder de que la no-conformidad ha sido
superada. El auditor líder es responsable de crear el archivo de auditoria que
incluye el plan de auditoria, lista de verificación, reporte y SAC's emitidas, así
como, actualizar el índice de auditoria localizado en la de calidad.
186
Cuando todos los puntos estén completos (incluyendo SAC's), el representante de

calidad "cerrará" el archivo de auditoria una vez que el auditor líder valide las
acciones correctivas implantadas.
9.2.12 Los resultados de las auditorias internas de calidad serán una parte integral
de las actividades del Gerente.
9.2.13 Mantenimiento de registros: Los archivos de auditoria serán almacenados en

el Área de Calidad (referenciando acciones correctivas para no conformidades).
9.2.14 El número de auditorias internas se codificará asignando un primer número

referente a la cantidad de auditorias efectuadas a un elemento de la norma seguido
de la letra A (auditoria interna) seguido de un número correspondiente con el
elemento auditado.
Ejemplo: 1A74 - Primera auditoria interna al elemento "Compras".
9.2.15 Cada auditor interno numerará las acciones correctivas por él generadas
dando un número consecutivo seguido de las dos iniciales de su nombre. P.ej.: No.
de SAC 02-MR (Acción correctiva No. 02) generada por Elisa Rojas. El
representante de calidad podrá asignar otro número de control para su archivo
relacionándolo con el número de la auditoria para fines de integración de todas las
acciones correctivas. P.ej.: La SAC 02-MR corresponde a la tercera no-
conformidad de la auditoria 1A74, el número de control será: 1A-02-MR-03.
187
Anexo 1
FORMATO PLAN DE AUDITORIA (SOLO REFERENCIA)
PLAN DE AUDITORIAS
TITULO_____________________ AUDITORIA No.__________ FECHA__________
SECCIONES/ AREAS A SER AUDITADAS__________________________________________
ITINERARIO DE LA AUDITORIA:
Junta de preauditoria: Repres._________________ Fecha___________ Hora__________
Auditoria Sección/ Área:

____________ Participantes___________________ Fecha___________ Horario________
Junta Post.auditoria: Repres. ___________________ Fecha___________ Horario________
PROPOSITO DE LA AUDITORIA__________________________________________________
REQUERIMIENTOS: Áreas de interés_____________________________________________

Personal/
Docto. ______________________________________________
PERSONAL DE AUDITORIA: _____________________________________________________
ACTIVIDADES A SER AUDITADAS: ________________________________________________
PERSONAL QUE SERA NOTIFICADO: _____________________________________________
REGISTROS Y DOCUMENTOS APLICABLES:

________________________________________________
________________________________________________
PROCEDIMIENTOS____________________________________________________________
AUDITOR LIDER: ______________________________ Firma_________ Fecha__________
AUDITOR ADM. ________________________________ Firma_________ Fecha__________
188
Anexo 2
FORMATO REPORTE DE AUDITORIA (SOLO REFERENCIA)
REPORTE DE AUDITORIAS
TITULO_________________________________ AUDITORIA No.________ FECHA_______
SECCIÓN / AREAS AUDITADAS____________________________________________________
PROPOSITO DE LA AUDITORIA__________________________________________________
ITINERARIO DE LA AUDITORIA:
Junta de preauditoria: Repres.______________________ Fecha_________ Hora_________
Deptos./Áreas auditadas:
________ Participantes ____________ / ____________ Fecha_________ Horario_______
Junta Post.auditoria: Repres:______________________ Fecha_________ Hora__________
RESULTADOS DE LA AUDITORIA.
Depto/Área_________________ Auditado__________________ Resp. __________________

Anomalìas______________________________________________________________________
Anomalìas______________________________________________________________________
Anomalìas______________________________________________________________________
Anomalìas______________________________________________________________________
OBSERVACIONES:(puntos que no fueron contemplados en el plan de auditoria)

________________________________________________________________________________
FECHA REQ. ACCIONES CORRECTIVAS: ___________________
AUDITOR LIDER: ____________________________ Firma _____________ Fecha _________
AUDITOR _________________________ Firma _____________ Fecha _________
AUDITOR _________________________ Firma _____________ Fecha _________
189
ANEXO 3
FORMATO REPORTE DE AUDITORIA (SOLO REFERENCIA)
REPORTE DE AUDITORIAS
SOLICITUD DE ACCION CORRECTIVA
No.___________________
PARA ÁREA FECHA DE FIRMA DEL

AUDITORIA AUDITOR
ESTANDAR CLAUSULA NO. PROCEDIMIENTO

APLICABLE
(1) NO CONFORMIDADES
Elaboración del programa El auditor verifica la

efectividad de la acción
anual de auditorias asignado Acción efectiva No
correctiva registrada en la
a auditores SAC correspondiente
FAVOR DE CONTESTAR FIRMA DE FECHA

ANTES DE LA FECHA CONFORMIDAD/AUDITADO Yes
(2) CAUSA DE NO CONFORMIDAD El propietario del

procedimiento de accines
Auditor interno estudia
correctivas y preventivas
procedimientos aplicables
l eva seguimiento para la Auditor cierra la SAC
coordinado con áreas y
aplicación de la acción
elabora plan
correctiva en la fecha
compromiso.
(3) PLAN DE ACCIÓN CORRECTIVA Fin

Auditor lider autoriza plan de
Contestación adecuada No
auditorias
sí
FECHA COMPROMISO DE FIRMA (GENERTE DE LA
Auditor genera una nueva
SAC indicando la No
FECHA
ACCIÓN CORRECTIVA DIVISIÓN) conformidad resultante
Auditor interno hace junta de
apertura y evalue el sistema Auditor interno valida la
(4) VERIFICACIÓN FINAL DE LA ACCIÓN
en base a procedimiento o
respuesta
CORRECTIVA
planes de control aplicables.
Envia notificación de la
nueva SAC a la grupo de
mejora y da aviso a
Gerencia y al propietario del
ACCIÓN CORRECTIVA EFECTIVA FIRMA
El (o los) propietario (s) del procedimiento de acciones FECHA
proceso (s) y/o correctivas y preventivas
El auditor interno registra procedimiento (s) auditados
SI todas sus observaciones en
el check list
NO firma la contestación de la
causa y la acción correctiva
indicando fecha de
aplicación.
DIAGRAMA DE FLUJO DE AUDITORIAS INTERNAS Auditor interno coordina con
la Gerencia la respuesta
No
adecuada para la acción
correctiva
El propietario del
El auditor interno certifica procedimiento de acciones
haber cubierto todos los correctivas y preventivas
aspectos indicados en el l eva seguimiento para
check list obtener respuesta en la
fecha requerida.
190
El mismo día al finalizar su Ing. Rita
El auditor entregaMa.
reporte de Culebro Gómez
auditoría notifica al auditado auditoria y SAC´s al
las no conformidades y auditado indicando la fecha
observaciones encontradas para obtener respuesta.
191
0006
PROCEDIMIENTO (PROPUESTO) DE
ACCIONES CORRECTIVAS Y PREVENTIVAS
1.0 Propósito
Establecer un sistema para implementar y documentar acciones correctivas y preventivas
tomadas para la eliminación de las causas de No Conformidades actuales y potenciales.
2.0 Alcance
Este procedimiento aplica a todas las áreas relacionadas con la toma de acciones
correctivas y preventivas para eliminar No Conformidades de servicios, procesos,
materiales comprados y del sistema de calidad.
3.0 Requerimientos
Ninguno
4.0 Responsables de la Implementación
4.1 El Representante de Calidad es responsable del: mantenimiento de este

procedimiento y de su monitoreo así como reportar el estado que guardan las acciones
correctivas y preventivas para la Revisión Gerencial.
4.2 El propietario del Procedimiento de Acciones Correctivas y Preventivas es

responsable de: la coordinación, seguimiento y la eliminación de las causas de No
Conformidad reales o potenciales y presentar la información pertinente de las Juntas
Periódicas de Calidad sobre las acciones correctivas/preventivas y los controles tomados
para asegurar la eficiencia de dichas acciones.
4.3 Los propietarios de los procedimientos y/o procesos son responsables de:
colaborar con la detección de las causas raíz de la No conformidad y coordinar esfuerzos
con el propietario del Procedimiento de Acciones Correctivas y Preventivas para la
eliminación de dichas causas reales o potenciales.
5.0 Areas Involucradas
Todas las áreas.
6.0 Definiciones, términos y símbolos
6.1 Acción Correctiva.- Actividades orientadas para eliminar las causas raíz de No
Conformidades y para prevenir su recurrencia. Las acciones correctivas pueden ser
iniciadas, sin ser limitadas a:
- Servicio No Conforme
- Resultados de Auditoria Interna/ Externa
- Devoluciones del Cliente
- Satisfacción del cliente.
6.2 Acción Preventiva.- Acciones tomadas cuando una No Conformidad potencial es

identificada como resultado de análisis de registros y otras fuentes relevantes de
192
información que puedan indicar tendencias o probabilidad de ocurrencia potencial de la No

Conformidad. Las acciones preventivas pueden ser iniciadas, pero no limitadas a:
- Resultados de Auditoria Interna/ Externa

- Análisis de Procesos y Operaciones de prestación del servicio
- Desviaciones del servicio acordado
- Análisis de Registros de Calidad
- Cualquier otra Razón cuando la No Conformidad potencial sea identificada.
6.3 SAC.- Siglas empleadas para identificar el formato empleado para Solicitar
Acciones Correctivas derivadas de No Conformidades detectadas en Auditorias al
Sistema de Gestión de Calidad.
6.4 SACS.- Estas siglas indican que se trata de una forma de "Solicitud de Acción
Correctiva" a Servicios y/o Procesos.
6.5 IAP.- Estas siglas indican que se trata de una forma de "Iniciación de
Acción Preventiva" a Servicios y/o Procesos.
6.6 RSNC.- Estas siglas indican que se trata de una forma de "Reporte de Solución a la
No Conformidad" a Servicios y/o Procesos Por parte del Cliente.
6.7 Grupo de Mejora.- Grupo de personas dedicadas a la toma de acciones

Correctivas y Preventivas, conformado por:
a) El propietario del Procedimiento de Acciones Correctivas y Preventivas
b) El o los propietarios del procedimiento y/o proceso involucrado
c) El Representante de Calidad
7.0 Clases o tipo de documentación
Entradas Salidas
7.1 Procedimiento de Auditorias Internas de Calidad SAC
7.4 Pasos para la solución de problemas (Anexo IV) Reporte 7Ds
7.5 Iniciación de Acción Preventiva IAP-Anexo III y IIIA

7.6 Iniciación de acción correctiva SAC
7.7 RSNC
8.0 Políticas
8.1 Generales
8.1.1 Las solicitudes de Acciones Correctivas y Preventivas pueden ser generadas
por cualquier empleado para notificar No Conformidades actuales o
potenciales y requerir la eliminación de la causa raíz.
8.1.2 Los cambios resultantes de Acciones Correctivas y Preventivas deberán

implantarse y registrarse en procedimientos documentados.
8.1.3 Todas las Acciones Correctivas y Preventivas tomadas para eliminar las
causas de No Conformidades reales o potenciales serán proporcionales a la
magnitud de los problemas detectados y a los riesgos que de ellos puedan
derivarse.
193
8.1.4 Se puede emplear de ser necesario un método disciplinado (8 Disciplinas)

para la solución de problemas cuando ocurra una No Conformidad interna o
externa a los requerimientos o especificaciones. Los pasos básicos para
investigar la causa y toma de acción correctiva, se describen en el anexo.
9.0 Procedimiento
9.1 Acciones Correctivas
9.1.1 Las acciones correctivas derivadas de las Auditorias Internas serán

atendidas conforme a lo indicado en el procedimiento 0006.
9.2.2. Las acciones correctivas por No Conformidad encontradas en Materiales y

Productos Comprados serán atendidas como se indica en el procedimiento
“Elaboración de solicitud de Compra”.
9.2.3 Las acciones correctivas serán requeridas para No Conformidades de

Servicios en Proceso, para servicio No Conforme detectado en con el cliente
derivado de Reclamos.
9.2.4 Para acciones correctivas requeridas por clientes, el propietario del

Procedimiento de Acciones Correctivas y Preventivas indicará en el formato de
Acción Correctiva del Servicio (SACS) Anexo I, la No Conformidad resultante del
análisis y pruebas al servicio No Conforme, para dirigirla al Gerente con copia para
el Representante de Calidad, quién asignará a una persona o grupo para solucionar
la No Conformidad y llenar el reporte dentro de un límite de tiempo requerido.
Al cerrar y validar la acción correctiva, el Representante de Calidad valida la

solución estampando su firma en la sección "F" correspondiente al formato SACS. Si
el problema no es solucionado, lo lleva al nivel inmediato superior para su atención.
El Reporte de la Solución a la No Conformidad será enviado al cliente con el formato
(RSNC) Anexo II.
9.3 Acciones Preventivas
Las acciones preventivas serán tomadas cuando sea detectada una tendencia
desfavorable o se identifique una no conformidad potencial en el proceso/ servicio.
9.3.1 La acción preventiva es iniciada mediante el análisis de reportes de: Tiempo

de Respuesta, Costos. Las tendencias desfavorables son identificadas en la Junta
Periódica de Calidad para iniciar la acción preventiva. Las áreas de oportunidad se
identificarán empleando análisis de Pareto.
9.3.2 El Gerente de informática, forma el grupo de mejora para tomar acciones

preventivas pertinentes.
9.3.3 El grupo de mejora empleará el formato de iniciación de acción preventiva

(IAP) Anexo III para registrar los avances que se reportarán al gerente junto con la
minuta de cada reunión.
En el anexo III A se indica los pasos a seguir para el llenado de este formato.
9.3.4 Al finalizar, el Representante de Calidad verificará la efectividad de la

acción preventiva.
194
9.3.5 El Propietario del Proceso de Acciones Correctivas y Preventivas

llevará el seguimiento de las IAP's, asignando un número consecutivo y registrando
las acciones preventivas.
9.4 Las SACS's/ IAP's, sin resolver o abiertas deberán ser revisadas por el
grupo de mejora y el Representante de Calidad para asegurar que está siendo
adecuadamente dirigido. Las SACS's/ IAP que no son correctamente dirigidos
después de un seguimiento deberán ser llevados al siguiente nivel Gerencial.
9.4.1 Un reporte mensual emitido por el Propietario del Proceso de Acciones

Correctivas y Preventivas, mostrando el estatus de la SACS/ IAP abierta, incluirá
el número de orden de servicio, la descripción, fecha de iniciación, responsabilidad,
descripción del problema y fechas para la acción.
9.4.2 Si una SACS es emitida con un error, el iniciador deberá ser notificado para
que pueda ser direccionado y el original del SACS sea enviado al Representante
de Calidad, para que al receptor elimine la responsabilidad por esta determinación.
9.4.3 Si la SACS es emitida por error o los resultados obtenidos hacen a la SACS
innecesaria, la SACS deberá ser cancelada por el Propietario del Proceso de
Acciones Correctivas y Preventivas y será el que escriba "Cancelado" lo firmará
y fechará, después lo enviará al Representante de Calidad. Las SACS's canceladas
son identificados y almacenados en el archivo completo.
9.4.4 Las acciones correctivas estarán sujetas a controles para asegurarse que la
acción seguida ha resuelto lo que no conformidad. Los controles en lugar deben
incluir las secciones D y E del SACS.
9.5 Registros
9.5.1 Los documentos deberán revisarse como se requiere por acciones

correctivas/ preventivas.
9.5.2 Calidad deberá recibir una copia de todas las IAP/ SACS's
completadas/iniciadas-aprobadas. El Propietario del Proceso de Acciones
Correctivas y Preventivas y el Representante de Calidad son responsable de
trabajar con él o los propietarios de los procesos y/o procedimientos
involucrados para facilitar la estabilidad y resolución de las IAP/ SACS's
apropiadas.
9.5.3 Las acciones correctivas adecuadas con críticas para el mejoramiento

continuo. Las respuestas de la SACS deberán concentrarse en los elementos del
sistema y qué acción se requiere para prevenir su recurrencia, en vez de responder
a los aspectos específicos identificados.
9.5.4 Los Reportes de Acciones Correctivas/ Preventivas documentando los

resultados de la investigación de las causas de No Conformidad, deberán
conservarse por el Auxiliar de Calidad de acuerdo al procedimiento DF06N2M424.
195
ANEXO I A
Llenado de la Forma (SACS)
Lo siguiente describe el tipo de información que se incluirá en cada Sección de la Forma

SACS. No se deje ninguna área en blanco. Si el área no aplica, coloque un N/A en el espacio
apropiado. El Propietario del Proceso de Acciones Correctivas y Preventivas es
responsable de completar las siguientes acciones A, B, y E.
1.0 Llenado de la Sección A:
Número de control interno:

Cada SACS deberá ser identificado utilizando un número de control único
que Indica el número correspondiente al reporte de No Conformidad, el
Propietario del Proceso de Acciones Correctivas y Preventivas asigna
el número de control antes de emitir la forma SACS.
Asignado A:
Nombre del Propietario del Proceso de Acciones Correctivas y Preventivas
de la Gerencia de informática, designado para coordinar su terminación.
Fecha de Emisión:
Fecha en que el SACS fue asignado.
Iniciado por:
El nombre del Propietario (s) del proceso y/o procedimiento
involucrado (s) que inició la solicitud de acción correctiva o preventiva.
Fecha de Finalización
La fecha en que la SACS deberá cerrarse, esta fecha no deberá exceder de
30 días posteriores a la fecha de emisión y servirá para seguimiento por
parte del Propietario del Proceso de Acciones Correctivas y
Preventivas.
2.0 Llenado de la Sección B:
Número de orden de servicio:

El número de orden de servicio que tiene la No Conformidad.
Descripción de la No Conformidad:
Poner tantos detalles en la forma mas clara posible para la descripción del
problema. También anotar cuando fue encontrado el problema, la frecuencia
de la No Conformidad, porcentaje de No Conformidad y cualquier otra
información útil para resolver el problema.
3.0 Llenado de la Sección C:
Acciones de Contención:
La acción inmediata tomada por él (o los) Propietario (s) del proceso y/o
procedimiento(s) involucrado (s) para minimizar el efecto de la No
Conformidad puede ser una solución a corto plazo al problema, hasta que la
causa raíz del problema sea determinada y resuelta.
4.0 Llenado de la Sección D:
196
Causa Raíz:
El Propietario (s) del proceso y/o procedimiento involucrado (s) y el
Propietario del Proceso de Acciones Correctivas y Preventivas
Identificarán la No Conformidad y a través del uso de las técnicas de
solución de problemas, identificarán la causa raíz.
Acciones Correctivas y Permanentes:

El Propietario (s) del proceso y/o procedimiento (s) involucrado (s) y
el Propietario del Proceso de Acciones Correctivas y Preventivas
identificarán las actividades que aseguran que el problema no vuelva a
ocurrir.
Esta sección deberá ser firmada y fechada.
La fecha de implementación deberá de ser la fecha en que la acción
correctiva sea implementada completamente.
Gerencia:
La SACS completa deberá enviarse a Gerencia quien revisará y aprobará la
respuesta.
5.0 Llenado de la Sección E:
Revisión de acciones correctivas:

El Propietario (s) del proceso y/o procedimiento involucrado (s) y el
Propietario del Proceso de Acciones Correctivas y Preventivas
revisarán la SACS, para asegurar que la acción tomada es adecuada. Si la
acción tomada es aceptada y completamente implementada, se firmará,
fechará y marcará en la columna de "Aceptada". Si la acción propuesta es
aceptada, pero no completamente implementada, se proveerá una fecha de
seguimiento, marcando en la columna de "Pendiente", con su firma. Si la
acción propuesta no es aceptada, indicará fecha de seguimiento en la
columna de "Rechazada" marcándola y poniendo su firma.
6.1 Aceptada:
La SACS deberá ser enviada con el Representante de Calidad, para que
sean actualizadas marcando el recuadro de "Aceptada" y programar su
implementación.
6.2 Pendientes:
La SACS deberá ser llevada el Propietario del Proceso de Acciones
Correctivas y Preventivas para que de seguimiento de las SACS's y
pueda ser actualizadas como "pendiente" para la solución de la no
conformidad.
Nota: El Gerente de informática es responsable de contactar al

Representante de Calidad y pedir que firme, ponga fecha y marque
"Aceptada" de la Sección E de la SACS original, cuando la respuesta
ha sido completamente implementada.
La SACS deberá ser despachada a la sección correspondiente para
que pueda ser cambiado del estatus de "Pendiente" a "Aceptada".
6.3 Rechazada:
La SACS deberá ser discutida con el grupo de mejora para que el problema
pueda ser resuelto y la fecha de seguimiento determinada. Una SACS nueva
deberá ser emitida con la nueva fecha y el mismo número de SACS (La copia
197
de rechazado de la SACS será anexada). Las SACS's rechazadas

permanecerán "abiertas" hasta que el estatus cambie a “Aprobada”.
El original de la SACS deberá ser enviada al Representante de Calidad,
con la nueva fecha de seguimiento para fines de actualización.
6.0 Llenado de la Sección F:
Validado por:
Esta sección deberá ser completada únicamente si en la Sección E se indica
"Aceptada". La validación de las SACS's será conducida por Representante
de Calidad. Si la validación es aceptada, se coloca firma, fechar y marque el
cuadro de "Aprobada" indique en comentarios como la SACS fue validada,
identificando los métodos de verificación usados para asegurar que la acción
correctiva fue efectiva. Si la validación no es aceptada, se pondrá la firma,
fecha y se marca el cuadro de "Rechazada", indicando en comentarios la
razón de la no validación.
198
ANEXO II A
Llenado de la Forma (RSNC)
Lo siguiente describe el tipo de información que se incluirá en cada Sección de la Forma

RSNC. No se deje ninguna área en blanco. Si el área no aplica, coloque un N/A en el
espacio apropiado. El Propietario del Proceso de Acciones Correctivas y Preventivas
es responsable de completar las siguientes acciones A, B, y E.
2.0 Llenado de la Sección A:
Número de control interno:

Cada SACS deberá ser identificado utilizando un número de control único
que Indica el número correspondiente al reporte de No Conformidad, el
Propietario del Proceso de Acciones Correctivas y Preventivas asigna
el número de control antes de emitir la forma SACS.
Asignado A:
Nombre del Propietario del Proceso de Acciones Correctivas y Preventivas
designado para coordinar su terminación.
Fecha de Emisión:
Fecha en que el SACS fue asignado.
Iniciado por:
El nombre del Propietario (s) del proceso y/o procedimiento
involucrado (s) que inició la solicitud de acción correctiva o preventiva.
Fecha de Finalización
La fecha en que la SACS deberá cerrarse, esta fecha no deberá exceder de
30 días posteriores a la fecha de emisión y servirá para seguimiento por
parte del Propietario del Proceso de Acciones Correctivas y
Preventivas.
2.0 Llenado de la Sección B:
Número de orden de servicio:

El número de orden de servicio que tiene la No Conformidad.
Descripción de la No Conformidad:
Poner tantos detalles en la forma mas clara posible para la descripción del
problema. También anotar cuando fue encontrado el problema, la frecuencia
de la No Conformidad, porcentaje de No Conformidad y cualquier otra
información útil para resolver el problema.
3.0 Llenado de la Sección C:
Solución (es) emitida (s):

La acción o acciones tomadas por él (o los) Propietario (s) del proceso
y/o procedimiento involucrado (s) para minimizar el efecto de la No
Conformidad.
Gerencia:
La RSNC completa deberá enviarse a Gerencia de informática, quien revisará
y aprobará la respuesta.
199
Aprobación de las acciones correctivas por parte del cliente:

Llenos los campos A, B y C, el formato original de RSNC será enviado al
cliente.
El Cliente revisará la RSNC, para asegurar que la acción tomada es
adecuada. Si la acción tomada es aceptada y completamente implementada,
se firmará, fechará, y agregara su cargo de la compañía a quien representa y
por último marcará en la columna de "Aceptada". Si la acción propuesta no es
aceptada, marcará en la columna de "Rechazada" e indicará fecha y firma.
Comentarios:
Indique en comentarios como la RSNC fue aprobada, identificando los
métodos de verificación usados para asegurar que la acción correctiva fue
efectiva. Si la validación no es aceptada, indique en comentarios la razón
por la cual fue “Rechazada”. Regrese la RSNC para archivo o para volverse
a emitir.
6.1 Aceptada:
Cuando la RSNC a sido aceptada por el cliente, la RSNC original deberá ser
enviada al archivo y emitir copias para el grupo de mejora, y comunicar la
solución.
6.3 Rechazada:
Cuando la RSNC ha sido rechazada por el cliente: la SACS y RSNC deberán
ser discutidas con el grupo de mejora para que el problema pueda ser
resuelto y la fecha de seguimiento determinada. Una SACS nueva deberá ser
emitida con la nueva fecha y el mismo número de SACS (La copia de
rechazado de la RSNC será anexada a el archivo). La RSNC rechazada
permanecerá "abierta" hasta que el estatus cambie a “Aprobada”.
Validado por:
Esta sección deberá ser completada después de que la Sección D haya sido
llenada. La validación de las RSNC's será conducida por Representante de
Calidad donde pondrá su nombre, firma, y fecha cuando la RSNC fue
validada.
Comentarios:
En este espacio el Representante de Calidad Indicará como la RSNC fue
validada, identificando los métodos de verificación usados para asegurar que
la acción correctiva fue efectiva. Si la RSNC no es aceptada por el Cliente,
indicará la razón del rechazo y regresará la RSNC para archivo y para
volverse a emitir posteriormente.
200
Anexo III A
Llenado de la Forma de Iniciación de la Acción Preventiva (IAP)
1.0 Definición del Problema

Defina claramente el problema potencial o la tendencia que se decide atender.
2.0 Grupo
Forme un grupo multifuncional de estudio del problema, los integrantes deberán de
tener experiencia en el área en que se desea estudiar el problema, para el estudio
del mismo, el propietario del proceso de Acción Preventiva deberá de coordinar las
labores a desempeñar por cada integrante del equipo.
3.0 Descripción Esquemática del Problema

Ayuda visual empleada para mejorar la descripción del problema cuando sea
necesario.
4.0 Medición del Nivel de Calidad

Anote el nivel actual de calidad del problema: por ejemplo, tiempo de realización del
servicio, nivel de satisfacción del cliente en %, costo, etc., y establezca las metas a
alcanzar en 2 periodos de tiempo (corto y largo plazo).
5.0 Utilice para el análisis de Problemas Potenciales un Diagrama de Causa y

Efecto
En el diagrama anote todas las posibles causas que puedan dar origen al problema,
empleando lluvia de ideas.
6.0 Listar causas del problema

En liste las tres principales causas raíz de la sección de lluvia de ideas.
7.0 Determinación de la Acción Preventiva y Plan de Implementación

Una vez identificada la posible causa raíz, determine la Acción Preventiva a tomar
así como el responsable y fecha de implantación.
8.0 Verificación de la Efectividad de las Acciones

Mediante el seguimiento de la implantación de la acción, verifique los resultados
obtenidos y compárelos con los datos establecidos en el punto 4.0 Use gráficas
para medir la mejora.
9.0 Fin del Estudio

Anote la fecha en la cual se dio por terminado el proyecto de iniciación de Acción
Preventiva, y la fecha de la siguiente junta, para comparación de resultados.
Nota: La metodología mostrada en el Anexo III también es útil para el análisis de

problemas potenciales.
201
ANEXO IV
6 DISCIPLINAS PARA LA SOLUCION DE PROBLEMAS
Es importante que los esfuerzos para la solución de problemas sigan un proceso lógico
sistemático. La solución de problemas se hará conforme a los siguientes 6 pasos:
Paso No. 1 Formar un equipo de trabajo.
Paso No. 2 Identificar y definir el problema.
Paso No. 3 Aislar y comprender el problema.
Paso No. 4 Colectar y analizar la información.
Paso No. 5 Corregir y reducir el problema.
Paso No. 6 Monitorear y cambiar el documento.
1 y 2. Identificar y Definir el Problema:
Forme un equipo de trabajo para la solución del problema donde el principal objetivo
es estar seguro que ha identificado el problema verdadero o la causa raíz y no los
síntomas:
- Mire las señales del posible problema.
- Pregunte acerca del problema:
. ¿Qué ha sido afectado?

. ¿Cuáles son los síntomas?
. ¿Dónde aparecen?
. ¿Cuándo ocurren?
. ¿Cuántos productos están afectados?
- Ver si el problema es recurrente.
- Escriba claramente la definición del problema.
- Describa el problema con tantos detalles como le sea posible.
3. Aislar y comprender el problema:
En este paso, la meta es encontrar en forma inmediata algo que arregle

temporalmente el efecto del problema. Después se podría encontrar una solución a
corto plazo que podría ser también la solución más apropiada para largo plazo. Pero
usted no podrá hacer un juicio hasta que no haya estudiado el problema.
- Mantenga informado al cliente del avance de la solución de su no conformidad.
4. Colectar y analizar la información:
El objetivo de este paso es juntar información sobre el problema y sus causas,

analizar la información para determinar la solución más efectiva.
- Coleccionar información acerca de la frecuencia de ocurrencia, localización,

valores de mediciones o costos del problema.
202
- Eliminar, el adivinar, rumores y opiniones (el yo opino) sobre la solución del

problema.
- Utilizar herramientas y técnicas adecuadas para colectar y analizar la información:
. Lluvia de ideas.
. Diagramas de causa y efecto.
. Hojas de verificación
. Diagramas de Pareto, etc.
5. Corregir o reducir el problema:
En este paso usted podrá corregir las acciones que eliminarán el problema del
proceso o para prevenir la posible recurrencia del mismo.
Utilice el siguiente criterio para el desarrollo adecuado de la solución.
. Satisfacción del cliente

. Costo
. Tiempo de servicio
. Facilidad de implementación.
. Haga un consenso de grupo para la solución.
. Base los cambios necesarios sobre el conocimiento individual del
problema y los procesos.
. Determine si el problema ha sido corregido, o si un nuevo problema ha
sido creado.
6. Monitorear y cambiar el documento:
El esfuerzo de la solución de problemas no termina hasta que usted implementa una

solución. El último paso es seguir sus acciones, para asegurar que el problema ha
sido corregido y para registrar sus descubrimientos para que la información este
disponible por si ocurre un problema similar en el futuro.
- Monitorear el proceso para determinar la efectividad de los cambios.
- Documentar los métodos usados para resolver problemas.
- Provea documentación de:
. Pasos tomados
. Herramientas y técnicas usadas.
. Personal involucrado.
. Personal que necesitan involucrarse.
. Seguimiento adicional, si es necesario.
- Utilice cartas y gráficas para:
. Ganar soporte y cooperación de otras personas de la compañía
203
ANEXO I
SOLICITUD DE ACCIÓN CORRECTIVA A SERVICIOS (SACS).
A Asignado a: ______________________________________ No. de no control
interno__________
Fecha de
emisión__________
Iniciado por: _____________________________________ Fecha de finalización_____________
B
Número de Orden de Servicio: ____________________
Descripción de la no conformidad:
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
C Acciones de Contención:
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
D Causa raíz:
________________________________________________________________________________
________________________________________________________________________________
Acción Correctiva/Preventiva:
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
Enviado por: _____________________________________Fecha__________________________
Gerencia ________________________________________Fecha de implantación_____________
E Revisión de la acción correctiva
ACEPTADA PENDIENTE RECHAZADA

(Validación requerida) (seguimiento requerido) (Asignado a)
Fecha_________________ Fecha de seguimiento__________ Fecha de

seguimiento________
Evaluado por__________ Evaluado por_________________ Evaluado por_____________
Fecha_______________________
Fecha___________________
F Validada por:
Representante de Calidad:
____________________ _________________________
_______________
Nombre Firma
Fecha
APROBADA RECHAZADA
Evaluado por_____________________ Evaluado por:
__________________________
Fecha____________________________
Fecha__________________________________
Comentarios________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________
204
ANEXO II
REPORTE DE SOLUCIONES A NO CONFORMIDADES (RSNC).
A Asignado a: ____________________________________ No. de no control interno__________
Fecha de
Emisión________________
Iniciado por: _____________________________________ Fecha de finalización_____________
B
Número de Orden de Servicio: ____________________
Descripción de la no-conformidad:
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
C Solución (es) emitida (s):

____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
_____________________________________________________________________
Enviado por: _______________________________________Fecha__________________________

Gerencia ________________________________________Fecha de implantación_____________
D Aprobación de la acción correctiva por parte del cliente:

ACEPTADA RECHAZADA
Fecha_______________________ Fecha ______________________________

Evaluado por________________ Evaluado por_______________________
Cargo______________________
Firma______________________ Firma_____________________________
Comentarios:_______________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________
E Validada por:
Representante de Calidad:
__________________ ______________________
__________________
Nombre Firma
Fecha
Comentarios:_______________________________________________________________________
____________________________________________________________________________________
____________________________________________________________________________________
________________________
205
Definición del problema: Listar las 3 principales causas raíz de la

sesión de tormenta de ideas:
_______________________________________
_______________________________________ 1.______________________________________
_______________________________________ ____
_______________________________________ 2.______________________________________
________________ ____
3.______________________________________
____
Grupo Descripción Determinar la acción preventiva y plan de
1._______________ esquemática del implementación:
2._______________ problema (sí se
Causa Raíz Acción Preventiva Respuesta
3._______________ requiere): Fecha
4._______________
5._______________ 1.______________________________________
6._______________ ________________________________________
7._______________ ________
Líder_____________ 2.______________________________________
_ ________________________________________
__________________ ________
_ 3.______________________________________
__________________ ________________________________________
_ ________
Medición del nivel de Calidad Verificar efectividad de las acciones:
Nivel Actual Unidades

De
Nivel meta 1(D/M/A)_________ Medición
_______________________________________ Del nivel
____ De Caliad
Nivel meta 2(D/M/A)________
_______________________________________
____
ANTES DESPUES
DE LA MEJORA
Si las acciones no son efectivas volver a

la lluvia de ideas.
Proyecto terminado en fecha:

_____________________
Fecha de siguiente junta:

_____________________
Material Mano de obra
Problema
Método Maquina
ANEXO III
FORMATO DE INICIACIÓN DE ACCIÓN PREVENTIVA (IAP).
206
5.6 Comentarios.
De la investigación realizada, y con relación al problema planteado en este trabajo, se
sugiere que no existe una sola manera de implementación de un sistema de gestión de este
tipo, ya que de igual forma en que cada industria tiene sus particularidades cada empresa
también, sin embargo, algunas actividades que se recomiendan son:
En la sección de Proyecto de Mejora, específicamente, Desarrollo de la documentación, se

recomienda llegar al detalle de quien entrega qué a quién, es decir, a un nivel suficiente
para que todos lo sepan y lo entiendan.
4.2 Requisitos de la documentación.
Elaborar los procedimientos específicos e instructivos de trabajo, planes y programas para
satisfacer la norma.
4.2.3 Control de los documentos.
En esta parte se deberá llevar a cabo el diseño y desarrollo de procedimientos para el
control de documentos del sistema de gestión de calidad, con responsabilidades relativas a
la creación, control y cambios.
4.2.4 Control de los registros.
Establecer el procedimiento documentado que defina los controles para identificar y
mantener los registros de calidad.
6.1 Provisión de recursos.
En este punto, será necesaria la implementación y generación de procedimientos y uso de
ellos.
6.2 Recursos humanos.
Será necesario definir competencias necesarias para las posiciones estratégicas y las del
personal.
6.4 Ambiente de trabajo.
Definir y evaluar un sistema de evaluación del desempeño integral.
7.2.3 Comunicación con el cliente.
Sería significativo implementar un buzón de sugerencias, encuestas, sistema de
sugerencias, quejas o reclamaciones, para crear un proceso de atención al cliente, esto
dependerá del C.C.
8.4 Análisis de datos.
A través de los datos de seguimiento, no conformidades, auditorías, etc. se debe
determinar cuáles son las áreas de oportunidad de mejora al sistema de gestión de calidad.
Por otro lado, al trabajar en la propuesta de la documentación que requiere la norma, como
fue el manual de calidad, y los procedimientos de auditoría y de acciones correctivas y
preventivas, nos da una mejor visión de la utilidad e importancia de tener documentado el
sistema y sobre todo podemos percibir los beneficios que conlleva el hecho de tener una
documentación bien definida y controlada.
Finalmente, el desarrollar e implementar este modelo para la Gerencia de Informática de

Banco de México, apoyado en las recomendaciones que plantea ISO 9000-3, permitirá
tener un sistema de gestión que le soportará en el cumplimiento de sus requerimientos para
así ofrecer servicios y productos de mejor calidad y con mejores niveles de competitividad.
207
CONCLUSIONES Y RECOMENDACIONES.
208
CONCLUSIONES Y RECOMENDACIONES.
El producto o servicio resultante de un proceso con pobre aseguramiento de la calidad,

solo a causa del destino y con mucha suerte, puede resultar relativamente aceptable, por lo
que implementar un sistema de gestión de calidad en las empresas es de suma importancia.
La informática, potenciando a sus recursos humanos es, hoy en día, la herramienta más
poderosa con que cuentan las organizaciones para tener éxito, y más aún cuando se tratan
sistemas que soportan la economía de nuestro país, por lo que es de suma importancia que
estos sistemas estén avalados por una cierta calidad desde su desarrollo; por otro lado, es
importante subrayar que la calidad la hace la gente, y es a base de arduo trabajo por parte
de esta gente que integra las compañías, que se va construyendo día con día.
Mucho se dice que la calidad es una moda, pero considero que no es así, la gestión de la
calidad no es una moda, es sobre todo, un modo de pensar y de actuar; es una forma de
hacer las cosas, es compromiso, pero un compromiso real, no parcial, ya que la
consecuencia de implantar un sistema de calidad resulta en una inversión, la cual es,
altamente redituable a mediano y largo plazo.
En un mercado altamente competitivo, es más ventajoso competir por calidad antes que por
precios.
Hay mucho de qué hablar sobre los sistemas de calidad, pero considero que mucho de ello
se concentra en lo siguiente:
Basándonos en “10 formas de matar un sistema de calidad” de la publicación “Gestión de la
calidad” de la Dra. Teresita Villar y el Prof. Marcos Payssé, tenemos que existen 9:
 12 formas de matar un sistema de calidad

1. Creer que la calidad puede agregarse cuando el producto esta terminado
2. Lanzar un programa de calidad, y luego sentarnos a esperar sus resultados
3. Creer que la calidad es gratis
4. Designar un responsable y que lo apoyen los que tienen tiempo
5. “El programa no debe interferir con las tareas importantes de cada día”
6. Dedicarnos a pensar qué pueden hacer los demás para mejorar nuestro
trabajo
7. Digámosle a la gente que la calidad es lo más importante de su trabajo, pero
descarguemos la responsabilidad a un grupo especial para lograrla
8. Hagamos todo bien, pero no midamos nada relativo a la calidad (solo costos
del programa y presupuesto de fabricación de los productos)
9. El sistema de calidad se debe cumplir a partir de ciertos niveles, pero la
dirección y sus mandos inmediatos no se regulan por el mismo ni forma
parte de la planificación estratégica de la empresa
10. Identifiquemos gente culpable de errores, no analicemos los procesos
11. Consideremos solo los costos visibles de productos noconformes, y no los
sistemas de información para la calidad, los errores de facturación
especificación, informes
12. Creer que la calidad es sólo para “tapar el ojo” al cliente, debido a lo cual
las actividades adoptadas para asegurarla pueden obviarse rutinariamente
 12 formas de hacer exitoso un sistema de calidad

1. La aceptación de que los clientes internos y externos son los protagonistas
más importantes del proceso
9
http://www.cp.com.uy/44/iso44.htm
209
2. El compromiso a largo plazo de la dirección de la Organización de que el

sistema de aseguramiento de la calidad se convierta en parte de la gestión
global
3. El convencimiento de que es factible lograr mejoramientos en el desempeño
de la organización
4. El convencimiento de que es mejor prevenir los problemas que tratar de
corregirlos
5. La concientización de que todo trabajo es mensurable
6. La participación de todos los empleados, tanto en grupos como en forma
personal
7. La confianza en que para el mejoramiento de los procesos, es tan importante
el enfoque tecnológico como las personas
8. El convencimiento de que los proveedores y clientes pueden cooperar
mutuamente si hablan un lenguaje común
9. El reconocimiento de que la calidad la hacen todas y cada una de las
personas de la organización
10. El reconocimiento de que los problemas de bajo nivel de calidad sobre los
productos y servicios liberados siempre son un problema de gerenciamiento.
11. Estar dispuestos a revisarnos para saber dónde mejorar
12. Estar convencidos que la única manera de generar un producto/servicio de
alto nivel de calidad es contar con un proceso de idénticas características
13. Sentar las bases sobre el propio sistema de calidad que nos permitan
aprender del proceso
Considero que lo anterior es de suma importancia y engloba mucho de lo que un sistema de

gestión de calidad puede o no generar.
Actualmente, la satisfacción hacia el uso de un producto puede marcar una gran diferencia
en el mercado de productos similares. Es así como el desarrollo de artículos que satisfacen
las expectativas de los clientes y usuarios harán la diferencia entre las organizaciones que
desarrollan productos similares y que compiten en el mercado.
El desarrollo de productos software no está ausente de ofrecer calidad, es por esto que día
a día las organizaciones y especialmente las productoras de software se preocupan por
implementar mecanismos y estrategias que les conlleven a garantizar:
 La producción de código mas fiable
 Mayor nivel de calidad en todo el ciclo de la producción del software
 Y por ende, la satisfacción de sus clientes y mejora de su ventaja competitiva
Considero que lo anterior no sería posible si una metodología de desarrollo adecuada, pero
soportada con un sistema de gestión de calidad, como lo es ISO 9001, lo cual se demuestra
en este trabajo a pesar de que se llegó a un nivel de propuesta únicamente, sin embargo no
es difícil visualizar lo que sucedería si se implementara este sistema combinado con las
recomendaciones de ISO 9000-3, con todo esto, me parece que se resuelve la problemática
planteada en el apartado 2.4..
210
ANEXOS
211
Anexo 1
REFERENCIAS
1. Andrés Berlinches Cerezo, CALIDAD, LAS NUEVAS ISO 9000:2000 “SISTEMAS DE

GESTIÓN DE LA CALIDAD”, Thompson Paraninfo, 2002 p.20-21
2. Charles H. Schmauch, ISO 9000 FOR SOFTWARE DEVELOPERS, ASQC, 1995 p.149
3. David Sheppard, ENSAYOS, SISTEMAS DE PAGOS, Centro de estudios de Banca

Central, Banco de Inglaterra, Londres, 1996. p.18
4. Estévez R. F., LAS NORMAS ISO 9000 E ISO 14000 DEL NUEVO MILENIO,
SISTEMAS GLOBALES DE GESTIÓN DE CALIDAD Y AMBIENTAL, Qualitec
Internacional, S.A. de C.V., 1999, p.90
5. Guía ISO 9000-3 p.105; p.174
6. Instituto Latinoamericano de la Calidad A.C (INLAC)., Guía de interpretación ISO

9001.2000, INLAC-Latinoamérica, México, p.87
7. INLAC, SISTEMAS DE GESTIÓN DE LA CALIDAD, Serie ISO 9000:2000,

Mejoramiento continuo hacia la excelencia. P.88
8. Ivar Jacobson, Grady Booch, James Rumbaugh, EL PROCESO UNIFICADO DE

DESARROLLO DE SOFTWARE, Adison Wesley, 2000. p.20;p.24-30
9. James L. Lamprecht, GUÍA INTERPRETATIVA DE ISO 9001-2000 CON ÉNFASIS

EN LA METODOLOGÍA ESTADÍSTICA, Panorama, 2001. p.88
10. Michael G. Jenner, SOFTWARE QUALITY MANAGEMENT AND ISO 9001, HOW TO
MAKE THEM WORK FOR YOU, John Wiley & Sons, Inc., 1995 p.22
11. Michael O. Tingey, COMPARING ISO 9000 MALCOM BALDRIGE AND THE SEI
CMM FOR SOFTWARE, Prentice Hall PTR, 1997 p.174
12. Mills, Everald E., SOFTWARE METRICS, Software Engineering Institute (1998). P.6
13. Norma Nacional Americana, SISTEMAS PARA LA GESTIÓN DE LA CALIDAD-

DIRECTRICES PARA LA MEJORA DEL DESEMPEÑO, ANSI/ISO/ASQ Q9004-2000
p.90
14. ISO 9000:2000, NMX-CC-9000-IMNC-2000, COPANT/ISO 9000-2000, p.88;

p.104
15. Norris, Mark; Rigby, Peter, INGENIERÍA DE SOFTWARE EXPLICADA, Ed. LIMUSA,
México, D.F. 1994 p.22
16. Rational software, RATIONAL UNIFIED PROCESS, FUNDAMENTALS, STUDENT

MANUAL, Rational University. p.25
212
17. Rational software, RATIONAL UNIFIED PROCESS, REQUIREMENTS

MANAGEMENT WHIT USE CASES, STUDENT MANUAL, Rational University. p.26
18. W.Humphrey., MANAGING THE SOFTWARE PROCESS, Addison Wesley Longman

Publications (1989). p.22
19. Walter Shewhart, STATISTICAL METHOD FROM THE VIEWPOINT OF QUALITY

CONTROL, Dover publication, Inc., N.Y., 1986. p.89
20. http://www.iso.org p.87

21. http://www.banxico.org.mx p.12
22. http://www.praxiom.com p.174
23. http://www.cp.com.uy/44/iso44.htm p.187
24. http://webinterno/ p.14
25. http://webinterno/BancaCentral/InfoEconomica/InfoSisPagos/SisPagos p.17
213
Anexo 2
Glosario de términos.
Actividad. El estado en el que se exhibe algún comportamiento.
Actor. Un conjunto coherente de roles que los usuarios de casos de uso desempeñan
cuando interaccionan con estos casos de uso.
Área. En este trabajo, nos referimos con área a la Gerencia de Informática de la D.G.O.B.C..
Artefacto. Los artefactos son productos de trabajo intermedios o finales que se producen y
se utilizan durante un proyecto. Los artefactos se usan para capturar y difundir la
información del proyecto. Un artefacto puede ser:
Un documento. Por ejemplo, el documento de Visión.
Un modelo. Como el Modelo de Casos de Uso o el Modelo de Diseño.
Un elemento del modelo. Como una clase, o un subsistema.
Arquitectura. Es la serie de decisiones técnicas significativas que definen en su conjunto

una aproximación básica al sistema que solucionará un problema. Abarca las siguientes
características:
Estructura de alto nivel del sistema. Incluyendo su descomposición en subsistemas y las
interfaces de cada uno.
Coordinación de recursos globales.
Condiciones de entorno.
Concurrencia inherente.
Administración de datos.
Implementación del control de software.
Cada elemento debe comportarse de acuerdo a la especificación de las colaboraciones con
otros elementos.
Incorporación de patrones predefinidos o reutilización de elementos existentes.
Atributo. Una propiedad con nombre de un clasificador que describe el rango de valores
que las instancias de una propiedad pueden tomar.
Caso de uso. Una descripción detallada de un conjunto de secuencias de acciones,

incluyendo variaciones, que un sistema lleva a cabo y que conduce a un resultado
observable de interés para un actor determinado.
Casos de prueba. Descripción detallada de los datos y condiciones que el ingeniero de

Pruebas emplea para evaluar el funcionamiento del Sistema.
Componente. Una parte física y reemplazable de un sistema que se ajusta a, y proporciona

la realización de, un conjunto de interfases.
DGOBC. Dirección General de Operaciones de Banca Central.
Disciplina. Colección de actividades relacionadas entre sí que a su vez se relacionan con un

objetivo de interés de mayor relevancia.
Gerencia. En este trabajo, nos referimos con área a la Gerencia de Informática de la

D.G.O.B.C..
214
Requerimiento. Cualquier necesidad de un área usuaria que debe cubrirse mediante una
solución de tipo informático.
Rol. Descripción de las responsabilidades y actividades que una persona o grupo de

personas deben observar para cumplir un objetivo dentro de un proceso.
Servicios de informática. El desarrollo, mantenimiento y soporte de los sistemas y equipos

de cómputo.
NOTACIÓN.
Define los íconos empleados en la descripción gráfica de los flujos de trabajo (workflows) y
su descripción general.
Punto de Inicio Punto de Fin
Barra de Sincronización Documento
Actividad de alto nivel Expediente
Decisión Sistema
Rol Primario Estadística
Rol de Apoyo Capacitación
Actividad Dirección del Flujo
215

TesisRUP ISORita

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TesisRUP ISORita

Uploaded by

Copyright:

Available Formats

Propuesta de Implantación del Sistema de Gestión ISO-9001:2000 para el proceso de Desarrollo del Software usando la

metodología del RUP.

Tesis para la obtención del grado de Maestro en Ingeniería de Calidad

Rita Maria Culebro Gómez

La información y las tecnologías de información son dos aspectos muy importantes en el

Así, el conjunto de actividades desarrolladas en el Banco puede esquematizarse como

Procurar la estabilidad del poder sistema de los sistemas de

Tecnologías de Información, es una actividad propia de soporte del Banco de México, y es

La Gerencia de Informática se encarga de mantener y desarrollar sistemas que apoyen el

Dentro de las normativas mayormente conocidas, que se pueden enfocar al proceso de

Dada la relevancia de los sistemas usados en el Banco, y la necesidad de un proceso de

Como se observa en la tabla de arriba, en la Gerencia se cumplen de forma parcial o no los

 Planes de trabajo estimado y de costos que son muy pocos certeros.

Se ha hecho referencia a esta situación en repetidas ocasiones como la “crisis del

Es simple, si no satisfacemos a nuestros clientes, nos quedamos sin negocio. Actualmente,

b) Realizar un ejercicio de auditoria sobre el proceso de desarrollo de software con el

Se espera que la propuesta de implantación de este sistema de calidad se oriente a

Planteamiento del Problema:

Es importante proveer de un entendimiento básico de la norma ISO 9000:2000, sus

Las organizaciones que han implementado de manera conciente y profunda sistemas de

administración son ejemplos de bonos anticipados. Las organizaciones que se encuentran

De manera general, la estrategia seguida dada la situación mostrada en la Tabla 2, fue:

 Planeación de las actividades a realizar con base a los resultados obtenidos

Este trabajo aborda en el Capítulo I, La importancia de los sistemas en la Gerencia de

Capítulo I. LA IMPORTANCIA DE LOS SISTEMAS

1.3 Importancia de los sistemas

Capítulo II. LA CALIDAD Y EL PROCESO DE DESARROLLO DE SOFTWARE CON RUP.

EL PROCESO DE DESARROLLO DE SOFTWARE.

2.1 Definiciones de Calidad.

Calidad: Definición según ISO 9000:2000

2.2 Los sistemas informáticos en el Banco de México.

En los últimos años, el Banco ha promovido la realización de sus funciones en un contexto

En particular, las estrategias de desarrollo de sistemas en el Banco, están orientadas a la

2.3 El desarrollo de sistemas de forma general.

2.4 Problemáticas y aspectos relevantes de los sistemas de software

La seguridad de la operación de la Institución es una prioridad absoluta. Existe un grado

Como se mencionó anteriormente, el problema principal, es que se desarrollaron sistemas

2.5 Tendencias actuales en el proceso de desarrollo de software. El

El proceso unificado de Rational, es un proceso de ingeniería de software. Proporciona un

2.3.2 Introducción al RUP.

Las características principales de RUP son:

 Dirigido por casos de uso

Figura 2..1. Diagrama del RUP.

De las características principales mencionadas anteriormente, no debemos olvidar las

 Desarrollo basado en componentes.

 Uso del Lenguaje Unificado de Modelado

Un artefacto o llamado también producto, es aquella información que es producida,

Figura 2.2. Roles, Actividades y Artefactos en RUP.

2.3.3 La vida del Proceso Unificado.

Inicio Elaboración Construcción Transición

Iteración Iteración Iteración Iteración

Figura 2.3. Un ciclo con sus fases e iteraciones.

2.3.4 Fases del RUP.

A continuación, se describirán brevemente cada una de las fases.

Los objetivos son:

Los productos a generar deben ser:

Los objetivos son:

Al finalizar esta fase, se tendrán los siguientes productos:

Los citerior de evaluación son los siguientes:

Los objetivos son:

Al finalizar esta fase, se tendrán los siguientes productos:

iv) Plan de proyecto para la fase de Transición.

Al finalizar esta fase, se tendrán los siguientes productos: