• Author / Uploaded
• Josue Lagos

Citation preview

INGENIERIA DE SOFTWARE

Tarea #1

Sección: 982 Docente: Lic. Lourdes Mendoza Nombre: Humberto Zelaya Número de cuenta: 31221352

INGENIERIA DE SOFTWARE

MÉTODO DE EVALUACIÓN DEL ESTÁNDAR CMMI PARA EL PROCESO DE MEJORA (SCAMPI) CMMI es el acrónimo de Capability Maturity Model Integration y se refiere a los modelos que contienen las mejores prácticas que ayudan a las organizaciones a mejorar sus procesos. Han sido desarrollados por equipos de trabajo formados por especialistas de la industria, el gobierno y el Software Engineering Institute (SEI) que transfirió los derechos al CMMI Institute para su operación y comercialización. Siendo un modelo refleja una abstracción de la realidad que permite a las organizaciones adoptar prácticas útiles para alcanzar sus objetivos de negocio, constituye una referencia no es un proceso en sí. Para establecer una analogía, querer adaptar la organización al modelo es como si al ver una maqueta de una casa una persona deseara vivir en ella. La adecuada interpretación del modelo para cubrir las diferentes situaciones, necesidades y objetivos de una organización son esenciales para lograr los resultados que se quieren. Muchas veces por desconocimiento o por falta de sentido común o criterio, el resultado no es lo esperado. QUE ES CMMI Es una guía que ayuda en la mejora de procesos, pero como en cualquier receta cada quién le puede poner de su propio sazón. El enfoque del modelo permite evolucionar desde un proceso en crisis a un proceso controlado, estandarizado, medido y optimizado que sienta las bases de la mejora continua y permite a la organización adoptar nuevas prácticas sobre un proceso estable y controlado que está institucionalizado.

· · ·

Según el modelo que se utilice se puede obtener el documento con un conjunto de guías que ayudan en: Desarrollo y mantenimiento de productos y servicios (CMMI DEV), Adquisición de productos y servicios (CMMI ACQ) y Establecimiento, entrega y gestión de los servicios (CMMI SVC). Contiene elementos esenciales de un proceso efectivo y propone una forma de adopción para las organizaciones que permite incrementar la calidad y productividad, al tiempo que controla el presupuesto y los compromisos establecidos. Cada una debe interpretar, adoptar y aplicar aquellas prácticas que le apoyan en el logro de sus objetivos y cumplimiento de sus necesidades de manera eficiente.

INGENIERIA DE SOFTWARE

Considera dos enfoques o rutas para adoptar las mejoras y medir el nivel en que han evolucionado y se conocen como representaciones. En una forma se consideran áreas de proceso de manera individual y se califican en niveles de capacidad de acuerdo con la representación continua. El otro enfoque considera un conjunto preestablecido de áreas de proceso que constituyen un nivel de madurez y que es la forma de evaluar la representación escalonada o por etapas. Está estructurado para facilitar su uso en elementos que definen la forma y modo de aplicarlo, considerando los elementos que son obligatorios, sugeridos o el material informativo en las áreas de proceso. En general el documento se puede revisar en función de metas, prácticas y sus prácticas con el resto del material informativo. Es utilizado por las organizaciones para entender las mejores prácticas de la industria, para priorizar y adoptar las mejoras a los procesos existentes, para compararse con su competencia dentro del mercado o para que los clientes puedan identificar las prácticas que necesitan demostrar sus proveedores Método de evaluación del estándar CMMI para el proceso de mejora (SCAMPI, por sus siglas en inglés): proporciona un modelo de cinco fases para evaluar el proceso: inicio, diagnóstico, establecimiento, actuación y aprendizaje. El método SCAMPI emplea el SEI CMMI como la base de la evaluación

INGENIERIA DE SOFTWARE

EVALUACIÓN BASADA EN CMM PARA LA MEJORA DEL PROCESO INTERNO (CBA IPI) Proporciona una técnica de diagnóstico para evaluar la madurez relativa de una organización de software; usa el SEI CMM como la base de la evaluación. Este sistema denominado CBA IPI (por su sigla en inglés CMM based appraisal for internal process improvement) fue creado como respuesta a las necesidades de los usuarios de un método de valorización basado en CMMI. la evolución que ha tenido desde su inicio hasta la actualidad, es de la siguiente forma: fue desarrollado y probado en 1994. En mayo de 1995, después de acumular lecciones aprendidas de la retroalimentación de la comunidad, fue liderada la versión 1.0 y después, el método y la documentación fueron actualizados en marzo de 1996, dando como resultado el CBA IPI versión 1.1 Este método implícitamente usa el CMM versión 1.1 como modelo de referencia. La recopilación de datos está basada tanto en las áreas claves del proceso (KPAs) de CMM como asuntos no relacionados con CMM. Está diseñado para establecer la consistencia de largo de las valoraciones de CMM para que los resultados de una valoración puedan ser comparados con otros de una previa. Los componentes y detalles de este método. Facilita a una organización conocer la capacidad de sus procesos software mediante la identificación de las fortalezas y debilidades. Con el fin de establecer y dar prioridad a planes de mejora software. Consiste en la evaluación de la capacidad del proceso software de una organización a través de un grupo de profesionales adecuadamente entrenados que trabajan como un equipo. El método de evaluación interna utilizado en SW-CMM se denomina Evaluación Basada en CMM para Mejora del Proceso Interno (CMM-Based Appraisal for Internal Process Improvement, CBA IPI). Se trata de un método que saca a relucir los puntos fuertes y débiles del actual proceso del software de la organización, utilizando CMM como modelo de referencia, y que también sirve para que la organización se comprometa a mejorar su proceso del software.

INGENIERIA DE SOFTWARE

Las medidas que se llevan a cabo se encuadran en la fase de diagnóstico de IDEAL para la mejora del proceso del software. CBA IPI está actualmente en su versión 1.2 y cumple los requisitos CAF Este método se lleva a la práctica por un supervisor de evaluación interna CBA IPI autorizado por el SEI.

EL MODELO DE PROCESOS ISO/IEC 15504 – ISO/IEC 12207:2008 Normalmente, en la mejora de la calidad de los procesos participan dos tipos de modelos, el modelo de procesos y el modelo de evaluación. El modelo de procesos define un catálogo o colección estructurada de buenas prácticas que describen las características de un proceso efectivo, mientras que el modelo de evaluación proporciona los principios requeridos para realizar una evaluación de la calidad, e implantación, de dicho modelo de procesos en una organización, en el modelo objeto de este estudio, se hace uso del modelo de procesos ISO/IEC 12207:2008 (uno de los modelos de procesos de referencia para la industria del software), y de la norma ISO/IEC 15504 como modelo de evaluación. Mejora de la calidad de los procesos software.

La norma ISO/IEC 15504, en su parte 7, describe las bases para llevar a cabo evaluaciones por niveles de madurez, para lo cual describe un conjunto de niveles. En concreto, establece 6 niveles de madurez para mejorar y evaluar a las organizaciones, desde el 0 hasta el 5, siendo el 0 el nivel inferior y el 5 el superior. La parte 7 de dicha norma sólo describe los niveles, y no los procesos a superar en cada uno de ellos (salvo en algunos anexos donde muestra ejemplos que pueden servir de guía). La Tabla 1 muestra un ejemplo de los procesos definidos para los niveles 1 y 2.

INGENIERIA DE SOFTWARE

· · ·

·

·

Normalmente, tiene un menor coste de certificación que otros modelos similares (Ver Informe de INTECO). Existen certificaciones de prestigio, como por ejemplo la otorgada por AENOR. Proporciona un modelo de evaluación de procesos para los procesos 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 un modelo de evaluación de procesos para los procesos 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. Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI y viceversa, y se 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). Procesos de los niveles de madurez 1 y 2 del modelo de evaluación y mejora de procesos software ISO/IEC 15504 – ISO/IEC 12207:2008. Los procesos del nivel 1 y 2 son los mismos, con la salvedad de que para ir de un nivel 1 al 2 debe mejorar la capacidad de los mismos, o gestión de procesos que hace la organización. Por otro lado, cada uno de los anteriores procesos se

INGENIERIA DE SOFTWARE

descompone en “outcomes”, descompone dicho proceso.

que

describen

características

en

que

se

VENTAJAS DE LA NORMA SPICE/ISO/IEC 15504 Primer modelo de procesos de dosdimensiones, es decir, dimensionesindependi entes para los procesos y la capacidad

- El resultado de una evaluación de proceso puede ser representado por un perfil de proceso.

- Es el modelo más consensuado y probado

- Mayor reconocimiento en el mercado Europeo.

- Coherencia con otros modelos de calidad ya implementados en la organización ISO9001- ISO 20000- ISO 27000.

- Menores costos de la certificación Desventajas de la norma SPICE/ISO/IEC 15504 ISO/IEC TR-15504 permite que el dominio de procesos sea tan amplio para abarcar todos los posibles ciclos de vida, de tal manera que hace difícil que todos los atributos de proceso sean universales, provocando dificultad y confusión durante la evaluación. Poco reconocimiento en el mercado Norteamericano.

· · · ·

¿Qué ventajas aporta esta norma a las empresas de desarrollo y mantenimiento software? Pueden contar con una norma ISO, internacional y abierta. La norma cuenta con el respaldo del Ministerio de Industria de España ya que existen ayudas para la certificación de las PYMES y de AENOR. Integración más fácil con otras normas ISO del sector TIC, como son: ISO 27000 de seguridad, ISO 20000 de servicios de IT e ISO 9000. Evalúa por niveles de madurez, la evaluación más extendida entre los modelos de mejora.

INGENIERIA DE SOFTWARE

El CMM - CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software. ISO12207 Esta norma está orientada a los procesos de ciclo de vida del software de la organización ISO. Establece un proceso de ciclo de vida para el software que incluye procesos y actividades que se aplican desde la definición de requisitos, pasando por la adquisición y configuración de los servicios del sistema, hasta la finalización de su uso. ISO9001: 2000 PARA SOFTWARE La Norma ISO 9001:2008 elaborada por la Organización Internacional para la Estandarización (ISO), determina los requisitos para un Sistema de gestión de la calidad (SGC) que pueden utilizarse para su aplicación interna por las organizaciones, sin importar si el producto o servicio lo brinda una organización pública o empresa privada, cualquiera que sea su tamaño, para su certificación o con fines contractuales. Dependiendo del país, puede denominarse la misma norma "ISO 9001" de diferente forma agregándose la denominación del organismo que la representan dentro del país: UNE-EN-ISO 9001:2008 (España), IRAM-ISO 9001:2008, etc., acompañada del año de la última actualización de la norma. ISO 9001: Contiene los requisitos del modelo de gestión. ISO 9004: Contiene a la antigua ISO 9001, y además amplía cada uno de los puntos con más explicaciones y casos, e invita a los implantadores a ir más allá de los requisitos con nuevas ideas, esta apunta a eficiencia del sistema. ISO 19011 en su nueva versión 2011: detalla los requisitos para la realización de las auditorías de un sistema de gestión ISO 9001 y también para el sistema de gestión medioambiental establecido en ISO 14001. ESTRUCTURA DE ISO 9001:2008 Capítulo 1 al 3: Guías y descripciones generales. Capítulo 4 Sistema de gestión: contiene los requisitos generales y los requisitos para gestionar la documentación. Capítulo 5 Responsabilidades de la Dirección: contiene los requisitos que debe cumplir la dirección de la organización, tales como definir la política, asegurar que las responsabilidades y autoridades están definidas, aprobar objetivos, el compromiso de la dirección con la calidad, etc.

INGENIERIA DE SOFTWARE

Capítulo 6 Gestión de los recursos: la Norma distingue 3 tipos de recursos sobre los cuales se debe actuar: RRHH, infraestructura, y ambiente de trabajo. Aquí se contienen los requisitos exigidos en su gestión. Capítulo 7 Realización del producto/servicio: aquí están contenidos los requisitos puramente de lo que se produce o brinda como servicio (la norma incluye servicio cuando denomina "producto"), desde la atención al cliente, hasta la entrega del producto o el servicio. Capítulo 8 Medición, análisis y mejora: aquí se sitúan los requisitos para los procesos que recopilan información, la analizan, y que actúan en consecuencia. El objetivo es mejorar continuamente la capacidad de la organización para suministrar productos y/o servicios que cumplan con los requisitos. El objetivo declarado en la Norma, es que la organización busque sin descanso la satisfacción del cliente a través del cumplimiento de los requisitos. ISO 9001:2008 tiene muchas semejanzas con el famoso “PDCA”: acrónimo de Plan, Do, Check, Act (Planificar, Hacer, Verificar, Actuar). [cita requerida] La norma está estructurada en cuatro grandes bloques, completamente lógicos, y esto significa que con el modelo de sistema de gestión de calidad basado en ISO se puede desarrollar en su seno cualquier actividad, sin importar si el producto o servicio lo brinda una organización pública o privada, cualquiera que sea su tamaño. La ISO 9000:2000 (Norma obsoleta) se va a presentar con una estructura válida para diseñar e implantar cualquier sistema de gestión, no sólo el de calidad, e incluso, para integrar diferentes versiones. LA NUEVA ISO 9001:2015 Desde junio del 2012 se inició la revisión de la versión actual de la norma; la intención es hacer una renovación mayor. Se busca que con el uso y certificación de esta norma las empresas sean más competitivas para el año 2020. Según el INLAC la norma cambiará en un 30%, respecto a la versión 2008; teniendo una estructura de alto nivel, incorporando dos nuevos requisitos quedando su estructura de la siguiente manera  Alcance 

Referencias Normativas



Términos y Definiciones



Contexto de la Organización  

Planificación 



Liderazgo Soporte

Operación1| Evaluación del Desempeño

INGENIERIA DE SOFTWARE



Mejora

El proceso de revisión de la norma ISO 9001 inicia su fase final, después de que el pasado 3 de junio se publicara el borrador de la ISO 9001:2015, elaborado por el comité técnico ISO/TC 176 responsable de elaborar las normas de ISO 9000 y complementarias. Siguiendo la planificación prevista, el FDIS (borrador final) se publicará en noviembre de 2014 para poder publicar definitivamente la nueva versión de la norma en el otoño del año 2015. DIFERENCIAS ENTRE LA VERSIÓN 2008 Y LA VERSIÓN 2015

·

·

·

·

Según el borrador publicado por la organización ISO, se pueden apreciar cambios sustanciales en la nueva versión con respecto a la versión de 2008. Estos cambios, según las comparaciones que se han podido realizar al respecto, abordan los siguientes aspectos: Mejora la redacción hacia un enfoque más general y adaptado a las entidades de servicios. Se centra en la planificación y el liderazgo y cambiando el término "realización de productos" por el de "operaciones". Énfasis en el enfoque basado en procesos. La nueva versión cuenta con una cláusula específica donde se define un conjunto de requisitos para que una entidad adopte este enfoque basado en procesos. De acciones preventivas a prevención a más alto nivel. El apartado donde en la antigua versión se habla sobre esto desaparece. Sin embargo, se habla de la prevención a mayor escala, en coherencia con nuevos puntos sobre la gestión del riesgo, aspecto que se aborda con más profundidad. Cambios terminológicos:

· Los términos "documento" y "registro" se sustituyen por el de "información documentada". · El término "cliente" pasa a denominarse "parte interesada", lo que cuadra con un nuevo enfoque hacia la calidad total y los modelos de Excelencia empresarial. · Más detalle en la Gestión del Cambio: También muy relacionado con losmodelos de Excelencia está el apartado sobre "Planificación y control de cambios", con mejoras sobre la versión actual. Publicado por DANNA PAOLA SALCEDO ROJAS en 18:51 No hay comentarios: Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest

INGENIERIA DE SOFTWARE

SPICE (ISO/IEC 15504)

Estándar que define un conjunto de requerimientos para la evaluación del proceso del software. El objetivo del estándar es ayudar a las organizaciones a desarrollar una evaluación objetiva de cualquier proceso del software definido [ISO08]. 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. En 1991, dado el número creciente . 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/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:

INGENIERIA DE SOFTWARE

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). Este primer borrador se basó en modelos existentes en aquél momento. 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. 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’ 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. 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) . 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. 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.

INGENIERIA DE SOFTWARE

·

·

· ·

· · · · · ·

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