Universidad Iberoamericana · Web viewMS Word Modelo de Caso de Uso (cat) Negociable 50% 100% Opcional Rational Rose Prototipo de Interfaz de Usuario Opcional 30% 100% Opcional A

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 metodología del RUP.

0Ing. 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............................................................................................................................121.1 Historia...............................................................................................................................................121.2 Organigrama del Banco de México....................................................................................................141.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.................................................................................202.1 Definiciones de Calidad......................................................................................................................202.2 Los sistemas informáticos en el Banco de México.............................................................................212.3 El desarrollo de sistemas de forma general.......................................................................................222.4 Problemáticas y aspectos relevantes de los sistemas de software usados en el Banco de México....232.5 Tendencias actuales en el proceso de desarrollo de software. El proceso unificado........................242.6 El proceso de desarrollo de software en la Gerencia de Informática................................................31

CAPÍTULO III. NORMAS, VOLUNTARIA Y OBLIGATORIA..............................................................87

ISO 9000........................................................................................................................................................873.1 Antecedentes de ISO 9000..................................................................................................................873.2 La norma ISO 9001:2000...................................................................................................................883.3 Requisitos Generales........................................................................................................................1013.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................................................................1074.1 Presentación del caso.......................................................................................................................1074.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...........................................................................1505.1 Implantación del sistema..................................................................................................................1505.2 Estrategia de implementación propuesta.........................................................................................1515.3 Propuesta de implementación...........................................................................................................1515.4 Recomendaciones de ISO 9000-3 para el proceso de desarrollo de software.................................1615.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



INTRODUCCIÓN



Antecedentes y JustificaciónLa 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:

Proveer a la economía del país de moneda nacional

Promover el sano desarrollo del

Propiciar el buen funcionamiento


Derivadas de la Ley

De Soporte


sistema financiero

de los sistemas de pagos

Procurar la estabilidad del poder adquisitivo de la moneda

Tecnologías de informaciónRecursos humanos

Recursos materialesControl contable y presupuestal

Servicios jurídicosSeguridad

ContraloríaRelaciones 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 calidad básicos, en los cuales está fundada la norma, para así encontrar los focos rojos, obteniendo los siguientes resultados:

PUNTOS PRINCIPALES CONTRIBUCIÓN AL PROCESO DE DESARROLLO DE SOFTWARE:SE OBSERVAN EN EL

PROCESOSÍ NO PARCIAL

Organización enfocada al cliente.

Es necesario enfocar nuestros procesos al cliente. Debemos adquirir la cultura de servicio, orientando nuestro proceso de desarrollo a la optimización de tiempos. Para lo cual es necesario controlar los requerimientos de nuestros clientes, generando formatos que 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.

X

Liderazgo.Es necesario que el personal adquiera el compromiso del cliente y se torne en un elemento especializado. Es necesario esclarecer la misión, metas y objetivos del área, y que se conviertan en las del personal.

X

Involucramiento del personal

Para poder lograr el punto anterior, debemos hacer que el personal se sienta parte del proyecto, que sea consciente del beneficio que trae consigo llevar el control de los proyectos.Se deberán establecer las habilidades del personal en beneficio del desarrollo de software.

X

Enfoque al proceso

Con el fin de obtener un control mayor del desarrollo de software., se deberá evaluar y dado el caso rediseñar la metodología de desarrollo de 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.

X

Enfoque de sistema para la gestión

Es orientar el sistema a la administración (aprovechamiento de recursos), para lo cual debemos identificar los procesos que se relacionan con el proceso de desarrollo de sistemas, de tal forma que entendamos cómo 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.

X

Mejora ContinuaEs necesario generar reportes que reflejen la satisfacción de nuestros clientes para que en base a ellos podamos ir organizando el ciclo de mejora continua.

X

Enfoque Objetivo para la toma de decisiones

Es necesario basarnos en hechos para la toma de decisiones, por lo que es requisito indispensable contar con un sistema que nos proporcione información confiable sobre las actividades del personal involucrado en el desarrollo de sistemas.Se deberá dar seguimiento a los proyectos con la finalidad de contar con información actualizada.

X

Relaciones benéficas con proveedores

Se deberá crear una relación de ganar-ganar con proveedores de tal forma que tanto los desarrolladores como los clientes ganen en el proceso del desarrollo de sistemas.Programadores: Menos tiempos de retrabajos por falta de especificaciones a detalle.Clientes: Tiempos de promesa de entrega verídicos.

X

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:

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:1 MILLS, EVERALD E., Software Metrics, Software Engineering Institute, SEI-CM-12-1.1 (1998).



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

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 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 desarrollo de software.

Evaluación mediante un cheklist, de los resultados obtenidos de la auditoria (Ver Anexo 2).

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.



CAPÍTULO ILA IMPORTANCIA DE LOS SISTEMAS



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.



CAPÍTULO IILA CALIDAD Y EL PROCESO DE DESARROLLO DE SOFTWARE CON 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



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.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


Rita Maria Culebro Gónzalez, 03/01/-1,

Investigar más sobre este respecto


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, 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.

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 usoLa 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 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 arquitecturaLa 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 incrementalPara 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.



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 ModeladoCon 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 integradoPara 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é?.



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.

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.

Iteración#1 ...…Iteración

#2... ... Iteración#n-1...... Iteración

#n...

Inicio Elaboración TransiciónConstrucción

Versiones

Tiempo

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.


Roles

Actividad

Artefacto/Producto


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.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.



Al finalizar esta fase, se tendrán los siguientes productos: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.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.

Al finalizar esta fase, se tendrán los siguientes productos: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.



Requeri -mientos

Análisis yDiseño

Pruebas

Adminis-tración deproyectos

Ambiente

Proceso de Desarrollo

Disciplinas

Procesos de Apoyo

Disciplinas

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 Desarrollo1. 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 involucradosEstablecer y formalizar las fronteras del desarrollo o proyectoConsiderar 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 TrabajoDiagrama Principal



Figura 2.5. Diagrama principal de la disciplina Administración de requerimientos.



Diagramas específicos

Figura 2.6. Diagrama de la actividad Analizar el problema.



Analizar el problemaEl 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 FaseAnalista -Ingeniero de Requerimientos

Identificar Requerimientos para VisiónEl objetivo de esta tarea es la de establecer las 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.

IncepcionElaboration

Analista -Ingeniero de Requerimientos

Detectar Actores y Casos de UsoEl objetivo de esta tarea es evaluar a los actores y casos de uso que se van detectando e ir evaluando su agrupación.



Capturar GlosarioEl objetivo de esta tarea es la de comenzar a 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.



Desarrollar Plan de Administración de RequerimientosEsta 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.



Figura 2.7. Diagrama de la actividad Entender las necesidades del usuario.



Entender las necesidades del usuarioEl propósito de esta actividad es: levantar la información del proyecto con los usuarios con la finalidad de entender sus necesidades reales Documentar la información recolectada


Levantar necesidades con el usuarioEsta tarea consiste en evaluar los perfiles de los usuarios y decidir 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”.



Desarrollar VisiónEl objetivo de esta tarea es ir desarrollando paulatinamente el documento de Visión conforme se vayan levantando los requerimientos.



Generar Survey de Casos de UsoEsta tarea consiste en generar el Survey de Casos de Uso con la información que actualmente se encuentra levantada.



Construir el Modelo InicialEsta tarea consiste en desarrollar el modelo inicial del sistema, basado en el Survey de Casos de Uso dentro de Racional Rose.



Desarrollar Especificaciones SuplementariasEsta tarea consiste en documentar y generar las especificaciones suplementarias que se vayan generando.



Administrar DependenciasEsta tarea consiste en la creación y/o actualización del repositorio 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.



Figura 2.8. Diagrama de la actividad Definir el sistema.



Definir el Sistema

El propósito de esta actividad es:

realizar el análisis de alto nivel de los requerimientos levantadosintegrar a las disciplinas participantes Poner a disposición de las mismas la información generada


Refinar el GlosarioEL Glosario generado deberá actualizarse permanentemente. En esta tarea el Glosario podrá ser sometido a revisión por los usuarios.



Refinar el Survey de Casos de UsoEsta tarea consiste en refinar el Survey de Casos de Uso conforme se vayan levantando los requerimientos.



Refinar el Documento de VisiónEl objetivo de esta tarea refinar paulatinamente el documento de Visión conforme se vayan levantando los requerimientos.


Refinar ModeloEl objetivo de esta tarea es la de refinar el modelo e ir integrando a la Disciplina de Arquitectura.


Delegar y Administrar DependenciasEl repositorio del Racional Requisite Pro deberá contar con la información actualizada y deberá ser puesta a disposición entre los participantes del proyecto.


Tabla 2.3. Detalles del rol, tarea y fase de la actividad definir el sistema.



Figura 2.9. Diagrama de la actividad Administrar el alcance.



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.


Priorizar Casos de UsoEl objetivo de esta tarea es establecer la priorización de Casos de Uso sugerida por la disciplina de Requerimientos 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.



Actualizar DependenciasEl objetivo de esta tarea es la de actualizar a todas las disciplinas necesarias sobre la priorización de los casos de uso.


Arquitecto de Software Actualizar ArtefactosEl objetivo de esta tarea es la de actualizar todos los artefactos generados con base en la priorización de requerimientos establecida.


Tabla 2.4. Detalles del rol, tarea y fase de la actividad administrar el alcance.



Figura 2.10. Diagrama de la actividad Redefinir el sistema.



Redefinir el Sistema


Describir el flujo de eventos de las Especificaciones de Casos de Uso en detalleDetallar las especificaciones suplementariasDesarrollar el documento de Especificación de Requerimientos de Software Modelar el prototipo y/o la interfaz del usuario

Rol/Responsable Tarea FaseEspecificador de Casos de Uso – Ingeniero de Requerimientos

Detallar Casos de UsoEl objetivo de esta tarea es la de detallar los flujos básicos y alternos de cada uno de los Casos de Uso identificados de manera formal.


Especificador de Casos de Uso – Ingeniero de Requerimientos

Detallar Especificación SuplementariasEl objetivo de esta tarea es la de detallar de manera puntual las especificaciones suplementarias previamente identificadas. El detalle de las mismas deber evitar ambigüedades.



Desarrollar Especificación de Requerimientos de SoftwareEl objetivo de esta tarea es la de empezar la construcción del documento de Especificación de requerimientos de Software que formalizará el desarrollo de la disciplina dentro del proyecto.


Diseñador – Ingeniero de Requerimientos

Modelar la Interfaz del UsuarioEsta tarea tiene como finalidad la construcción del prototipo y/o modelado de la interfaz de usuario.


Tabla 2.5. Detalles del rol, tarea y fase de la actividad redefinir el sistema.



Figura 2.11. Diagrama de la actividad Administrar cambios en requerimientos.



Administrar Cambios en los Requerimientos


Administrar y dar seguimiento a las solicitudes de cambioReestructurar el modelo de Casos de Uso basados en esas solicitudesAdministrar los atributos y traceabilidad necesaria en el repositorio de Racional Requisite Pro


Someter a Revisión y obtener retroalimentación sobre los artefactos generadosTodos 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 Requerimientos

Actualizar ArtefactosEl resultado generado como parte de la Administración de Requerimientos podrá considerar la actualización de artefactos que se vean impactados.

IncepcionElaborationConstruction


Administrar DependenciasEl resultado generado como parte de la Administración de Requerimientos podrá considerar la actualización de los repositorios de información tanto de solicitudes de cambios como de la administración de los requerimientos.

IncepcionElaborationConstruction

Tabla 2.6. Detalles del rol, tarea y fase de la actividad administrar cambios en los requerimientos.



Artefactos

Artefactos Clasificación

Cómo Utilizarlos(Por Fase)

Aprobación Formal

Herramientas Utilizadas

I E C T

Glosario Obligatorio 30% 100% Negociable Requisite ProMS Word

Plan de Administración de Requerimientos

Obligatorio 100% Negociable Requisite ProMS Word

Visión Obligatorio 100% Obligatorio Requisite ProMS Word

Survey de Casos de Uso

Obligatorio 80% 100% Obligatorio Requisite ProMS Word

Especificación de Casos de Uso

Obligatorio 40% 100% Obligatorio Requisite ProMS Word

Especificaciones Suplementarias

Obligatorio 50% 80% 100% Obligatorio Requisite ProMS Word

Modelo de Caso de Uso (cat)

Negociable 50% 100% Opcional Rational Rose

Prototipo de Interfaz de Usuario

Opcional 30% 100% Opcional A elegir

Especificación de Requerimientos de Software

Obligatorio 50% 80% 100% Obligatorio Microsoft WordSODA para Word

Plan de Actividades por Iteración

Negociable Negociable MS Project

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 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

Reportes Clasificación Herramientas Utilizadas

Rol Responsable

Actores Opcional SODACasos de Uso Opcional SODASurvey de Casos de Uso Obligatorio SODA

Tabla 2.8. Reportes usados en requerimientos.



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 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.


Figura 2.12. Diagrama principal de la disciplina Análisis y Diseño.


Definir una Arquitectura Candidata


Definir arquitectura candidata

Analizar el comportamiento del sistema

Refinar la Arquitectura

Diseñar la Base de Datos

Diseñar Componentes

Fin


Figura 2.13. Diagrama de la actividad Definir una arquitectura candidata.

Actividades/Tareas

Rol Responsable Descripción de la ActividadArquitecto Crear un bosquejo inicial de la arquitectura

Modelar una primera aproximación de la arquitectura del sistema. Definir elementos significativos de la arquitecturaSe definen los conceptos esenciales que manejará el sistema así como sus relaciones obteniendo un conjunto de clases preliminares. Definir organización del sistemaSe 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


Crear un bosquejo inicial de la arquitectura

Definir elementos significativos

Definir la organización del Sist.

Visión

Arquitecto

Doc. de arquitectura


|

Figura 2.14. Diagrama de la actividad Analizar el comportamiento del sistema.

Actividades/Tareas

Rol Responsable Descripción de la ActividadArquitecto / Diseñador

Analizar casos de usoIdentificar 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álisisSe 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ñoSe 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álisisSe 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 usoPara 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.


Análisis de CU

Definir mecanismos de análisis

Identificar clases de análisis

Identificar elementos de diseño Definir

realizaciones de CU

Arquitecto / Diseñador

Survey de CU

Mod. de Diseño

Visión Realizaciones de CU

Esp. de CU


Refinar la arquitectura

Figura 2.15. Diagrama de la actividad Refinar la arquitectura.

Actividades/Tareas

Rol Responsable Descripción de la ActividadDiseñ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ñoSe 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 existentesSi 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 arquitecturaSe 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


Priorizar CU

Mantener la consistencia e integridad de la Arquitectura

Describir la distribución del Sistema

Survey de CU

Doc. de Arquitectura (refinado)

Transición de las act. de análisis a act. de diseño

Incorporar elementos de diseño existentes

Diseñador

Esp. Suplementarias

Vista de Distribución

Esp. de CU

Desarrollar el modelo de implementación

Mod. de Clases (refinado)


Se propone la distribución física de los procesos y componentes en cada nodo del sistema.Desarrollar el modelo de implementaciónSe 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

Figura 2.16. Diagrama de la actividad Diseño de componentes.

Actividades/Tareas

Rol Responsable Descripción de la ActividadDiseñ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 usoSe 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 subsistemasSe agrupan los componentes obtenidos de acuerdo a su funcionalidad en subsistemas.Diseñar el modelo de componentes


Refinar elementos de diseño

Refinar y actualizar realizaciones de CU

Implementación de componentes

Mod. de Clases

Vista de Componentes

Diseño de Subsistemas

Diseñar el modelo de componentes

Diseñador

Doc. de Arquitectura

Doc. de Arquitectura (refinado)

Modelo del sistema


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. Implementación de componentesA 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

Figura 2.17. Diagrama de la actividad Diseño de base de datos.

Actividades/Tareas

Rol Responsable Descripción de la ActividadDiseñ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 DatosCon base a las clases persistentes se propone la estructura de la base de datos del sistema.Definir mecanismos y estrategias para acceder los datos persistentesDespué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


Identificar clases persistentes

Diseñar la estructura de la BD

Definir mecanismos y estrategias para acceder los datos persistentes



Diseñador

Mod. de Clases

Mod. de Datos


Revisión de Detalles


Rol Responsable

Incep

Elab Const

Trans

Documento de Arquitectura de Software (Software Arquitecture Document)

10% 70% 90% 100%

Interno Formal

MsWord Arquitecto de Software

Modelo del Sistema10% 70% 90% 100

%Interno Formal

Rational Rose

Arquitecto de Software

Tabla 2.14. Artefactos generados en análisis y diseño.

Notas sobre los Artefactos

Artefactos Cómo Utilizarlos Razón

Documento de Arquitectura de Software

En Word

Este documento es un reporte del modelo, proporciona una descripción arquitectónica comprensiva del sistema, usando diversas vistas de la arquitectura para representar diferentes aspectos del sistema.

Modelo del sistema

En Rational Rose

El modelo del sistema proporciona una descripción a detalle del sistema, casos de uso, subsistemas, clases, componentes, etc. y la forma en que éstos están relacionados.

Tabla 2.15. Notas sobre los artefactos usados en análisis y diseño.

3. Pruebas

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 tiempo.



Fin

[Definir la Misión de las Pruebas

Seleccionar otra técnica

Probar y Evaluar Lograr la misión establecida

Mejorar los activos de pruebas]

Iniciar otro ciclo de prueba

Inicio

Verificar el alcance de la prueba]

Verificar la estabilidad del sistema


Figura 2.18. Diagrama principal de la disciplina de Pruebas.




Modelo de Caso de Uso

Definir la Misión de las Pruebas

Documento de Arquitectura

Modelo del Sistema Lista de Ideas de Pruebas

Ingeniero de Pruebas

Plan de Pruebas

Identificar motivadores de pruebas

Establecer la Misión

Vision

Plan de Iteración

Plan de Desarrollo de Software


Definir el alcance de las pruebas

Definir objetivos

de pruebas

Identificar ideas de pruebas

Figura 2.19. Diagrama de la actividad Definri la misión de pruebas.

Actividades/Tareas

Rol Responsable Descripción de la ActividadIngeniero de pruebas

Identificar Motivadores de PruebasEn 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ónEn 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 PruebasDefinir los objetivos de pruebasEn esta parte se especificarán más a detalle, puntos



objetivos que serán sujetos a evaluaciones por parte del 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 pruebasCon 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 PruebasCon 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.



IImplementar Suite de Pruebas

Ambiente de pruebas Caso de Prueba

Implementar Prueba

Definir los detalles de las pruebas

Guías de Pruebas

IIngeniero de Pruebas

Definir el ambiente de pruebas

Definir la Testabilidad de los elementos

Plan de Pruebas Ideas de Pruebas

Suite de Pruebas

Script de Pruebas

Script de Pruebas

Verificar el alcance de la prueba

Figura 2.20. Diagrama de la actividad Verificar el alcance de la prueba.


Definir los detalles de las pruebasDe 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:ObjetivoTécnica o método de realización Herramientas necesarias



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 pruebasEn 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 elementosEn 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 PruebaCon 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 pruebasDespué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.




Determinar resultados de pruebas

Ejecutar suite de pruebas

Solicitud de Cambio


Implementar Prueba Analizar fallas detectadas

Ideas de Pruebas

Resultados de las pruebas

Ejecutable

Suite de Pruebas

Caso de prueba Solicitud de Cambio

Log de Pruebas

Resumen de evaluación

de las pruebas

Validar la estabilidad del sistema

Figura 2.21. Diagrama de la actividad Validar la estabilidad del sistema.


Implementar pruebaEstá 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 pruebasEsta 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 .

Analizar fallas detectadasCon 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 pruebasCon 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 pruebasSe 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..





Ejecutar suite de pruebas


Implementar Prueba Analizar fallas detectadas

Ideas de Pruebas


Ejecutable

Suite de Pruebas

Caso de prueba Datos de entrada

Log de Pruebas

Resumen de evaluación

de las pruebas

Implementar suite de pruebas

Script de Prueba

Solicitud de Cambio

Ambiente de pruebas Solicitud de Cambio

Identificar ideas de pruebas Verificar cambios

en el ejecutable

Definir los Elementos a probar

Script de Prueba

Ideas de Pruebas

Solicitud de Cambio

Solicitud de Cambio

Probar y Evaluar

Figura 2.22. Diagrama de la actividad Probar y evaluar.


Implementar pruebaDe 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.




Tras analizar los resultados obtenidos se revisarán los scripts de pruebas, y se decidirá si son susceptibles de mejora en cuanto a sus características de ejecución y objetivosEjecutar suite de pruebasSe 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.

Analizar fallas detectadasCon el Log de resultados obtenido anteriormente, se analizarán y evaluarán los resultados en base a los 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 pruebasCon 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 probarSe 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.Definir los detalles de las pruebasCon 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 ejecutableDe 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 pruebasCon 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.



Implementar prueba


Identificar Ideas de pruebas

Solicitud de Cambio


Verificar el alcance Obtenido de las

pruebas

Verificar el alcance de la calidad

Ideas de Pruebas


Analizar fallas detectadas

Solicitud de Cambio

Resumen de evaluación de las pruebas

Log de Pruebas

Implementar Suite prueba

Log de Pruebas

Lograr la misión establecida

Figura 2.23. Diagrama de la actividad Logra la misión establecida.


Verificar el alcance obtenido de las pruebasCon 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.

Verificar el alcance de la calidadCon 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 pruebasCon 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 pruebasCon los resultados obtenidos durante el proyecto se revisará la lista de ideas de pruebas, para mejorarla o retroalimentarla.Implementar pruebaCon 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.Implementar suite de pruebasSe revisarán las suites de pruebas para mejorarlas. Posteriormente se ejecutarán y generarán nuevos resultados y Log de pruebas. Analizar fallas detectadasCon el Log de resultados obtenido anteriormente, se analizarán y evaluarán los resultados en base a los 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.




Implementar pruebas

Desarrollar la implementación

de la prueba IIngeniero de

Pruebas Desarrollar Guías

de Prueba Definir los elementos

a probar

Guías de Pruebas

Datos de entrada

Suite de Pruebas

Identificar ideas de pruebas

Definir detalles de

pruebas Definir rastreabilidad

de necesidades

Resumen de evaluación de las pruebas

Guías de Pruebas

(Catálogo de Ideas de Pruebas)

Plan de pruebas

Script de pruebas

Ambiente de pruebas

Script de pruebas

Mejorar los activos de pruebas

Figura 2.24. Diagrama de la actividad Mejorar los activos de pruebas.


Desarrollar implementación de la pruebaCon 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 pruebasEstá 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 obtendrá una guía que apoye en el futuro en la implementación de pruebas.Definir los elementos a probarCon 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.Implementar suite de pruebasCon 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 pruebasCon 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 pruebasPartiendo 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.Definir los detalles de las pruebasCon 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 necesidadesCon 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 de Detalles


Rol Responsable

Incep

Elab Const

Trans

Plan de Pruebas (Test Plan)

80% 100% 100%

Externo-Formal

Micosoft Word

Ingeniero de pruebas

Casos de Prueba (Test Case) 30% 95% 100

%

Interno-Formal

MS Word y Rational Test

Ingeniero de pruebas



ManagerScripts de Pruebas (TestScripts)

10% 70% 100%

Interno- Formal

Robot, TestManager


Resúmen de Evaluación de la Prueba (Test Evaluation Summary)

100% 100%

Interno- Formal

MS Word Ingeniero de Pruebas

Tabla 2.22. Artefactos generados en pruebas.



Registro de Pruebas (TestLog)

Se genera automáticamente al ejecutar scripts automáticos y manuales. Manejo interno para generación del Resumen de Evaluación de la prueba

Lista de Ideas (Test Ideas List)

Manejo interno para la generación de algunos casos de prueba. No se generarán catálogos de Ideas de prueba por ser proyecto de implementación.

Modelo de Análisis de Carga (Workload Analysis Model)

No se aplica

Datos de Prueba (TestData)

Requeridos para los casos de prueba. Su manejo y revisiones son internos

Resultados de la Prueba (TestResults)

Se genera automáticamente al ejecutar scripts automáticos y manuales. Manejo interno para generación del Resumen de Evaluación de la prueba

Arquitectura de Automatización de Pruebas (TestResults)

No aplica

Especificación de Intgerfaz de Pruebas (Test Interface Specification)

No aplica

Configuración del Ambiente de Pruebas (Test Enviroment Configuration)

No aplica



Suite de Pruebas (TestSuite)

Su manejo será ocasional y de revisión interna informal. Util para pruebas de regresión pero de poco uso en un proyecto de implementación.

Tabla 2.23. Notas sobre los artefactos generados en pruebas.

ReportesReportes Cómo

UtilizarlosHerramientas Utilizadas

Plantilas/Ejemplos

Reportes de Cobertura de Casos de Prueba

TestManager, SoDA, Seagate Crystal Reports

No Aplica

Tabla 2.24. Reportes generados en pruebas.

Notas sobre los ReportesLos 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 Apoyo4. 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.



Flujo de Trabajo

Diagrama Principal

Figura 2.25. Diagrama principal de la disciplina Administración de proyectos.


Concebir un nuevo Proyecto



Figura 2.26. Diagrama de la actividad Concebir un nuevo proyecto.

Actividades/Tareas

Rol Responsable Descripción de la ActividadAdministrador del Proyecto

Recepción del RequerimientoSe establece la necesidad de un nuevo sistema o modificación mayor a un sistema existente.Asignar al Equipo de RequerimientosSe 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 riesgosSe 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 del ProyectoGerente del AreaDirector del Area

Aprobar del ProyectoUtilizando el análisis de requerimientos inicial, se determina la factibilidad del proyecto aprobándose su desarrollo o por el contrario se determina su inviabilidad y se cancela la solicitud.

Administrador del Proyecto

Iniciar del ProyectoUna 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.



Administrar la Iteración

Figura 2.27. Diagrama de la actividad Administrar la iteración.

Actividades/Tareas


Asignar al personalSe 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ónSe dan a conocer los planes y objetivos de la iteración.Identificar y evaluar riesgosSe 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ónSe 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.



Desarrollar el Plan de Administración de Software

Figura 2.28. Diagrama de la actividad Desarrollar elplan de administración de software.

Actividades/Tareas


Planificar Fases e IteracionesSe 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étricasSe 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 ProductoConforme 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.



Planear la Iteración siguiente

Figura 2.29. Diagrama de la actividad Planear la iteración siguiente.

Actividades/Tareas


Reunir los planes detallados por disciplinaSe solicita a los equipos de cada disciplina desarrollen un plan detallado para sus actividades.Compilar el plan de la iteraciónA 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.



Cierre de Fase

Figura 2.30. Diagrama de la actividad Cierre de fase.

Actividades/Tareas


Reunir los reportes de avance por disciplinaSe establece conjuntamente con los demás participantes en el proyecto, el estado actual de cada disciplina.Presentar el estado del proyectoSe 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.



Cierre de Proyecto

Figura 2.31. Diagrama de la actividad Cierre de proyecto.

Actividades/Tareas


Reunir los reportes de resultados por disciplinaSe 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 proyectoSe 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.



Monitorear y Controlar el Proyecto

Figura 2.31. Diagrama de la actividad Monitorear y controlar el proyecto.

Actividades/Tareas


Monitorear el estado del ProyectoSe 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 proyectoSe 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ón de Detalles


Rol ResponsableInce

pElab Cons

tTrans

Plan de Desarrollo de Software (Software Development Plan )

30 %

80% 90% 100% Extern

o Formal

MS Word Adminitrador del Proyecto



Plan de Iteración (Iteration Plan)

Se construye un plan por cada iteración durante todas las fases

Interno Formal

MS Project Adminitrador del Proyecto

Evaluación de las Iteraciones (Iteration Assessment)

Se construye una evaluación por cada iteración durante todas las fases

Interno Formal


Lista de Riesgos (Risk List)

40% 80% 90% 100% Interno Fromal


Plan de comunicación

80% 100%

✓ ✓ Externo Formal


Plan de Métricas del Proyecto (Project Measurements)

10% 80% 90% 100% Interno Fromal


Plan de Aceptación del Producto

10% 80% 90% 100% Externo Formal


Evaluación del Estado del Proyecto (Status Assessment)

Se construirá uno diferente al final de cada fase

Adminitrador del Proyecto

Tabla 2.32. Artefactos generados en administración del proyecto.



Plan de Iteración

En MS Project

El uso de MS Project permite a todos los participantes calendarizar sus tareas, haciendo innecesario el fromato RUP de Plan de Iteración.

Evaluación del Estado del Proyecto

En Power Point

En este proyecto no es práctico el uso de un documento con este fin. Se sustituye por el Reporte de Fin de Fase.

Tabla 2.33. Notas sobre los artefactos generados en la administración del proyecto.



Reportes

Reportes Cómo Utilizarlos


Plantillas/Ejemplos

Fin de faseFormato Presentación a la Gerencia y la Dirección

Power Point No aplica

Tabla 2.34. Reportes generados en la administración de proyectos.

Notas sobre los ReportesAl 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 DisciplinaNo se realizarán las actividades siguientes:

Desarrollo del Plan de Administración de RiesgosDesarrollo del Plan de Resolución de ProblemasDesarrollo 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.



Flujo de Trabajo

Diagrama Principal

Preparar Ambiente para elProyecto

Preparar Ambientepara la iteracion

Preparar guías para laiteración

Soporte al Ambientedurante la iteración

[Durante la iteración deInception]

Figura 2.32. Diagrama principal de la disciplina de Ambiente.




Ingeniero delProceso

Desarrollar el Casode Desarrollo

Preparar Ambiente

Construir el SitioWeb

Proponer lasPlantillas

Caso deDesarrollo

Plantillas

Figura 2.33. Diagrama de la actividad Preparar ambiente.

Actividades/Tareas

Rol Responsable Descripción de la ActividadIngeniero del Proceso

Desarrollar el Caso de DesarrolloTrabajará 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ícoProponer las plantillasRecopilará las plantillas que se utilizarán durante el proceso de desarrollo de sistemas.Construir el sitio webConsiderando 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.



Figura 2.34. Diagrama de la actividad Preparar ambiente para la iteración.

Actividades/Tareas

Rol Responsable Descripción de la ActividadIngeniero del Proceso

Refinar el Caso de DesarrolloRealizará las mejoras necesarias durante el desarrollo del proyecto, atendiendo las peticiones hechas por los especialistas de cada disciplina.Actualizar las plantillasRealizará las mejoras requeridas en las plantillas incluyendo modificaciones de forma y fondo.Refinar el sitio webRealizará 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.



Figura 2.35. Diagrama de la actividad Preparar guías para la iteración.

Rol Responsable Descripción de la Actividad

Preparar guías para la iteraciónTrabajará 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.



CAPÍTULO IIINORMAS, VOLUNTARIA Y OBLIGATORIA.



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 mejoras4:

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.

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.



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).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.

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.



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, 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:

7 Walter Shewhart, Statistical Method from the Viewpoint of Quality Control, Dover publication, Inc., N.Y., 1986, pp.45,149.


Req

uerim

ient

os d

el

clie

nte

Satisfacción del clienteEntradas

Mejora Continua del sistema de

Calidad

Responsabilidad de la Dirección

Administración de Recursos

Realización del Producto

Medición, Análisis y Mejora

Producto o Servicio

ResultadosReq

uerim

ient

os d

el

clie

nte

Satisfacción del clienteEntradas

Mejora Continua del sistema de

Calidad

Responsabilidad de la Dirección

Administración de Recursos

Realización del Producto

Medición, Análisis y Mejora

Producto o Servicio

Resultados


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 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:19941 Objeto y campo de aplicación 11.1 Generalidades1.2 Aplicación 2 Referencias normativas 23 Términos y definiciones 34 Sistema de gestión de la calidad4.1 Requisitos generales 4.2.14.2 Requisitos de la documentación4.2.1 Generalidades4.2.2 Manual de calidad

4.2.24.2.1

4.2.3 Control de los documentos4.2.4 Control de los registros de calidad

4.5.1+4.5.2+4.5.34.16

5 Responsabilidad de 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



5.1 Compromiso de la dirección 4.1.15.2 Enfoque al cliente 4.3.25.3 Política de la calidad5.4 Planificación 5.4.1 Objetivos de la calidad5.4.2 Planificación del sistema de gestión de la calidad5.5 Responsabilidad, autoridad y comunicación5.5.1 Responsabilidad y autoridad5.5.2 Representante de la dirección5.5.3 Comunicación interna

4.1.1

4.1.14.2.3

4.1.2.14.1.2.3

5.6 Revisión por la dirección5.6.1 Generalidades5.6.2 Información para la revisión5.6.3 Resultados de la revisión

4.1.3

6 Gestión de los recursos6.1 Provisión de recursos 4.1.2.26.2 Recursos humanos6.2.1 Generalidades6.2.2 Competencia, toma de conciencia y formación

4.1.2.24.18

6.3 Infraestructura 4.96.4 Ambiente de trabajo 4.97 Realización del producto7.1 Planificación de la realización del producto 4.2.3+4.10.17.2 Procesos relacionados con el cliente7.2.1 Determinación de los requisitos relacionados con el producto7.2.2 Revisión de los requisitos relacionados con el producto7.2.3 Comunicación con el cliente

4.3.2+4.4.44.3.2+4.3.3+4.3.44.3.2

7.3 Diseño y desarrollo7.3.1 Planificación del diseño y desarrollo7.3.2 Elementos de entrada para el diseño y desarrollo7.3.3 Resultados del diseño y desarrollo7.3.4 Revisión del diseño y desarrollo7.3.5 Verificación del diseño y desarrollo7.3.6 Validación del diseño y desarrollo7.3.7 Control de cambios del diseño y desarrollo

4.4.2+4.4.34.4.4

4.4.54.4.64.4.74.4.84.4.9

7.4 Compras7.4.1 Proceso de compras7.4.2 Información de las compras7.4.3 Verificación de los productos comprados

4.6.24.6.34.6.4+4.10.2

7.5 Producción y prestación del servicio7.5.1 Control de la producción y de la prestación del servicio7.5.2 Validación de los procesos de producción y de la prestación del servicio7.5.3 Identificación y trazabilidad7.5.4 Propiedad del cliente7.5.5 Preservación del producto

4.9+4.15.6+4.19

4.9

4.8+4.10.5+4.124.74.15.2+4.15.3+4.15.4+4.15.5

7.6 Control de los dispositivos de seguimiento y medición

4.11.1+4.11.2

8 Medida, análisis y mejora8.1 Generalidades 4.10+4.20.1+4.20.28.2 Seguimiento y medición8.2.1 Satisfacción del cliente8.2.2 Auditoría interna 4.17



8.2.3 Seguimiento y medición de los procesos8.2.4 Seguimiento y medición del producto8.3 Control del producto no conforme

4.17+4.20.1+4.20.24.10.2+4.103.+4.10.4+4.10.5+4.20+4.20.24.13.1+4.13.2

8.4 Análisis de datos 4.20.1+4.20.28.5 Mejora8.5.1 Mejora continua8.5.2 Acción correctiva8.5.3 Acción preventiva

4.1.34.14.1+4.14.24.14.1+4.14.3

Tabla 3.1. Tabla comparativa de los requisitos de la norma ISO 9001, versión 2000 y 1994.

Tabla comparativa ISO 9000-3 con ISO 9001:1994.

ISO 9000-3 ISO 9001:19944.1 Responsabilidad de la administración4.1.1 Responsabilidad de la administración de proveedores4.1.1.1 Política de calidad4.1.1.2 Organización 4.1.1.2.1 Responsabilidad y autoridad4.1.1.2.2 Verificación de recursos y personal4.1.1.2.3 Representante de la administración 4.1.1.3 Revisión de la administración4.1.2 Responsabilidad de la administración de compras4.1.3 Revisiones entre el proveedor y compras

4.1 Responsabilidad de la dirección4.1.1 Política de calidad4.1.2 Organización 4.1.2.2 Recursos4.1.2.3 Representante de la dirección 4.1.3 Revisión de la dirección

4.2 Sistema de calidad 4.2.1 General4.2.2 Documentación de sistema de calidad4.2.3 Plan de calidad

4.2 Sistema de calidad4.2.1 Generalidades4.2.2 Procedimientos del sistema de calidad4.2.3 Planeación de calidad

4.3 Auditorías internas al sistema de calidadDeterminar la efectividad del sistema de calidad.Auditorías y acciones de seguimiento.

4.17 Auditorías de calidad internas

4.4 Acciones correctivas 4.14 Acciones correctiva y preventiva 4.14.1 Generalidades4.14.2 Acción correctiva4.14.3 Acción preventiva

5.1 GeneralUn 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 contrato5.2.1 GeneralAlcance y requerimientos definidos y documentados.Identificación de riesgos.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

4.3 Revisión de contrato4.3.1 Generalidades4.3.2 Revisión4.3.3 Modificaciones al contrato4.3.4 Registros



5.2.2 Aspectos de calidadCriterios 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 comprador5.3.1 GeneralRequerimientos completos y no ambiguos.Desempeño, seguridad, confiabilidad y privacidad.5.3.2 Cooperación mutuaAsignar a una persona responsable por ambas partes.Método para acordar requerimientos y aprobación de cambios.Prevenir malos entendidos.Registrar y revisar resultados de discusiones.

4.3 Revisión del contrato4.3.1 Generalidades4.3.2 Revisión4.3.3 Modificaciones al contrato4.3.4 Registros4.4 Control de diseño4.4.1 Generalidades4.4.2 Planeación de diseño y desarrollo4.4.3 Interrelaciiones organizacionales y técnicas4.4.4 Datos de entrada del diseño4.4.5 Resultados del diseño4.4.6 Revisión del diseño4.4.7 Verificación del diseño4.4.8 Validación del diseño4.4.9 Cambios del diseño

5.4 Planeación de desarrollo5.4.1 GeneralDefinición del proyecto.Organización de los recursos (estructura, responsabilidades).Fases de desarrollo.Calendario de proyecto (tareas, recursos, tiempos).Identificación de planes relacionados. Plan de calidad, plan de configuración de la administración, plan de integración, plan de pruebas.5.4.2 Plan de desarrollo5.4.2.1 FasesTransformar 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ónPlan 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 herramientasReglas, prácticas y convenciones.Herramientas y técnicas de desarrollo.Administración de la configuración.5.4.3 Control de avance5.4.4 Entradas a las fases de desarrolloDefinidas y documentadas

4.4 Control de diseño4.4.1 Generalidades4.4.2 Planeación de diseño y desarrollo4.4.3 Interrelaciones organizacionales y técnicas4.4.4 Datos de entrada del diseño4.4.5 Resultados del diseño4.4.6 Revisión del diseño4.4.7 Verificación del diseño4.4.8 Validación del diseño4.4.9 Cambios del diseño



5.4.5 Salidas de las fases de desarrolloLograr los requerimientos relevantes.Criterios de aceptación.Funcionalidad.5.4.6 Verificación de cada faseRevisiones de desarrollo.Comparación de diseños.Pruebas y demostraciones.5.5 Plan de calidad5.5.1 General5.5.2 ContenidoObjetivos de calidad definidos en términos medibles.Criterios de entradas y salidas para cada fase.Tipos de pruebas, verificaciones y validaciones.Plan detallado de pruebas.Definición de responsabilidades, revisiones y pruebas, control de cambios, control de errores y acciones correctivas.

4.2 Sistema de calidad4.2.1 Generalidades4.2.2 Procedimientos del sistema de calidad4.2.3 Planeación de calidad4.4 Control de diseño4.4.1 Generalidades4.4.2 Planeación de diseño y desarrollo4.4.3 Interrelaciones organizacionales y técnicas4.4.4 Datos de entrada del diseño4.4.5 Resultados del diseño4.4.6 Revisión del diseño4.4.7 Verificación del diseño4.4.8 Validación del diseño4.4.9 Cambios del diseño

5.6 Diseño e implantación5.6.1 GeneralTransforma los requerimientos en un producto de software.5.6.2 DiseñoReglas de diseño y definición de interfases internas.Metodología de diseño.Uso de experiencias pasadas, lecciones aprendidas, evitar recurrencias del mismo o similar problema.Procesos subsecuentes, facilitar pruebas, mantenimiento y uso.5.6.3 ImplementaciónReglas de programación, lenguaes, consistencia de nombres, código.Metodología de implementación.Revisiones, registros.

4.4 Control de diseño4.4.1 Generalidades4.4.2 Planeación de diseño y desarrollo4.4.3 Interrelaciones organizacionales y técnicas4.4.4 Datos de entrada del diseño4.4.5 Resultados del diseño4.4.6 Revisión del diseño4.4.7 Verificación del diseño4.4.8 Validación del diseño4.4.9 Cambios del diseño4.13 Control de producto no conforme4.13.1 Generalidades4.13.2 Revisión y disposición de productos no conforme

5.7 Pruebas y validación 5.7.1 General5.7.2 Plan de pruebasPruebas unitarias, integración, sistema.Casos de prueba, datos de prueba y resultados esperados.Tipos de pruebas a desarrollar.Ambiente de pruebas, herramientas y software de pruebas.Criterios de aceptación.Documentación de usuario.Personal y capacitación requerida.5.7.3 PruebasRegistro de los resultados de las pruebas.Anotar cualquier problema y su impacto, para que el problema sea revisado hasta su solución.Cualquier modificación debe ser identificada y vuelta a probar, así como su impacto.Evaluar la relevancia de las pruebas.

4.4 Control de diseño4.4.1 Generalidades4.4.2 Planeación de diseño y desarrollo4.4.3 Interrelaciones organizacionales y ténicas4.4.4 Datos de entrada del diseño4.4.5 Resultados del diseño4.4.6 Revisión del diseño4.4.7 Verificación del diseño4.4.8 Validación del diseño4.4.9 Cambios del diseño4.10 Inspección y prueba4.10.1 Generalidades4.10.2 Inspección de prueba de recibo4.10.3 Inspección de prueba en proceso4.10.4 Inspección y pruebas finales4.10.5 Registros de inspección y prueba4.11 Control de equipo de inspección4.11.1 Generalidades4.11.2 Procedimientos de control



La configuración de hardware y software debe ser considerada y documentada.5.7.4 ValidaciónPrueba integral.5.7.5 Prueba de campos

4.13 Control de productos no conformes4.13.1 Generalidades4.13.2 Revisión y disposición de productos no conforme

5.8 Aceptación5.8.1 GeneralEl comprador debe juzgar el producto y deberá documentarse.5.8.2 Aceptación del plan de pruebasCalendario.Procedimientos para evaluación.Software y hardware de ambiente y recursos.Criterios de aceptación.

4.10 Inspección y prueba4.10.1 Generalidades4.10.2 Inspección y prueba de recibo4.10.3 Inspección y prueba en proceso4.10.4 Inspección y pruebas finales4.10.5 Registros de inspección y prueba4.15 Manejo de almacenamiento4.15.1 Generalidades4.15.2 Manejo4.15.3 Almacenamiento4.15.4 Empaque4.15.5 Conservación 4.15.6 Entrega

5.9 Réplica, entrega e instalación5.9.1 RéplicaNúmero de copias.Tipo de medio (formato, versión y forma de lectura).Documentación (manuales, guías).Aspectos de licencias.Custodia de copias de respaldo y original.5.9.2 EntregaCopias correctas y completas.5.9.3 InstalaciónCalendario, trabajo fuera de las horas normales y fines de semana.Acceso a instalaciones del cliente.Disponibilidad de personal con ciertas habilidades.Acceso a los sistemas y equipos del cliente.Validación de cada instalación (contractual).Procedimiento formal para aprobación de cada instalación terminada.

4.10 Inspección y prueba4.10.1 Generalidades4.10.2 Inspección y prueba de recibo4.10.3 Inspección y prueba en proceso4.10.4 Inspección y pruebas finales4.10.5 Registros de inspección y prueba4.13 Control de producto no conforme4.13.1 Generalidades4.13.2 Revisión y disposición de productos no conforme4.15 Manejo de almacebamiento, empaque, conservación y entrega4.15.1 Generalidades4.15.2 Manejo4.15.3 Almacenamiento4.15.4 Empaque4.15.5 Conservación4.15.6 Entrega

5.10 Mantenimiento 5.10.1 GeneralResolución de problema.Modificación de interfase.Expansión funcional o mejora de desempeño.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 actual5.10.4 Organizaciones de soporte5.10.5 Actividades de mantenimientoResolució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.

4.13 Control de productos no conforme4.13.1 Generalidades4.13.2 Revisión y disposición de productos no conforme4.19 Servicio



5.10.6 Registros y reportes de mantenimientoLista 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 versionesTipos 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ón6.1.1 GeneralMecanismos para identificar, controlar y dar seguimiento a las versiones de software.Identificar la versión de software.Identificar el estatus de los productos de software.Control de un item de software por más de una persona.Proveer la coordinación de la actualización de productos múltiples en una o más localidades.Identificar y dar seguimiento a las solicitudes de cambio desde su inicio hasta su liberación.6.1.2 Plan de administración de la configuraciónOrganizaciones involucradas y responsabilidades.Actividades a desarrollar.Herramientas, técnicas y metodologías a utilizar.6.1.3 Actividades 6.1.3.1 Identificación y seguimientoEspecificaciones funcionales y técnicas.Herramientas de desarrollo.Interfases con software y hardware.Documentos y archivos relacionados con software.6.1.3.2 Control de cambiosIdentificar, documentar, revisar y autorizar cualquier cambio.6.1.3.3 Reporte de estatusRegistrar, administrar y reportar el estatus.

4.4 Control de diseño4.4.1 Generalidades4.4.2 Planeación del diseño y desarrollo4.4.3 Interrelaciones organizacionales y técnicas4.4.4 Datos de entrada del diseño4.4.5 Resultados del diseño4.4.6 Revisión del diseño4.4.7 Verificación del diseño4.4.8 Validación del diseño4.4.9 Cambios del diseño4.5 Control de documentos y datos4.5.1 Generalidades4.5.2 aprobación y emisión de documentos y datos4.5.3 Cambios en documentos y datos4.8 Identificación y rastraebilidad del producto4.12 Estado de inspección y prueba4.13 Control de producto no conforme4.13.1 Generalidades4.13.2 Revisión y disposición de productos no conforme

6.2 Control de documentos 6.2.1 GeneralProcedimientos de control de documentos.Aprobación de los procedimientos.Procedimiento de cambios.6.2.2 Tipos de documentosSistema de calidad en el ciclo de vida de los sistemas.Documentos de planeación, actividades del

4.5 Control de documentos y datos4.5.1 Generalidades4.5.2 aprobación y emisión de documentos y datos4.5.3 Cambios en documentos y datos



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 usoRevisió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 documentos6.3 Registros de calidadTiempo de retención de los registros debe ser establecido y registrado.

4.16 Control de los registros de calidad

6.4 Medidores6.4.1 Medidores de los productosErrores y fallas.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 ProcesoQué tan bien el proceso de desarrollo de software se lleva a cabo.Qué tan efectivo el proceso de desarrollo está para reducir la probabilidad de introducción de errores o de no detectarlos.

4.20 Técnicas estadísticas4.20.1 Identificación de necesidades4.20.2 Procedimientos

6.5 Reglas, prácticas y convenciones 4.9 Control de procesos4.11 Control de equipo de inspección, medición y prueba4.11.1 Generalidades4.11.2 Procedimientos de control

6.6 Herramientas y técnicas 4.9 Control de procesos4.11 Control de equipo de inspección, medición y prueba4.11.1 Generalidades4.11.2 Procedimientos de control

6.7 Compras6.7.1 GeneralEl proveedor debe asegurar que un producto o servicio comprado está de acuerdo con los requerimientos especificados.6.7.2 Apoyo de subcontratistas6.7.3 Validación de producto no comprado

4.6 Adquisiciones4.6.1 Generalidades4.6.2 Evaluación de subcontratistas4.6.3 Datos para adquisiciones4.6.4 Verificaciones de los productos compardos4.6.4.1 Verificación del proveedor en las instalaciones del subcontratista4.6.4.2 Verificación del cliente al producto subcontratado

6.8 Productos incluidos de softwareValidación.Almacenamiento.Protección.Mantenimiento

4.7 Control de productos proporcionados por el cliente

6.9 CapacitaciónProveer capacitación para todo el personal involucrado en las actividades de un proyecto.

4.18 Capacitación



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-3IntroducciónGeneralidades Enfoque basado en procesosRelación con la norma NMX-CC-9004-IMNCCompatibilidad con otros sistemas de gestión

00.1

0.2

0.3

0.4Objeto y campo de aplicaciónGeneralidadesAplicación

11.11.2

1 Alcance

Referencias normativas 2 2 Normas de referenciaTérminos y definiciones 3 3 DefinicionesSistemas de gestión de la calidad 4 4 Requisitos del sistema de CalidadRequisitos generales 4.1Requisitos de la documentaciónDocumentaciónGeneralidadesManual de la calidadControl de los documentosControl de los registros

4.2

4.2.14.2.24.2.34.2.4

4.2

4.2.14.2.2

Sistema de calidad

GeneralidadesProcedimientos del sistema de Calidad

Responsabilidad de la dirección 5 4.1

4.1.14.1.24.1.3

Responsabilidad de la direcciónPolítica de CalidadOrganizaciónRevisión de la dirección

Compromiso de la dirección 5.1Enfoque al cliente 5.2Política de calidad 5.3Planificación 5.4Objetivos de calidad 4.5.1Planificación del sistema de gestión de la calidad

5.4.2 4.2.3 Planeación de la Calidad

Responsabilidad, autoridad y comunicación

5.5

Representante de la dirección 5.5.2Comunicación interna 5.5.3Revisión de la dirección 5.6Gestión de los recursos 6Competencia, toma de conciencia y formación

6.2.2 4.18 Capacitación

InfraestructurasAmbiente de trabajo

6.36.4

Realización del producto 7Planificación de la realización del 7.1 4.4.2 Planeación del diseño y desarrollo



productoProcesos relacionados con los clientes

7.2

Determinación de los requisitos relacionados con el producto

7.2.1 4.4.3

4.4.44.4.54.4.64.4.74.4.84.4.9

Interrelaciones organizacionales y técnicasEntradas del diseñoResultado del diseñoRevisión del diseñoVerificación del diseñoValidación del diseñoCambios del diseño

Revisión de los requisitos relacionados con el producto

7.2.2 4.34.3.14.3.24.3.34.3.4

Revisión del contratoGeneralidadesRevisiónModificaciones al contratoRegistros

Diseño y desarrollocompras

7.37.4

4.44.4.14.64.6.14.6.2

4.6.34.6.4

Control del diseñoGeneralidadesAdquisicionesGeneralidadesEvaluación de subcontratistasDatos para adquisicionesVerificación de los productos comprados

Producción y prestación del servicio 7.5 4.15

4.15.14.15.24.15.34.15.44.15.54.15.64.19

Manejo, almacenamiento, empaque, conservación y entregaGeneralidadesManejoAlmacenamientoEmpaqueConservaciónEntrega Servicio

Control de dispositivos de seguimiento y de medición

7.6 4.5

4.5.14.5.2

4.5.3

4.11

4.11.14.16

Control de documentos y datosGeneralidadesAprobación y emisión de documentos y datosCambios en documentos y datosControl de equipo de inspección, medición y pruebaGeneralidades Control de registros de calidad

Medición, análisis y mejor 8 4.12 Estado de inspección y pruebaGeneralidades 8.1 4.10.1 GeneralidadesAuditoría interna 8.2.2 4.10

4.10.2

4.10.3

4.10.4

4.10.5

4.17

Inspección y pruebasInspección y pruebas de reciboInspección y prueba en procesoInspección y pruebas finalesRegistros de inspección y pruebaAuditorías de calidad internas

Seguimiento y medición de los procesos y producto

8.2.38.2.4

4.7 Control de productos proporcionados por el cliente



4.8

4.9

Identificación y rastreo del productoControl del proceso

Control de producto no conforme 8.3 4.13

4.13.14.13.2

Control de producto no conformeGeneralidadesRevisión y disposición de productos no conformes

Análisis de datos 8.4 4.204.20.1

4.20.2

Técnicas estadísticasIdentificación de necesidadesProcedimientos

mejora 8.5Mejora continua 8.5.1Acciones correctivasAcciones preventivas

8.5.28.5.3

4.14

4.14.14.14.24.14.3

Acción correctiva y preventivaGeneralidadesAcción correctivaAcción preventiva

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.

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 Calidad4.1 Gestión de Sistemas y ProcesosEstablecer, documentar, implementar y mantener un sistema de gestión de calidad y mejorar continuamente su eficacia.

4.2 DocumentaciónLa 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 calidadLos 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ónComunicar la importancia de cumplir los requisitos del cliente, establecer la política de calidad y objetivos, suministro de recursos.

5.2 Enfoque al clienteDeterminar las necesidades y expectativas del cliente, cumplir requisitos, satisfacción del cliente.

5.3 Política de calidadApropiada 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 CalidadEstablecer 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 calidadLa planificación del sistema de gestión de calidad debe llevarse a cabo para cumplir los requisitos así como los objetivos de calidad.

5.5 Responsabilidad, autoridad y comunicaciónLas 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 internaAsegurar 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 recursosDeterminar 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 InfraestructuraIdentificar, suministrar y mantener la infraestructura necesaria para lograr la conformidad del producto (equipo adecuado, servicios de apoyo, etc).

6.4 Ambiente de trabajoIdentificar 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 productoDebe 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.

7.2 Procesos relacionados con el clienteDeterminar 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).

7.3 Diseño y desarrolloPlanificació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 ComprasProceso de compras, información de compras, verificación del producto comprado.

7.5 operaciones de producción y servicioControl 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 seguimientoDeterminar 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ónLa 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 conformeEl 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 MejoraLa 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:

a) Declaraciones documentadas de una política de calidad y objetivos de la calidad.

b) Un manual de calidadc) 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.



CAPÍTULO IVDIAGNÓSTICO DE LA SITUACIÓNACTUAL.



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



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 mejorado continuamente su sistema de administración de calidad de acuerdo con los requerimientos de este Estándar Internacional.

X

Para implantar el sistema de administración de calidad, el área: Ha identificado los procesos necesarios para el sistema de

administración de calidad Ha determinado la secuencia y la interacción de estos

procesos. Ha determinado los criterios y los métodos requeridos para

asegurar la operación efectiva y el monitoreo efectivos de estos procesos.

Mide, monitorea y analiza estos procesos, e implanta las acciones necesarias para lograr los resultados planeados y la mejora continua.

Maneja estos procesos de acuerdo a esta normativa internacional.

X X

X X X X

Parcialmente, mediante un sistema interno.

Algún personal externo realiza alguna actividad o esta involucrado en 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

X




Requerimiento ISO 9001: 4. Sistema de administración de calidad / 4.2 Requerimientos de documentación Área(s) Auditada(s):



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 objetivos de calidad.

Manual de Calidad. Procedimientos documentados requeridos en este Estándar

Internacional Documentación requerida por el área para asegurar la

planeación, operación y monitoreo efectivo de sus procesos. Registros requeridos por este Estándar Internacional.

X X X X 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.




Requerimiento ISO 9001: 4. Sistema de administración de calidad / 4.2 Requerimientos de documentación Área(s) Auditada(s):



Sí No N/A 4.2.2 Manual de Calidad

Se tiene/mantiene establecido con un Manual de Calidad que incluye: 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.

X

4.2.3 Control de Documentos

Se mantiene un control de los documentos requeridos por el sistema 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.

X




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 evidencia de la conformidad con los requerimientos y de la operación efectiva del sistema de administración de calidad.

X

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.




Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.1 Compromiso de la gerencia Área(s) Auditada(s):



Sí No N/A 5.1 Compromisos de la Gerencia

La alta gerencia cuenta con evidencia de su compromiso para el 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.

X




Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.2 Enfoque al cliente / 5.3 Política de Calidad Área(s) Auditada(s):



Sí No N/A 5.2 Enfoque al Cliente

La alta gerencia se ha asegurado que los requerimientos del cliente 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 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 estándares o especificaciones del cliente?

NOTA: Ver relación con los siguientes puntos (Ver. 7.2.1 y 8.2.1).

X X X

5.3 Política de Calidad

La alta gerencia ha asegurado que la política de calidad: 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.

X




Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.4 Planeación Área(s) Auditada(s):



Sí No N/A 5.4.1 Objetivos de calidad

Ha establecido la alta gerencia objetivos de calidad, incluyendo aquellos necesarios para cumplir con los requerimientos para el producto, en funciones y niveles relevantes dentro de el área.

X

Desarrollados en un taller interno.

Los objetivos de calidad definidos son medibles y consistentes con la política de calidad.

X

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 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 mantenida cuando son planeados e implantados cambios en el sistema de administración de calidad.

X X




Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.5 Administración Área(s) Auditada(s):



Sí No N/A 5.5.1 Responsabilidad y autoridad

Se tienen definidas y han sido documentadas las responsabilidades y autoridades dentro de el área por parte de la alta gerencia.

¿Es delegada la autoridad al personal para: prevenir la recurrencia de no-conformidades, identificar y registrar problemas de calidad, iniciar y verificar acciones correctivas, controlar procesos, realizar inspecciones?

X

X

Parcialmente, ya que no hay nada escrito

5.5.2 Representante de la gerencia

Ha designado la alta gerencia a un miembro de la gerencia que, 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.

X

5.5.3 Comunicación interna




Se ha asegurado la alta gerencia que se tengan establecidos procesos apropiados de comunicación dentro de el área, y que la comunicación tiene con respecto a la efectividad del sistema de administración de calidad.

¿Existe algún mecanismo de comunicación dentro de la Gerencia?

X

Requerimiento ISO 9001: 5. Responsabilidad de la gerencia / 5.6 Revisión gerencial Área(s) Auditada(s):




Mantiene la alta gerencia un proceso de revisión del sistema de administración de calidad, en intervalos planeados, para asegurar su continua adecuación, suficiencia y efectividad.

X

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




Se incluyen como datos de entrada para la revisión de la gerencia la 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.

X





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 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.

X




Requerimiento ISO 9001: 6. Administración de recursos / 6.1 Provisión de recursos Área(s) Auditada(s):



Sí No N/A Se ha determinado y proporcionado los recursos necesarios para: a) Para implantar y mantener el sistema de administración de calidad y mejorar continuamente su efectividad. b) Incrementar la satisfacción del cliente mediante el cumplimiento de sus requerimientos.

X

X

Únicamente verbal




Requerimiento ISO 9001: 6. Administración de recursos / 6.2 Recursos humanos Área(s) Auditada(s):




El área se asegura que el personal que realiza actividades que afecta la calidad del producto es competente con base en educación apropiada, entrenamiento, habilidades y experiencia.

¿Están claramente definidas y documentadas las responsabilidades y autoridades de todo el personal que afecta la calidad (Gerente, Subgerente, Líder, etc)?

X

X

Registros de capacitación

6.2.2 Competencia, conocimiento y entrenamiento

Tiene el área definidas las necesidades de competencia para el personal que realiza actividades que afectan la calidad del producto.

X

El área ha proporcionado el entrenamiento u otras acciones para satisfacer las necesidades identificadas.

X

Se evalúa la efectividad del entrenamiento proporcionado.

X

Se asegura el área de que los empleados tienen conocimiento de la relevancia e importancia de sus actividades y cómo contribuyen al logro de los objetivos de calidad.

X

Se mantienen registros apropiados de la educación, entrenamiento, habilidades y experiencia. (Ver 4.2.4).

X




Requerimiento ISO 9001: 6. Administración de recursos / 6.3 Infraestructura / 6.4 Medio de Trabajo Área(s) Auditada(s):



Sí No N/A 6.3 Infraestructura

El área ha determinado, proporcionado, y mantiene la infraestructura 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 X

Visual y registros de inventario.

6.4 Medio de Trabajo

Se han determinado y se administran el medio de trabajo necesarios para alcanzar la conformidad de los requerimientos del producto.

¿Se realiza una evaluación periódica del ambiente de trabajo en la Gerencia?

X X

Hardware, software, comunicaciones.




Requerimiento ISO 9001: 7. Realización del producto / 7.1 Planeación de la realización del producto. Área(s) Auditada(s):



Sí No N/A El área planea y desarrolla los procesos necesarios para la realización del producto.

X Artefactos, metodología RUP.

La planeación de los procesos de realización es consistente con los otros requerimientos del sistema de administración de calidad de el área.

X

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. Necesidad de establecer los procesos, documentación, y

proporcionar los recursos y las facilidades específicas al producto.

Actividades requeridas de verificación, validación, monitoreo, inspección y pruebas específicas para el producto y los criterios de aceptabilidad del producto.

Los registros que son necesarios para proporcionar evidencia 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.

X X X

X

Artefactos, metodología RUP. Artefactos, metodología RUP. Artefactos, metodología RUP.




La salida de la planeación se encuentra en una forma adecuada a los métodos de operación de el área.

¿Existe personal calificado, para realizar las actividades de verificación en las etapas de inspección, pruebas y monitoreo del diseño, producción, instalación y servicio?

X X




Requerimiento ISO 9001: 7. Realización del producto / 7.2 Procesos relacionados con el cliente Área(s) Auditada(s):



Sí No N/A 7.2.1 Determinación de requerimientos relacionados al producto

Ha identificado el área los siguientes requerimientos: Requerimientos especificados por el cliente, incluyendo los

requerimientos para la entrega y actividades post-entrega. Requerimientos no declarados por el cliente pero necesarios

para el uso especificado o intencionado, donde sea conocido. Requerimientos estatutarios y regulatorios relacionados con

el producto. Cualquier requerimiento adicional determinado por el área. ¿Existe algún mecanismo para medir la calidad del servicio

proporcionado al cliente?

X X X

X X

Disciplina de Requerimientos de RUP. Disciplina de Requerimientos de RUP. Disciplina de Requerimientos de RUP.

7.2.2 Revisión de requerimientos de producto

Revisa el área los requerimientos identificados del cliente junto con requerimientos adicionales determinados por el área.

X Disciplina de Requerimientos de RUP.

Se revisan los requerimientos antes de establecer un compromiso 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.

X





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 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: 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 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 declaración documentada del requerimiento antes de su aceptación.


Cuando los requerimientos sufren modificaciones, se asegura el área 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.

7.2.3 Comunicación con el cliente

Tiene el área determinados e implantados arreglos efectivos para la 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.

X




Requerimiento ISO 9001: 7 Realización del producto / 7.3 Diseño y desarrollo Área(s) Auditada(s):



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:

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

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?

X X

Artefactos de RUP. Parcialmente, a través de RUP

Se tienen definidas las interfaces entre los diferentes grupos implicados en el diseño y desarrollo para asegurar comunicación efectiva y claridad de responsabilidades.

X

Se actualiza la salida de la planeación conforme el diseño y desarrollo progresa.

X A través de la metodología RUP



7.3.2 Entradas del diseño y desarrollo

Se tienen definidas y documentadas las entradas relacionadas con requerimientos del producto y se mantienen registros de ésta actividad.

¿En el caso de desarrollo de sistemas están definidos claramente y sin ambigüedad los requisitos funcionales? (Desempeño, seguridad, confiabilidad, interfases).

X X

En definición

Se incluyen en los datos de entrada: 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 adecuación y resueltos los requerimientos incompletos, ambiguos o conflictivos entre sí.

X X





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 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?

X Verbal únicamente.

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: 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.

X

7.3.4 Revisión del diseño y desarrollo

Se conducen en etapas adecuadas y de acuerdo a los arreglos 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 documentadas formalmente según el plan de diseño?

X X

Verbal únicamente.

Se incluye entre los participantes en tales revisiones a representantes de funciones concernientes con la etapa de diseño y el desarrollo que está siendo revisada.

X No siempre.

Son registrados los resultados de las revisiones y las acciones subsiguientes de seguimiento.

X Documentación informal.

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.



7.3.5 Verificación del diseño y desarrollo

Se realizan verificaciones del diseño y desarrollo de acuerdo al los arreglos planeados para asegurar que las salidas del diseño y desarrollo han satisfecho los requerimientos de entrada del diseño y desarrollo.

¿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 complementado satisfactoriamente todas las actividades especificadas en los procedimientos?

X X X

Visual únicamente, sin documentación formal.

Son registrados y mantenidos los resultados de la verificación y las acciones de seguimiento.





7.3.6 Validación del diseño y desarrollo

Se realizan validaciones del diseño y desarrollo de acuerdo a los 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 frecuencias especificadas, anotando los resultados y asignando responsables para la solución de fallas?

X X

Verbal únicamente.

Cuando así es aplicable, se completa la validación antes de la entrega o implantación del producto.

X Necesario por la propia actividad de desarrollo de sistemas.

Son registrados y mantenidos los resultados de la validación y las 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 diseño y desarrollo.

¿Se ha obtenido una aprobación por escrito o una desviación del cliente previo a la implantación de un cambio de diseño en producción?

X X

Son revisados, verificados y validados los cambios, según sea apropiado, y aprobados antes de la implantación.

¿Son documentados y aprobados los cambios de diseño por personal autorizado antes de su implantación?

X X

Se incluye en le control anterior la evaluación del efecto de los cambios en las partes, componentes y productos entregados.

X

Son registrados y mantenidos los resultados de la revisión de los cambios y las acciones necesarias de seguimiento.

X




Requerimiento ISO 9001: 7. Realización del producto / 7.4 Compras Área(s) Auditada(s):



Sí No N/A 7.4.1 Control de compras

Controla el área sus procesos de compras para asegurar que el producto comprado esté conforme con los requerimientos especificados.

X

El tipo y la extensión del control en los procesos de compra dependen del efecto del producto comprado en los procesos subsecuentes de realización del producto o el producto final.

X

Evalúa y selecciona el área a sus proveedores basado en su capacidad de suministrar el producto de acuerdo con los requerimientos de el área.

X

Se tiene definidos los criterios para la selección, evaluación y re-evaluación de los proveedores.

X

Se mantienen registros de los resultados de las evaluaciones y de las acciones subsecuentes generadas del seguimiento.

X

7.4.2 Información de compras

Contienen los documentos de compra información describiendo el 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.

X

El área asegura que los requerimientos especificados contenidos enlos documentos de compra antes de la comunicación con el proveedor son los adecuados.

X

7.4.3 Verificación del producto comprado




Tiene el área identificadas y aplicadas las inspecciones y las actividades necesarias para asegurar que los productos comprados cumplen los requerimientos de compra especificados.

X

Si se establece o el cliente establece realizar verificaciones de las 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.

X

Requerimiento ISO 9001: 7. Realización del producto / 7.5 Producción y provisión del servicio Área(s) Auditada(s):



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 bajo condiciones controladas.

X

Controla el área las operaciones de producción y servicio mediante: Disponibilidad de información que especifica las

características del producto. Donde sea necesario, la disponibilidad de instrucciones de

trabajo. Uso de equipo adecuado. Disponibilidad y uso de dispositivos de medición y monitoreo. ¿Se tiene un proceso para validar lo correcto y completo de

las versiones de los sistemas? Implantación de actividades de monitoreo y medición. Implantación de procesos definidos para la liberación, entrega

y las actividades aplicables de post-entrega.

X X

X X X X

Artefactos de RUP. Herramientas usadas por RUP.

7.5.2 Validación de procesos para producción y provisión del servicio




Lleva a cabo el área validaciones de los procesos de producción y 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.

X

Las validaciones permiten demostrar la capacidad de los procesos para lograr los resultados planeados.

X

Se tienen definidos los arreglos para la validación incluyendo, según 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

obligaciones del cliente y de la Gerencia, en la etapa de 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.

X

X Únicamente en ls casos en que el cliente es personal del Banco.

7.5.3 Identificación y rastreabilidad

Se mantiene identificado, según sea apropiado, el producto por medios adecuados a través de las etapas de realización del producto.

¿Se tiene un procedimiento para administrar las versiones de las aplicaciones, respaldos y procesos de recuperación en caso de desastre?

¿Se tiene algún mecanismo para identificar el estado del software a lo largo de las etapas, desde desarrollo hasta implantación?

X X

X

Herramientas de RUP. Herramientas de RUP. En definición.

Se mantiene identificado el estado del producto con respecto a los requerimientos de las mediciones y monitoreos.

X

Se mantiene un control y registro de la identificación única del producto, donde la rastraebilidad es un requerimiento.

¿Existe un procedimiento de replicación que incluya: el número de copia de cada software a ser liberado, el medio de almacenamiento, incluyendo formato y versión, la

X X



Se mantiene un control y registro de la identificación única del producto, donde la rastraebilidad es un requerimiento.

¿Existe un procedimiento de replicación que incluya: el 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?

X X

7.5.4 Propiedad del cliente

Se ejerce un adecuado cuidado con la propiedad del cliente mientras está bajo el control de el área o siendo usado por el área.

X

Se mantiene un control de identificación, verificación, protección y 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 y mantenimiento a los productos o información proporcionados por el cliente?

X X

Se mantienen registros y se reporta al cliente cuando cualquier 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.

X

7.5.5 Conservación del Producto

Se mantiene un control para asegurar que se conserva la 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 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?

X

X

El control antes mencionado incluye la identificación, manejo empaque, almacenamiento y protección del producto.

¿Se tiene un procedimiento para liberar la nueva versión con 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)?

X

X

El control mencionado incluye a las partes componentes de un producto.

X




Requerimiento ISO 9001: 7 Realización del producto / 7.6 Control de dispositivos de medición y monitoreo Área(s) Auditada(s):



Sí No N/A Se tienen identificadas las mediciones y monitoreos a ser realizadas y 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 y reportar la realización y resultados de las inspecciones y pruebas?

X X

Se tienen establecidos los procesos que aseguren que los monitoreos y mediciones pueden ser efectuadas y son efectuadas de manera que sea consistente con los requerimientos de monitoreo y medición.

X

Se mantiene un control sobre los dispositivos de medición y 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.

X

Se evalúa y registra la validez de los resultados de medición previos cuando se encuentra un equipo no conforme con los requerimientos y las acciones apropiadas sobre el equipo y cualquier equipo afectado.

X




Se mantienen los registros de los resultados de las calibraciones y verificaciones de los equipos.

¿El equipo de inspección, medición y pruebas (incluyendo software) utilizado, es capaz de dar la exactitud y precisión requeridas?

X X

Es confirmada la capacidad para satisfacer la aplicación intencionada 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 pruebas (incluyendo software cuando sea aplicable) para garantizar que la calibración no sea alterada?

X X




Requerimiento ISO 9001: 8 Medición, análisis y mejora / 8.1 General Área(s) Auditada(s):



Sí No N/A Se tienen planeados e implementados los procesos de monitoreo, 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

administración de calidad. ¿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?

X

En esta planeación se tienen incluidos la determinación de métodos 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?

X




Requerimiento ISO 9001: 8 Medición, análisis y mejoras / 8.2 Monitoreo y medición Área(s) Auditada(s):



Sí No N/A 8.2.1 Satisfacción del cliente

Se mantiene un mecanismo para monitorear la información en relación con la percepción del cliente en cuanto al cumplimiento de los requerimientos.

X

Se tiene definidas las metodologías para obtener y usar esta información.

X

8.2.2 Auditoría Interna

Conduce el área auditorías internas a intervalos planeados para 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.

X

Se tiene planeado un programa de auditoría tomando en 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.

X

Se tiene definidos los criterios de auditoría, alcance, la frecuencia y las metodologías.

X

La selección de auditores y conducción de las auditorías aseguran la objetividad e imparcialidad del proceso de auditorias.

X

Se aseguran de que los auditores no auditen su propio trabajo. X




Se tiene definido un procedimiento documentado en el que se 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.

X

Se aseguran de que la gerencia responsable del área auditada toma acciones sin retraso indebido, para eliminar las no conformidades y sus causas.

X

Las actividades de seguimiento incluyen la verificación de las acciones tomadas y se reportan los resultados de la verificación (Ver 8.5.2).

X





Sí No N/A 8.2.3 Monitoreo y medición de procesos

Se aplican métodos adecuados para monitorear y donde sea 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?

X

Permiten demostrar estos métodos la capacidad para alcanzar los resultados planeados.

X

Se toman acciones de corrección y acciones correctivas según sea apropiado que aseguren la conformidad del producto cuando los resultados planeados no son alcanzados.

X

8.2.4 Medición y monitoreo de producto

Se monitorean y se miden las características del producto para 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?

X

Las actividades de monitoreo son llevadas a cabo en etapas apropiadas del proceso de realización del producto y de acuerdo a los arreglos planeados.

X

Se mantiene la evidencia de conformidad con los criterios de aceptación.

X

Indican los registros la autoridad responsable de la liberación del producto.

X

Se asegura que la liberación del producto y la entrega del servicio no 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.

X




Requerimiento ISO 9001: 8 Medición, análisis y mejoras / 8.3 Control de producto no conforme. Área(s) Auditada(s):



Sí No N/A Se asegura que el producto no esté conforme con los requerimientos es identificado y controlado para prevenir el uso o entrega no intencionado.

X

Se tiene definidas las actividades de control, responsabilidad y autoridades relacionadas para tratar el producto no conforme en un procedimiento documentado.

¿Se tienen identificados a los sistemas que no cumplen con los requisitos de documentación, de programación, y otros?

X X

Se trata el producto no conforme por alguno o más de los siguiente 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.

X

Se mantienen los registros d el as no conformidades y cualquier acción subsecuente tomada incluyendo concesiones obtenidas.

X

Es sujeto a una reverificación el producto no conforme corregido con la finalidad de demostrar su conformidad con los requerimientos.

X

Se toman acciones apropiadas a los efectos, o efectos potenciales de 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.

X Informal, de palabra únicamente




Requerimiento ISO 9001: 8 Medición, análisis y mejoras / 8.4 Análisis de datos Área(s) Auditada(s):



Sí No N/A Lleva a cabo el área actividades para determinar, recolectar y analizar 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 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?

X X

Efectúa el área análisis de los datos antes mencionados para 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?

X




Requerimiento ISO 9001: Área(s) Auditada(s):



Sí No N/A 8.5.1 Mejora continua

El área mejora continuamente la efectividad del sistema de 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.

X

8.5.2 Acción correctiva

Se toman acciones para eliminar la causa de no conformidades con el 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?

X

Las acciones correctivas tomadas son apropiadas a los efectos de las no conformidades encontradas.

X

Mantiene un procedimiento documentado que defina los 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.

X





Sí No N/A 8.5.3 Acción preventiva

Se toman acciones preventivas para eliminar las causas de no conformidad potenciales para prevenir la recurrencia.

¿Se cuenta con un procedimiento de cambios a procesos en la Gerencia?

X

Las acciones preventivas tomadas son apropiadas a los efectos de 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?

X

Se tiene establecido un procedimiento documentado para definir los 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.

X



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.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.



CAPÍTULO VPROPUESTA DE IMPLANTACIÓN DEL SISTEMA DE GESTIÓN ISO-9001:2000 PARA EL

PROCESO DE DESARROLLO DE SOFTWARE.



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.



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 calidado 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 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é deCalidad

C.C.

Equipo deprocesos

E.P.

EquipocentralE.C.

04/09/2003RMCG Banco de México

Equipo de trabajo para la certificación bajo ISO 9001:2000

DIRECCIÓN DESISTEMAS

OPERATIVOS Y DEPAGOS

GERENCIA DEINFORMÁTICA

“REPRESENTANTEDE LA DIRECCIÓN”

SUBGERENCIA DEDESARROLLO DE

INFRAESTRUCTURAINFORMÁTICA

SUBGERENCIA DEINFORMÁTICA DE

ATENCIÓN AUSUARIOS

Comité de Calidad Encargado de definir y dar seguimiento a

las actividades propias del sistema degestión de calidad.

Analista de Sistemas

Equipo central Proyectos relacionados a los requisitos

4.0, 5.0 y 6.0 de la norma ISO 9001:2000

Analista de Sistemas

Equipo de procesos Proyectos relacionados a los requisitos

7.0 y 8.0 de la norma ISO 9001:2000

Figura 5.1. Estructura del equipo de calidad.




Etapas para la certificación bajo ISO 9001:2000

Definiciónde Alcance

Diagnóstico de lasituación actual, bajo

el estándar ISO9001:2000

Desarrollo de ladocumentación delsistema de calidad

Definición

Desarrollar elmanual decalidad de laGerencia deInformática

Definir losprocesos deacuerdo a lascláusulas dela norma ISO9001

Desarrollarinstructivos yregistros decalidad

Despliegue dedocumentacióndel sistema de

calidad

Auditorias alsistema de

calidad

Certificación delsistema de

calidad

Monitoreo delproceso y

mejora continua

Difundir lapolítica decalidad

Implantarnuevosprocesos deacuerdo a losrequisitosque marca lanorma

Implantarinstructivos yregistros decalidad

Reunirevidencia

Tenerauditoríascada devigilancia

Implantarproceso demejoracontinua

Seleccionarcertificador

Solicitar lacertificación

Agendarauditoríainicial

Implantaraccionescorrectivas

Agendarauditoría decertificación

Obtener lacertificación

Realizarauditoríasinternas alproceso

Implantarprimerasaccionescorrectivas ypreventivas

Figura 5.2. Pasos para la certificación.



Definiciónde Alcance

Diagnóstico de lasituación actual, bajo

el estándar ISO9001:2000

Desarrollo de ladocumentación delsistema de calidad

Definición

Despliegue dedocumentacióndel sistema de

calidad

Auditorias alsistema de

calidad

Certificación delsistema de

calidad

Monitoreo delproceso y

mejora continua

Equipocentral

Equipo deprocesos

Personal dela Gerencia

Equipocentral

Personal dela gerencia

Organismocertificador

Equipocentral


Organismocertificador

Equipocentral


Equipocentral

Comité decalidad


Equipo de trabajo para la certificación bajo ISO 9001:2000

Equipocentral

Equipo deprocesos

Comité decalidad

Equipocentral

Equipo deprocesos

Personal dela Gerencia

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:2000Establecer 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ónInforme del diagnóstico

Elaboración del informe 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:



1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2DEFINICIÓ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ÓNLa 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 CALIDADLa 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 CALIDADLa 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.

PROYECTO DE MEJORA RESPONSABLETIEMPO EN MESES

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 1 24.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.

TIEMPO EN MESESCRITERIO DE LA NORMA RESPONSABLE 9 10 11 125 6 7 81 2 3 4



1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 26.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.

TIEMPO EN MESESCRITERIO DE LA NORMA RESPONSABLE 9 10 11 125 6 7 81 2 3 4



1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 28. 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.

TIEMPO EN MESESCRITERIO DE LA NORMA RESPONSABLE 9 10 115 6 7 81 2 3 4

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.



5.4 Recomendaciones de ISO 9000-3 para el proceso de desarrollo de software.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. 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.



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.o Los requisitos de la entrada del diseño se deben especificar por el

cliente. 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.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.

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 procesoISO 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 pruebaISO 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.

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 pruebaISO 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 pruebaISO 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 conformesISO 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. 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 preventivasISO 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 entregaISO 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.

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 calidadISO 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 internasISO 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.

ISO 9000-3: 4.18 CapacitaciónISO 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-ventaISO 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ísticasISO 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 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.





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



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



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.



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.

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: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.



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; ef) 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.



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.



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

Manualdecalidad

Procedimientos del sistema de

calidad y de operación.Manuales de instrumentos

Instructivos de operación

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ónSon 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ónSon 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


Nivel 1

Nivel 2

Nivel 3

Nivel 4


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.

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; yg) 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.



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:

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; yf) 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.

5.5 Responsabilidad, autoridad y comunicación

5.5.1 Responsabilidad y autoridad

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.

5.5.3 Comunicación interna

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; yc) 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.



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)

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, ei) higiene, limpieza ruido, vibración y contaminación.



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 Procesos relacionados con el cliente

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; yd) 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; yc) 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.

7.2.3 Comunicación con el cliente

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 Diseño y desarrollo

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.

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; ye) 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

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); yd) 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).

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; ye) 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.



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 serviciob) asegurarse de la gestión del sistema de gestión de la calidad; yc) 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.

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; yc) 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.

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.

8.5.2 Acción correctiva

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); yf) revisar las acciones correctivas tomadas, verificando su efectividad.

8.5.3 Acción preventiva

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); ye) revisar las acciones preventivas tomadas verificando su efectividad.

9.0 Procesos de la Gerencia y sus interrelaciones

Diagramas de flujo de los procesosDescripción general de las funciones de cada proceso

Nombre del proceso:

Responsable Propósito general:

Proceso de desarrollo de software

Subgerencia de Desarrollo de Infraestructura Informática

Proceso clave, para el desarrollo de sistemas informáticos que requieren los clientes de la Gerencia.

Proceso de mantenimiento de sistemas

Subgerencia de Desarrollo de Infraestructura Informática

Proceso clave para el buen funcionamiento de los sistemas desarrollados en la Gerencia.

Proceso de monitoreo de sistemas

Subgerencia de Informática de Atención a Usuarios

Proceso de soporte a los procesos claves, cuya finalidad es vigilar el buen funcionamiento de los sistemas a cargo de la Gerencia de informática.

Proceso de soporte a usuarios

Subgerencia de Informática de Atención a Usuarios

Proceso de soporte a los procesos claves, cuya finalidad es proporcionar la asistencia que requieran nuestros clientes para el buen aprovechamiento de los sistemas.

Proceso de compras

Gerencia de informática-Área de compras del Banco de México

Proceso de soporte a los procesos claves; el cual se lleva a cabo en coordinación con el área de compras 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 reclutamiento

Gerencia de informática-Área de reclutamiento y selección del Banco de México

Proceso de soporte a los procesos claves; el cual se lleva a cabo en coordinación con el área de reclutamiento y selección del Banco, ya que no 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

Lista de todos los procedimientos utilizados por el sistema de gestión de calidad.

Procedimiento de auditoría interna Procedimiento de acciones correctivas



0004

PROCEDIMIENTO (PROPUESTO) DE AUDITORIAS INTERNAS DE CALIDAD1. PropósitoDefinir 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 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 AuditoresLa 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.

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.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.



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____________________ Participantes___________________ Fecha___________ Horario____________________ Participantes___________________ Fecha___________ Horario____________________ Participantes___________________ Fecha___________ Horario____________________ Participantes___________________ Fecha___________ Horario____________________ 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__________



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_______________ Participantes ____________ / ____________ Fecha_________ Horario_______________ Participantes ____________ / ____________ Fecha_________ Horario_______

Junta Post.auditoria: Repres:______________________ Fecha_________ Hora__________

RESULTADOS DE LA AUDITORIA.

Depto/Área_________________ Auditado__________________ Resp. __________________Anomalìas______________________________________________________________________Depto/Área_________________ Auditado__________________ Resp. __________________Anomalìas______________________________________________________________________Depto/Área_________________ Auditado__________________ Resp. __________________Anomalìas______________________________________________________________________Depto/Área_________________ Auditado__________________ Resp. __________________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 _________



ANEXO 3FORMATO REPORTE DE AUDITORIA (SOLO REFERENCIA)

REPORTE DE AUDITORIAS

SOLICITUD DE ACCION CORRECTIVA

No.___________________

PARA ÁREA FECHA DE AUDITORIA

FIRMA DEL AUDITOR

ESTANDAR CLAUSULA NO. PROCEDIMIENTO APLICABLE

(1) NO CONFORMIDADES

FAVOR DE CONTESTAR ANTES DE LA FECHA

FIRMA DE CONFORMIDAD/AUDITADO

FECHA

(2) CAUSA DE NO CONFORMIDAD

(3) PLAN DE ACCIÓN CORRECTIVA

FECHA COMPROMISO DE ACCIÓN CORRECTIVA

FIRMA (GENERTE DE LA DIVISIÓN)

FECHA

(4) VERIFICACIÓN FINAL DE LA ACCIÓN CORRECTIVA

ACCIÓN CORRECTIVA EFECTIVA

SI NO

FIRMA FECHA

DIAGRAMA DE FLUJO DE AUDITORIAS INTERNAS





0006

PROCEDIMIENTO (PROPUESTO) DE ACCIONES CORRECTIVAS Y PREVENTIVAS1.0 PropósitoEstablecer 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 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 Preventivasb) El o los propietarios del procedimiento y/o proceso involucradoc) El Representante de Calidad

7.0 Clases o tipo de documentación

Entradas Salidas 7.1 Procedimiento de Auditorias Internas de Calidad SAC7.4 Pasos para la solución de problemas (Anexo IV) Reporte 7Ds

7.5 Iniciación de Acción Preventiva IAP-Anexo III y IIIA7.6 Iniciación de acción correctiva SAC

7.7 RSNC

8.0 Políticas8.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 causasde No Conformidades reales o potenciales serán proporcionales a



la magnitud de los problemas detectados y a los riesgos que de ellos puedan derivarse.

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.

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.



ANEXO I ALlenado 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ónLa 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:

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 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.



ANEXO II ALlenado 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ónLa 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.




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.



Anexo III A

Llenado de la Forma de Iniciación de la Acción Preventiva (IAP)

1.0 Definición del ProblemaDefina claramente el problema potencial o la tendencia que se decide atender.

2.0 GrupoForme 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 ProblemaAyuda visual empleada para mejorar la descripción del problema cuando sea necesario.

4.0 Medición del Nivel de CalidadAnote 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 EfectoEn el diagrama anote todas las posibles causas que puedan dar origen al

problema, empleando lluvia de ideas.

6.0 Listar causas del problemaEn 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ónUna 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 AccionesMediante 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 EstudioAnote 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.



ANEXO IV6 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.

- 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



ANEXO ISOLICITUD 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_____________

BNú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 RECHAZADAEvaluado por_____________________ Evaluado por: __________________________Fecha____________________________ Fecha__________________________________

Comentarios________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

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_____________

BNú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 FechaComentarios:_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Definición del problema:

______________________________________________________________________________________

Listar las 3 principales causas raíz de la sesión de tormenta de ideas:

1.________________________________________



______________________________________________________________________________________

__2.__________________________________________3.__________________________________________

Grupo1._______________2._______________3._______________4._______________5._______________6._______________7._______________Líder____________________________________________________

Descripción esquemática del problema (sí se requiere):

Determinar la acción preventiva y plan de implementación:Causa Raíz Acción Preventiva Respuesta Fecha

1.______________________________________________________________________________________2.______________________________________________________________________________________3.______________________________________________________________________________________

Medición del nivel de Calidad

Nivel Actual Nivel meta 1(D/M/A)____________________________________________________Nivel meta 2(D/M/A)___________________________________________________

Verificar efectividad de las acciones:

Unidades DeMedición Del nivel De Caliad

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 MaquinaANEXO III

FORMATO DE INICIACIÓN DE ACCIÓN PREVENTIVA (IAP).



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.



CONCLUSIONES Y RECOMENDACIONES.



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 existen9:

12 formas de matar un sistema de calidad1. 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 9 http://www.cp.com.uy/44/iso44.htm



1. La aceptación de que los clientes internos y externos son los protagonistas más importantes del proceso

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..



ANEXOS



Anexo 1REFERENCIAS

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



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.8721. http://www.banxico.org.mx p.1222. http://www.praxiom.com p.17423. http://www.cp.com.uy/44/iso44.htm p.18724. http://webinterno/ p.1425. http://webinterno/BancaCentral/InfoEconomica/InfoSisPagos/SisPagos p.17


http://webinterno/BancaCentral/InfoEconomica/InfoSisPagos/SisPagos

http://webinterno/

http://www.cp.com.uy/44/iso44.htm

http://www.praxiom.com/

http://www.banxico.org.mx/

http://www.iso.org/


Anexo 2Glosario 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..



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.

Actividad de alto nivel Expediente

Barra de Sincronización Documento

Punto de Inicio Punto de Fin

Decisión Sistema

Rol Primario Estadística

Rol de Apoyo Capacitación

Actividad Dirección del Flujo


Documents

Universidad Iberoamericana · Web viewMS Word Modelo de Caso de Uso (cat) Negociable 50% 100% Opcional Rational Rose Prototipo de Interfaz de Usuario Opcional 30% 100% Opcional A