ISO 90003

2

NORMA ISO 9000-3 (DREY)

2

- HISTORIA - CONTEXTO - PREDECESORA - (BETANIA)

3

ALCANCE DE LA ISO 9000-3 (DREY)

4

SECCIONES 9000-3 (BETANIA)

5

PRINCIPALES CARACTERÍSTICAS (DREY)

6

DETERMINACIÓN DE LA CAPACIDAD DE MEJORA DEL PROCESO DE SOFTWARE»

8

ISO/IEC 15504 (DREY)

8

MODELO DEL SISTEMA (BETANIA)

9

DIMENSIONES (DREY)

9

ISO 900-3

PROFESORA:

Iso

Luisa Rodriguez

9000-3

REALIZADO POR: Drey Gonzalez Betania Garcia

L

a ISO 9003 es una norma desarrollada por la Organización Internacional de Normas (OIN) que regula las actividades de inspecciones y pruebas finales. La norma ISO 9003 ya es obsoleta y actualmente no se otorga.

Fue reemplazada en el año 2000 por un nuevo conjunto de normas que son las ISO 9001. Estas últimas brindan un marco más amplio que abarca varios aspectos de un sistema administrativo de calidad. Hoy en día, por lo general, las empresas buscan obtener la certificación 9001.

T E O R I A

D E

L A

I N F O R M A C I O N

-

L U I S A

R O D R I G U E Z

CONTENTIDO

ISO 900-3 (BETANIA)

Norma ISO 9000-3 son los estándares utilizados para el desarrollo, suministro y mantenimiento del software. Ámbito de aplicación: Introduccion La ISO 9000-3 nos proporciona una guía útil que nos sirve para detectar y corregir una serie de problemas de los productos software, consiguiendo tras su aplicación una mejora en la calidad de los mismos.

2

• • •

Desarrollo de Sistemas de Información Procesos del Ciclo de vida Calidad de Software

AUTOR:DREY GONZALEZ

- HISTORIA - CONTEXTO - PREDECESORA HISTORIA

Y D R E Y G O N Z A L E Z

La ISO 9001:2000 fue dada a conocer en el inicio del nuevo milenio y fusionaba la ISO 9003 con otros dos documentos, la 9001 y la 9002. Esta combinación permitió introducir un cambio

G A R C I A

SUCESORA

radical y llevó el foco a la administración de los procesos y a la fuerza de su cumplimiento, en oposición a la observación meticulosa del producto y su calidad.

Una derivación adicional muy importante de la ISO 9003 fue hacer responsable a la alta gerencia de los resultados y de asegurar una utilización eficiente de un sistema administrativo de calidad.

B E T A N I A

Las pautas de la norma BS 5750 se concentraban en cómo debían administrarse los procesos de fabricación, no en qué debía fabricarse. En el año 1987, la OIN aceptó adoptar la norma 5750 como la base de un nuevo conjunto de estándares internacionales al que llamó serie ISO 9000. Las primeras consistían en documentos provisorios, de los cuales la ISO 9003 formaba parte.

P O R

PREDECESORA

9 0 0 0 - 3

CONTEXTO La serie ISO 9000 se inició a instancias del gobierno británico. Durante la Segunda Guerra Mundial, el Reino Unido investigó temas relativos a defectos de calidad en municiones que provocaban el estallido de bombas en las fábricas.

Los procedimientos y las normas de fabricación se fueron desarrollando para abarcar todos los riesgos y finalmente conformaron las normas BS 5750 del Reino Unido.

I S O

La Organización Internacional de Normas (OIN) fue creada en Suiza en el año 1947, en un intento por armonizar las normas de diferentes países y crear una protección que generara un conjunto común de expectativas y un lenguaje común de estándares. La organización invitó a un experto por cada país para integrar los comités técnicos.

Participaron más de 160 países y unieron esfuerzos para crear más de 18.000 normas durante los últimos 50 años..

Por último, la utilización de la métrica se convirtió en una herramienta importante dentro de las normas 9000 para monitorear defectos y traer aparejada una mejora continua de los procesos, es decir detectar y solucionar las fallas.

AUTOR: BETANIA GARCIA

3

ALCANCE DE LA ISO 9000-3 y mantenimiento de software.”

L R O D R I G U E Z

a norma ISO 90003 es requerida por todas las compañías desarrolladoras de software para:

ALCANCE DE LA ISO 9000-3

C

I N F O R M A C I O N

-

L U I S A

on la norma se busca dar orientaciones en situaciones en las que se exija la demostración de la capacidad de un proveedor para desarrollar, suministrar y mantener productos de software.

T E O R I A

D E

L A

La norma sugiere clases de control y métodos para la producción de software que satisfaga los requisitos establecidos.

ANÁLISIS DE LA ISO 9000-3

S

irve para interpretar la norma ISO 9001 en el ámbito de la Ingeniería de Software.

De hecho, su nombre es: “Guía para la aplicación de ISO 9001 para el desarrollo, la aplicación 4

• Incursionar en el mercado europeo • Cubrir las expectativas de los clientes • Obtener beneficios de calidad • Como estrategia de mercado • Para reducir costos de producción

A

lgunos de los beneficios que se obtienen con la certificación de la Norma ISO 9000-3 son: • Mejor documentación de los sistemas.

• Cambio cultural positivo.

• Incremento en la eficiencia y productividad.

• Mayor percepción de calidad • Se amplía la satisfacción del cliente • Se reducen las auditorías de calidad • Agiliza el tiempo de desarrollo de un sistema

CLAUSULAS DE LA ISO 9000-3

SECCIONES DE LA ISO 9000-3

Sistemas de Calidad La empresa debe establecer y mantener un sistema de calidad documentado que debe incluir:

Administración de la Responsabilidad.

La dirección de la empresa debe definir y documentar su política y sus objetivos con respecto a la calidad.

Las responsabilidades, autoridades y relaciones entre todo personal, cuyo trabajo afecte la calidad del producto, deben ser definidas.

• Instructivos para la preparación de procedimientos del sistema de calidad.

• Instrucciones para la aplicación efectiva de los procedimientos.

Auditorias internas de calidad

AUTOR:DREY GONZALEZ

SECCIONES 9000-3 La empresa debe llevar un sistema de auditorias internas de calidad y sus resultados deben ser documentados.

Revisión de Contratos

Acciones correctivas y preventivas.

Control de los registros

Estadísticas La empresa debe mantener un registro de estadísticas adecuadas para verificar el estado del proceso.

G A R C I A

La empresa debe asegurar que los productos no se utilicen o procesen hasta que sean inspeccionados y verificados.

Los productos que no cumplan los requerimientos, especificados no deben ser instalados, usados o puestos en producción.

La empresa debe establecer y mantener procedimientos para identificar las necesidades de capacitación y proveer entrenamiento a todo el personal, que además debe ser calificado con base a su educación, entrenamiento o experiencia.

B E T A N I A

Inspección y pruebas.

Control del producto no conforme.

Capacitación

P O R

Control de Documentos y Datos

Esta clausula exige la definición de un proceso disciplinado o metodología.

Control, Calibración y Mantenimiento de los equipos de inspección, medición y pruebas utilizados por la empresa.

de calidad.

9 0 0 0 - 3

De esta forma asegurar que la empresa tiene la capacidad de cumplir con todos los requerimientos contractuales.

Planificación del diseño y el desarrollo

Se deben establecer y mantener registros que contengan el criterio de aceptación del producto.

I S O

La empresa debe establecer y mantener procedimientos para la revisión de los contratos y para la coordinación de estas actividades.

La empresa debe establecer y mantener procedimientos para controlar todos los documentos y datos.

Todo documento debe estar disponible, y los documentos obsoletos deben ser removidos.

Y

ISO 9000-3 y otros estándares

D R E Y G O N Z A L E Z

AUTOR: BETANIA GARCIA

5

PRINCIPALES CARACTERÍSTICAS EL MODELO DE MADUREZ DE LA CAPACIDAD (CMM) Y LOS MÉTODOS MÁS REPRESENTATIVOS DE EVALUACIÓN Y MEJORA ASOCIADOS

R O D R I G U E Z

Métodos más representativos de evaluación y mejora asociados

L U I S A

1. CMM (CAPABILITY MATURITY MODEL) MODELO DE MADUREZ DE CAPACIDADES

CMM proporciona a las organizaciones de software: el modelo de referencia necesario como soporte para el control de sus procesos de desarrollo y mantenimiento. facilita su evolución hacia una cultura de la Ingeniería del Software y de excelencia en la gestión.

SEI, Software Engineering Institute Instituto de Ingeniería del Software proporcionar la base

necesaria para mejorar el desarrollo del software considerando a las tareas de desarrollo del software como una serie de procesos que se pueden: definir, medir y controlar.

Como resultado se han obtenido modelos de referencia de la capacidad de los procesos y modelos de evaluación de dicha capacidad.

Evaluar la madurez de los procesos de desarrollo de software dentro de una organización.

Proponer un plan de mejora de los procesos de desarrollo de software de acuerdo a una serie de niveles.

Y para este fin se han propuesto 5 niveles:

MODELO DE MADUREZ DE LA CAPACIDAD (CMM)

• • • • • •

INICIAL REPETIBLE DEFINIDO GESTIONADO OPTIMIZADO MODELO DE MADUREZ DE LA CAPACIDAD (CMM)

Es un modelo con la finalidad de:

T E O R I A

D E

L A

I N F O R M A C I O N

-

CMM (SEI, 1995) es el modelo propuesto por el SEI como referencia para determinar la capacidad de los

procesos software de una organización.

6

AUTOR:DREY GONZALEZ

MODELO DE MADUREZ DE LA CAPACIDAD (CMM)

I S O

9 0 0 0 - 3

P O R

B E T A N I A

G A R C I A

Y

D R E Y

G O N Z A L E Z

7

AUTOR: BETANIA GARCIA

ISO/IEC 15504 Software Process Improvement Capability Determination

T E O R I A

D E

L A

I N F O R M A C I O N

-

L U I S A

R O D R I G U E Z

abreviado SPICE, en español, «Determinación de la Capacidad de Mejora del Proceso de Software»

E

s un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software.

IEC 15504 – Tecnologías de la Información – Evaluación de Procesos (‘ISO/IEC 15504 – Information Technology – Process Assessment’).

Las siglas SPICE significan: Software Process Improvement and Capability Determination, es decir, Determinación de la capacidad y mejora de los procesos de software.

El proyecto SPICE tenía tres

objetivos principales: Desarrollar un borrador de trabajo para un estándar de evaluación de procesos de software.

En 1991, dado el número creciente dre). Por tanto, el proyecto SPICE fue creado bajo los auspicios del Comité Internacional de estándares de Ingeniería de Software y Sistemas a través de su Grupo de Trabajo sobre Evaluación de proceso (WG10).

En 1992, el informe del grupo de estudio dijo que: “...la comunidad internacional debería poner recursos para desarrollar un estándar para la evaluación de procesos software, incorporando lo mejor de los métodos de evaluación de procesos existentes.”

ISO decidió entonces se hiciera el desarrollo por pasos de un estándar para la evaluación de procesos. Los pasos fueron los siguientes: Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de estándar”) para que después de su uso real pasase a Revisión y publicación como estándar internacional IS ISO/ 8

Llevar a cabo los ensayos de la industria de la norma emergente.

Promover la transferencia de tecnología de la evaluación de

CARACTERÍSTICAS

Establece un marco y los requisitos para cualquier fase de evaluación de procesos y proporciona requisitos para los modelos de evaluación de estos.

Proporciona también requisitos para cualquier modelo de evaluación de organizaciones.

Proporciona guías para la definición de las competencias de un evaluador de procesos.

Actualmente tiene 10 partes: de la 1 a la 7 completas y de la 8 a la 10 en fase de desarrollo. Comprende:

evaluación de procesos, mejora de procesos, determinación de capacidad.

Proporciona, en su parte 5, un Modelo de evaluación de procesos para las fases de ciclo de vida del software definidos en el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. Proporciona, en su parte 6, un Modelo de evaluación de procesos para las etapas de ciclo de vida del sistema, definidos en el estándar ISO/IEC 15288

AUTOR:DREY GONZALEZ

MODELO DEL SISTEMA procesos de software a la industria del software a nivel mundial.

El primer objetivo del proyecto se logró en junio de 1995, con la entrega del borrador de trabajo de la norma para la evaluación de procesos de software al WG10 para su votación entre la comunidad de estandarización internacional. El Borrador de Trabajo se denominaba comúnmente como el conjunto de documentos SPICE (o SPICE Versión 1).

ISO/IEC 15504 - 5 MODELO DE EVALUACIÓN DE PROCESOS DE CICLO DE VIDA DE SOFTWARE

G A R C I A

Por ejemplo, el modelo de evaluación de procesos de software, contenido en la Parte 5 de la Norma ISO/IEC 15504 define el Modelo de procesos de referencia como los procesos contenidos en la norma ISO/IEC 12207 Amd1/ Amd2, que contienen tres categorías de procesos y cada una con diferentes grupos de procesos:

Y D R E Y G O N Z A L E Z

Con el fin de apoyar la excelencia y la coherencia de la formación de los evaluadores, el proyecto SPICE también desarrolló y lanzó un Plan de Estudios de formación de los evaluadores SPICE que es utilizado actualmente por el Esquema de Registro Internacional de Evaluadores (IntRSA) – www.intrsa.org. En el capítulo de ‘Roles’ se desarrollan los detalles de

B E T A N I A

En este momento se efectúan actividades promocionales que se realizan a través de la Conferencia Internacional Anual SPICE y la publicación de artículos y libros.

P O R

En marzo de 2003, el proyecto SPICE se cerró oficialmente. La Red SPICE se estableció posteriormente con el encargo de seguir coordinando las actividades de la comunidad SPICE. La Red de SPICE está formalmente organizada por el ‘The Spice User Grupo’ (www.spiceusergroup.org).

Nivel 0: Incompleto Nivel 1: Realizado Nivel 2: Gestionado Nivel 3: Establecido Nivel 4: Predecible Nivel 5: En optimización Para cada nivel existen unos atributos de procesos estándar que ayudan a evaluar los niveles de capacidad.

9 0 0 0 - 3

Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto SPICE durante el período 1994 a 1998. Fue entonces, en 1998 cuando se publicó la primera familia de estándares ISO TR 15504. En aquel momento se comenzó a trabajar en la versión “Internacional Standard” de la norma, y desde 2006 está completamente publicado, exceptuadas las partes nuevas que se estén produciendo.

Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Define que todo modelo de evaluación de procesos debe definir: - la dimensión de procesos: el modelo de procesos de referencia (dimensión de las abscisas) - la dimensión de la capacidad: niveles de capacidad y atributos de los procesos. Los niveles de capacidad para todo modelo de evaluación de procesos pueden tener desde el 0 y al menos hasta el nivel 1 de los siguientes niveles de capacidad estándar:

I S O

Este primer borrador se basó en modelos existentes en aquél momento.

DIMENSIONES

BIBLIOGRAFIA https://es.wikipedia.org/wiki/ISO/IEC_15504 https://prezi.com/yoj8wozwl3sh/evaluacion-ymejora-de-procesos/ www.portalcalidad.com/foros/561-norma_ iso_90003 https://es.wikipedia.org/wiki/Usuario:LA_ CALIDAD_DEL_SOFTWARE

AUTOR: BETANIA GARCIA

9

10

T E O R I A

D E

L A

I N F O R M A C I O N

-

L U I S A

R O D R I G U E Z