12
COMPENDIO ISO 12207

Compendio 1ºk nº 2 erick stanley amaya amaya

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Compendio 1ºk nº 2 erick stanley amaya amaya

COMPENDIO

ISO 12207

Page 2: Compendio 1ºk nº 2 erick stanley amaya amaya

ISO/IEC 12207 Information Technology / Software Life Cycle Processes, es el estándar para los procesos de ciclo de vida del software de la organización ISO.

La estructura del estándar ha sido concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use. Para conseguirlo, el estándar se basa en dos principios fundamentales: Modularidad y responsabilidad. Con la modularidad se pretende conseguir procesos con un mínimo acoplamiento y una máxima cohesión. En cuanto a la responsabilidad, se busca establecer un responsable para cada proceso, facilitando la aplicación del estándar en proyectos en los que pueden existir distintas personas u organizaciones involucradas, no importando el uso que se le dé a este.

Los procesos se clasifican en tres tipos: Procesos principales, procesos de soporte y procesos de la organización. Los procesos de soporte y de organización deben existir independientemente de la organización y del proyecto ejecutado. Los procesos principales se instancian de acuerdo con la situación particular.

Procesos principales.

Adquisición.

Suministro.

Desarrollo.

Operación.

Mantenimiento.

Procesos de soporte.

Documentación

Gestión de la configuración.

Aseguramiento de calidad.

Verificación.

Validación.

Revisión conjunta.

Auditoría.

Resolución de problemas.

Procesos de la organización.

Gestión.

Infraestructura.

Mejora.

Recursos Humanos.

ISO 15504

Page 3: Compendio 1ºk nº 2 erick stanley amaya amaya

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

El ISO/IEC 15504, también conocido como Software Process Improvement Capability Determination, abreviado SPICE, en español, «Determinación de la Capacidad de Mejora del Proceso de Software» es un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software.

ISO decidió entonces se hiciera el desarrollo por pasos de un estándar para la evaluación de procesos. Los pasos fueron los siguientes:

1. Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de estándar”) para que después de su uso real pasase a

2. Revisión y publicación como estándar internacional IS ISO/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.

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

Promover la transferencia de tecnología de la evaluación de 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)

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.

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

Page 4: Compendio 1ºk nº 2 erick stanley amaya amaya

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.

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 cualificación y responsabilidades de diferentes roles que se necesitan en los procesos de evaluación y/o mejora.

CARACTERISTICAS

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 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de sistemas.

Proporcionará, en su parte 8, un Modelo de evaluación de procesos para los procesos de servicios TIC que serán definidos en el estándar ISO/IEC 20000-4 que definirá los procesos contenidos en la norma ISO/IEC 20000-1.

Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con 15504. Sin embargo CMMI-DEV aún no es un modelo conforme con esta norma (según lo requiere la norma ISO 15504 para todo modelo de evaluación de procesos).

DIMENSIONES

Page 5: Compendio 1ºk nº 2 erick stanley amaya amaya

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:

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.

ISO 25000

Page 6: Compendio 1ºk nº 2 erick stanley amaya amaya

El objetivo general de la creación del estándar ISO/IEC 25000 SQuaRE (Software Product Quality Requirements and Evaluation) es organizar, enriquecer y unificar las series que cubren dos procesos principales: especificación de requisitos de calidad del software y evaluación de la calidad del software, soportada por el proceso de medición de calidad del software.

Las características de calidad y sus mediciones asociadas pueden ser útiles no solamente para evaluar el producto software sino también para definir los requerimientos de calidad. La serie ISO/IEC 25000:2005 reemplaza a dos estándares relacionados: ISO/IEC 9126 (Software Product Quality) e ISO/IEC 14598 (Software Product Evaluation).

DIVISIONES

ISO/IEC 2500n. División de gestión de calidad. Los estándares que forman esta división definen todos los modelos comunes, términos y referencias a los que se alude en las demás divisiones de SQuaRE.

ISO/IEC 2501n. División del modelo de calidad. El estándar que conforma esta división presenta un modelo de calidad detallado, incluyendo características para la calidad interna, externa y en uso.

ISO/IEC 2502n. División de mediciones de calidad. Los estándares pertenecientes a esta división incluyen un modelo de referencia de calidad del producto software, definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas para la calidad de software interna, externa y en uso.

ISO/IEC 2503n. División de requisitos de calidad. Los estándares que forman parte de esta división ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto software que va a ser desarrollado ó como entrada para un proceso de evaluación. El proceso de definición de requisitos se guía por el establecido en la norma ISO/IEC 15288 (ISO, 2003).

ISO/IEC 2504n. División de evaluación de la calidad. Estos estándares proporcionan requisitos, recomendaciones y guías para la evaluación de un producto software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores.

ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen requisitos para la calidad de productos de software “Off-The-Self” y para el formato común de la industria (CIF) para informes de usabilidad.

Se han reservado los valores desde ISO/IEC 25050 hasta ISO/IEC 25099 para extensiones y "Technical Reports".

Page 7: Compendio 1ºk nº 2 erick stanley amaya amaya

CONTENIDO DE SQUARE

Términos y definiciones

Modelos de referencia

Guía general

Guías por división

Estándares internacionales para especificación de requerimientos, planificación y gestión, medición y evaluación de la calidad del producto.

ISO/IEC Nombre Stage Status

25000:2005 Guide to SQuaRE 60.60 Published

25001:2007 Planning and management 60.60 Published

25010:2011 Quality model and guide 60.60 Published

25012:2008 Data Quality model 60.60 Published

25020:2007 Measurement reference model and guide 60.60 Published

TR 25021:2007

Quality Measure elements 60.60 Published

25030:2007 Quality Requirements 60.60 Published

FDIS 25045 Evaluation module for recoverability 50.20Under Development

25051:2006Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing

60.60 Published

DTR 25060Common Industry Format (CIF) for Usability -- General Framework for Usability-related Information

40.20Under Development

25062:2006Common Industry Format (CIF) for usability test reports

60.60 Published

LA CMMI

Page 8: Compendio 1ºk nº 2 erick stanley amaya amaya

Integración de modelos de madurez de capacidades o Capability maturity model integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios.

La versión actual de CMMI es la versión 1.3 la cual corresponde a CMMI-SVC, liberada el 1 de noviembre de 2010. Hay tres constelaciones de la versión 1.2 disponible:

CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.

CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.

CMMI (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.

Dentro de la constelación CMMI-DEV, existen dos modelos:

CMMI-DEV

CMMI-DEV + IPPD (Integrated Product and Process Development)

Independientemente de la constelación\modelo que opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio.

Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organización es evaluada (por ejemplo, usando un método de evaluación como SCAMPI y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez (si bien se comienza con el nivel 2). En caso de que quiera la organización, puede coger áreas de proceso y en vez de por niveles de madurez puede obtener los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la Organización.

METRICA V3

Page 9: Compendio 1ºk nº 2 erick stanley amaya amaya

MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistemas de información, promovida por el Ministerio de Hacienda y Administraciones Públicas (antiguo Ministerio de Administraciones Públicas ) del Gobierno de España para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE.

VERSIONES

Versión 1 - 1989

Versión 2 - 1993

Versión 2.1 - 1995

Versión 3 - 2001.

ELEMENTOS FUNDAMENTALES

Procesos

Interfaces

Técnicas y Prácticas

Roles o Perfiles

Recursos

Al igual que ISO/IEC 12207, MÉTRICA está orientada al proceso y, en su versión 3, estos procesos son:

Planificación de Sistemas de Información (PSI). (No está cubierto por ISO/IEC 12207)

Desarrollo de Sistemas de Información (DSI). Debido a su complejidad, está a su vez dividido en cinco procesos:

Estudio de Viabilidad del Sistema (EVS).

Análisis del Sistema de Información (ASI).

Diseño del Sistema de Información (DSI).

Construcción del Sistema de Información (CSI).

Implantación y Aceptación del Sistema (IAS).

Mantenimiento de Sistemas de Información (MSI).

Page 10: Compendio 1ºk nº 2 erick stanley amaya amaya

MÉTRICA, en su versión 3, proporciona también cuatro interfaces que definen actividades orientadas a la mejora y perfeccionamiento de los procesos principales para garantizar la consecución del objetivo del desarrollo.

Gestión de proyectos (GP).

Seguridad (SEG).

Aseguramiento de la Calidad (CAL).

Gestión de la Configuración (GC).

MÉTRICA, en su versión 3, distingue entre:

Técnicas de desarrollo (Casos de Uso, Diagramas de Clases, Diagrama de flujo de datos,...).

Técnicas de gestión de proyectos (Técnicas de estimación, Staffing Size, Planificación,...)

Prácticas (Análisis de impacto, Presentaciones, Prototipado,...)...

MÉTRICA establece los siguientes perfiles para los participantes en el proceso de desarrollo de un sistema de información:

Directivo (Comité de Dirección, Directores de Usuarios,...).

Jefe de Proyecto (Responsable de Implantación, Responsable de Seguridad,...).

Consultor (Consultor Informático, Técnico de Sistemas).

Analista (Analista, Administrador de Bases de Datos,...).

Programador.