Proyecto final by Fredy Martinez

CMMI SERVICIOS Y DESARROLLO

STEPVEN ANTONIO RINCON VELASCO 624464 FREDY ANDRES MARTINEZ ARENAS 624480

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS BOGOTA 2010

CMMI SERVICIOS Y DESARROLLO

STEPVEN ANTONIO RINCON VELASCO 624464 FREDY ANDRES MARTINEZ ARENAS 624480

PROFESOR: GERMAN CUBILLOS CARTAGENA

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS BOGOTA 2010

Tabla de Contenido INTRODUCCIร N ....................................................................................................................... 4

1. 2.

PROBLEMA................................................................................................................................. 5 OBJETIVOS ............................................................................................................................ 7 4. 5.

MARCO TEORICO ...........................................................................................................................8 MARCO CONCEPTUAL ...........................................................................................................17 6. BIBLIOGRAFIA ....................................................................................................................18 7. ANEXOS .............................................................................. ยกError! Marcador no definido.

1. INTRODUCCIÓN

CMMI representa la fusión de un conjunto de modelos orientados a la mejora de procesos de ingeniería del software, ingeniería de sistemas, desarrollo de productos y adquisición de aplicaciones. Creado en 1991 por el Software Engineering Institute (SEI) como CMM y posteriormente actualizado como CMMI en 2002, está orientado a la garantía de calidad del software, y a la acreditación de empresas desarrolladoras de software en función del nivel de madurez de sus procesos de producción. Su implementación aumenta la fiabilidad del software producido, la visibilidad de los procesos de producción y soporte, la reusabilidad de componentes, y como resultado de la combinación de este tipo de mejoras, disminuye los costes de producción y mantenimiento de las aplicaciones. El modelo CMMI (Modelo integrado de madurez de la capacidad) se usa para evaluar el nivel de madurez de una compañía en términos de desarrollo informático. CMMI, una versión más amplia, se basa en CMM, adopta la mayoría de sus conceptos y ofrece los índices de referencia de las mejores prácticas para el desarrollo de software. El objetivo es alentar a las compañías para que monitoreen y mejoren continuamente sus procesos, y evalúen el nivel de madurez de los mismos en una escala de cinco niveles establecida por el CMMI.

2. PROBLEMA a) Identificación: El problema fundamental es que se han consolidado en las empresas procesos informales y poco estructurados que propician un desarrollo poco predecible y repetible.

b) Descripción:

El CMMI es un proceso el cual detalla cada paso del objetivo de la empresa esto es de gran utilidad puesto que sabemos lo que puede ocurrir dado cualquiera de los casos planteados en un proyecto. Sin embargo al ser el CMMI tan detallado normalmente requiere mucho más tiempo del esperado y por supuesto costo, en este caso nos enfocaremos más en los detalles del CMMI pues el verdadero inconveniente se presenta cuando estos detalles se involucran en el objetivo de la empresa, tantos detalles hacen que se pierda el objetivo a alcanzar en la empresa, y si no es detallado el objetivo puede no ser alcanzado y la empresa ir en perdidas.

c) Formulación:

¿ como saber si un ciclo de CMMI se cumple con los detalles requeridos y necesarios, al saber que pueden ser infinitos, pero que también algunos son irrelevantes o no tan importantes y lo único que logran es gastar tiempo y costo en la implementación del objetivo que esta orientado hacia la realización del un software? Su implementación seria optima si este sistema tuviera un limite en el cual se llegara a tener un estándar en cuanto al detalle pero el CMMI perdería su esencia, pues en si es un modelo que se basa en el detalle de los objetivos requeridos por la empresa.

d) Justificación del problema:

Los problemas que tienen las empresas desarrolladoras de software al iniciar un proyecto, radica en que el tiempo de vida del proyecto y el presupuesto que son estimados al principio del proyecto, es por eso que el CMMI por medio de sus niveles de madurez tiene la capacidad de evaluar estas dificultades, pero sus inconvenientes surgen a la hora de resolver cada nivel y llevarlo a otro el cual sea optimo para la empresa y sea la mejor decisión. En sus niveles de madurez cada nivel posee ciertas características las cuales cada una posee sus propios detalles, estos detalles se hacen cada instantes más minuciosos aparentemente para describir totalmente lo que el usuario requiere en los objetivos del software. Sus detalles en cada nivel hacen que este sea dinámico de esta misma manera el objetivo empieza a cambiar y puede que este cambie tan radicalmente que no cumpla nunca lo propuesto en un principio y este objetivo se pierda en el transcurso del tiempo.

3. OBJETIVOS a. GENERAL: Crear una metodología demás que se integre al CMMI, que en la hora de detallar un software en una empresa, este detalle sea valido, óptimo, priorizando cada detalle del mas necesario al no tan necesario, dejando solo los detalles que requiere una empresa para el logro del objetivo y no otros procesos que quitarían tiempo y costo.

b. ESPECIFICOS 

Detallar cada proceso según el nivel de madurez, involucrando solo los detalles necesarios.



Estandarizar el máximo de detalles para no correr el riesgo de desviarse del objetivo final



Priorizar cada detalle de los niveles del CMMI

4. MARCO TEORICO 1

El modelo americano Capability Maturity Model Integration (CMMI), creado por

el Software Engineering Institute ¡Error! No se encuentra el origen de la referencia., se ha convertido en los últimos años en un modelo estándar de facto para la mejora de procesos software y está empezando a ser exigido por los clientes a la hora de contratar servicios y desarrollos de sistemas intensivos en software.

CMMI se compone de un conjunto de modelos, métodos de evaluación y cursos de formación para diseñar procesos efectivos (tiempo y coste), en distintos dominios (desarrollo de productos y servicios, adquisiciones y mantenimiento), dentro del ámbito de una organización. El modelo CMMI declara el conjunto de prácticas que se deben llevar a cabo sin detallar la forma en la que implantarlas en cada empresa. 2

Cada vez más organizaciones están luchando y alcanzando el estado de

madurez alto, pero aún queda una comprensión compartida insuficiente de la que la medición y análisis de las prácticas relacionadas son apreciados para las organizaciones de madurez alto. Aunque Capability Maturity Model® Integración (CMMI®) Ofrece orientación de alto nivel, algunas organizaciones luchan para encontrar una vía eficaz para De madurez alto, y los que han llegado se debe persistir en la evolución de sus esfuerzos en el espíritu de la mejora continua. Como resultado, las organizaciones buscan cada vez más orientación sobre lo que se necesita para alcanzar la condición de madurez CMMI alta y la forma de seguir mejorando una vez que lleguen allí.

[MARTI01]; SINOPSIS DE LOS MODELOS SW-CMM Y CMMI; JUAN PALACIO [MARTI02]; MADUREZ CMMI DE MEDICIÓN DE ALTA Y EL INFORME; CARNEGIE MELLON UNIVERSITY

En noviembre de 2010.

Será lanzada esta última versión de los modelos

CMMI 1.3 incluye cambios en el material de alta madurez y otras mejoras que satisfarán mejor las necesidades de las organizaciones que utilizan modelos de CMMI.

del

nivel

como

objetivos

genéricos.

A medida que se desarrollo la obra en la versión 1.3, una gran prioridad era aclarar la alta madurez. Llevaron a cabo una alta madurez del programa con representación mayoritaria de los participantes de dicha industria para asegurar que las mejoras representadas sean las mejores prácticas actuales en la comunidad.

A medida que el trabajo progresaba en la versión 1.3, el equipo encontró que la descripción de la versión 1.2 utilizando la representación continua es errónea. La representación continua de alta define la madurez como la aplicación de los objetivos genéricos de 4 y 5 (descrito en cuatro prácticas genéricas breve) para procesar las áreas de la misma manera que cuatro zonas de alto proceso de maduración se utilizan en la representación en escena. A medida que la empresa ha trabajado para aclarar el contenido de las cuatro áreas de alta madurez de procesos para v1.3, queda claro que los cambios debían realizarse para mejorar la alineación, la armonización de los esfuerzos de madurez alto en las dos representaciones. El Equipo de Desarrollo de Productos CMMI se comprometió a garantizar que este tipo de investigaciones se centraran todavía más y se puede continuar. Además, el equipo reconoce el valor de las normas como la ISO 15504 y que la elaboración CMMI debe ser lo más compatible posible con estos métodos.

[PH10]; CMMI REPRESENTACIONES PASADO Y FUTURO; www.sei.cmu.edu/newsitems/CMMI_focus_073010.cfm

Este enfoque de las evaluaciones tiene una ventaja de largo alcance. A medida que explora dicha empresa las evaluaciones que utilizan las áreas de procesos de las organizaciones múltiples, el enfoque continuo a las apreciaciones ofrece la posibilidad de utilizar sólo los mejores áreas de procesos que ayudan a los esfuerzos de mejora de procesos de las organizaciones multidisciplinarias de hoy. Las líneas divisorias entre los modelos no son útiles para las actividades de mejora de procesos. Por ejemplo, cuántas organizaciones podrían beneficiarse de investigar el valor de CMMI para la capacidad de servicio y disponibilidad de área de procesos de gestión, aunque su principal área de interés es el desarrollo o adquisición. Una representación es un objetivo por el cual podemos ver el contenido el modelo CMMI. Una representación (por etapas) hace en un enfoque estructurado y global para la mejora de procesos. Este punto de vista de la mejora de modelo etapas mediante la agrupación de procesos en una fundación o de la evolución que se utilizará para la mejora de procesos. Para avanzar, la organización añade más los procesos para lograr una nueva etapa de mejora de la organización hasta las cuatro etapas de mejora se han definido y logrado. Por último, la organización está en condiciones de identificar y aprovechar las oportunidades de mejora de procesos a medida que surjan. La otra representación (continuo) hace en un enfoque más preciso un enfoque flexible de la mejora de procesos. Este punto de vista del modelo implica mapeo procesos de importancia crítica para el modelo CMMI y la selección de un área de proceso (por ejemplo, gestión de requisitos) que deben utilizarse para la mejora. Para avanzar, la organización agrega objetivos más genéricos para alcanzar otro nivel de capacidad de mejoría hasta tres niveles de mejora se han logrado. Para avanzar aún más, la organización selecciona más áreas de proceso hasta que finalmente se ha logrado los tres niveles de capacidad de todas las áreas de proceso CMMI. La organización está a continuación, en condiciones de identificar y aprovechar las oportunidades de mejora de procesos a medida que surjan.

Los esfuerzos teóricos de vinculación o relación entre ISO9001:2000 y CMMI,

empiezan por un mapeo de aquellas actividades que pueden ser equivalentes entre las normas, y se ha descrito también que un tipo de mapeo N-N es poco práctico a la hora de reflejar los cambios en los procesos en el manual de calidad de ISO. La complejidad inherente a la aplicabilidad del modelo requieren esfuerzos importantes en tiempo y recursos humanos para alcanzar los cambios culturales y organizacionales necesarios para lograr una mejora continua que el modelo propone, inclusive con los nuevos métodos ágiles de desarrollo de software [Baker, 2005]. Pero dado que ISO9001:2000 es un estándar para gestión de la calidad que busca una mejora continua de los procesos, CMMI se convierte en un candidato fuerte especialmente en los procesos de la ingeniería de software, permitiéndole acoplarse en el modelo ISO9001 como un “motor” de cambio Adicionalmente para la implementación del modelo CMMI, es necesario analizar algunos factores para su implementación. Gesfor ha tomado en consideración: factores de negocio, culturales y del conocimiento - experiencia de la organización para definir las versiones de los procesos definidos bajo la norma de ISO9001, y a CMMI, como se ha indicado anteriormente, como modelo de mejora. 5

La industria del software en España está formada principalmente por pymes y

micropyme, empresas que suponen cerca del 80% del sector, donde incluso el 85% tienen menos de diez empleados1, porcentaje que está aumentando cada vez más, en parte debido a la actual tendencia hacia la externalizarían y el “nearshoring” . La mejora de procesos software es una actividad que las pymes desean implementar con el objetivo de incrementar la calidad y capacidad de sus procesos y, en consecuencia, la calidad de sus productos y servicios. Y para mejorar sus procesos las empresas están utilizando modelos como CMMIDEV e ISO 15504, ambos modelos de referencia en España, contando, en el caso de CMMI, con 105 evaluaciones realizadas en España. Sin embargo, numerosos estudios [6-8] muestran que la aplicación de estos modelos en las 4

[MARTI06]; DESDE ISO 9001 HACIA CMMI; Departamento de Ciencias de la Computación. Escuela Superior de Informática. Universidad Alcalá 5 [MARTI07]; Experiencia en la implantación de cmmi-dev v1.2 en una micro pyme con metodologías ágiles y software libre; Red de Revistas Científicas de América Latina

pymes es muy difícil ya que supone para estas una gran inversión en dinero, tiempo y recursos. Este tipo de empresas necesita prácticas de ingeniería del software adaptadas a su tamaño y tipo de negocio Y en este sentido, para apoyar a las pequeñas empresas en la mejora de procesos, se están desarrollando varias iniciativas, como la ISO/IEC 29110 para micropyme y pequeños grupos, que no estará lista hasta 2010; u otras como ITmark, Competisoft, etc., que por la mayor difusión de CMMI son menos demandadas. 6

Hoy en día se les reconoce a las instituciones de formación superior el

esfuerzo por producir un ingeniero global, esto en parte se debe a la necesidad de la creación de un Registro Internacional para los Ingenieros, necesidad que se incrementa vertiginosamente con los procesos socio-económicos y culturales de la época, esta importancia de un reconocimiento internacional de los títulos de ingeniería se puede y debe dar gracias a los procesos de acreditación. En muchos países y en todas las regiones del mundo, se hacen esfuerzos por adoptar un sistema de acreditación de los programas de ingeniería, pero estos esfuerzos se han encontrado con un gasto excesivo y a la vez prohibitivo para adoptarlos como en el caso de los sistemas ABET o CEAB que son en esencia equivalentes. En la pasada Conferencia Internacional del LACCEI (del inglés Latin American and Caribbean Consortium of Engineering Institutions), Consorcio de Instituciones de Ingeniería para Latinoamérica y el Caribe) de la cual son socios fundadores entre otras universidades, la FAU (Florida Atlantic University) y la Universidad Distrital Francisco José de Caldas de Bogotá, Colombia, se propuso la elaboración de un modelo de acreditación institucional basado en una evaluación por niveles y dependiendo de las capacidades de las instituciones y que en un futuro se convierta en una metodología que facilite y permita obtener la acreditación, en primer lugar de todas las instituciones socias del LACCEI y en segundo término, faciliten los procesos de acreditación de otras instituciones de educación superior, especialmente de América Latina y del Caribe. 6

[MARTI16]; Modelo de Registro y Acreditación de Instituciones de Educación Superior basado en el Modelo CMMI; Seventh LACCEI Latin American and Caribbean Conference for Engineering and Technology

Basados en las experiencias y el éxito del modelo CMMI aplicado al desarrollo

de software, se propone el siguiente modelo de apoyo al proceso de acreditación, en especial a aquellos programas e instituciones del campo de la ingeniería: El nivel 1 - Inicial, arranca con las condiciones mínimas que debe cumplir un programa académico (Institución) para brindar el servicio de formación. Este nivel determina la capacidad para cumplir con los mínimos del que hacer del programa y que no es otro que la transmisión de conocimiento, cumpliendo con el proceso básico de formación. En este nivel pueden estar inmersos los ciclos 1 y 2 de formación, es decir técnicos y tecnólogos y aquellos programas incipientes de nivel 3 o formación profesional. El nivel 2 - Gestionado, este involucra a un programa académico (Institución) que cumpliendo con las condiciones mínimas de calidad esta empeñado en la búsqueda de estándares más alto de calidad, deseo y voluntad que se hace visible en la administración del mismo. Para ello encuentra necesario escuchar y entablar diálogos con los usuarios/beneficiarios para dar una respuesta a lo que la sociedad reclama. En este nivel además de cubrir el espectro de formación, el programa absorbe el ámbito de la extensión, es decir el de cubrir otros actores y servicios en la universidad. Nivel 3 - Definido, aquí el programa (Institución) que se ubique en este nivel no solo cumple con los proceso de formación y extensión, sino que su nivel de madurez y calidad le permite hacer generación y apropiación de nuevos conocimientos gracias a los procesos de investigación. En el caso de los programas y/o instituciones de ingeniería, este nuevo conocimiento tendrá que ser aplicado aportando un valor a la sociedad. Nivel 4 - Gestionado cuantitativamente, en este nivel, el programa (Institución) ya ha cumplido en general con su misión y ahora se ocupa que su proceso de gestión se eleve a estándares significativos de calidad. Y para conseguirlo debe evolucionar en unos procesos Sistemáticos que partiendo de la gestión

[MARTI01]; SINOPSIS DE LOS MODELOS SW-CMM Y CMMI; JUAN PALACIO

de datos, alcance su desarrollo hasta lograr la gestión del conocimiento, permitiendo una mejor interacción con múltiples actores de la sociedad. Nivel 5 - En optimización, para alcanzar este nivel el programa (Institución) ha completado a cabalidad la misión para el cual fue creado y ahora su marco de acción se basa en lograr un objetivo teleológico denominado visión que no es otro que la mejora continua. Hacer cada vez mejor su proceso de formación, de servicio a la comunidad, de investigación, de propia gestión y que lo conduzca a ser un líder de su campo disciplinar, con voz y voto en la sociedad.

La recursividad se produce cuando un proceso se aplica a los sucesivos

niveles dentro de una estructura. Cuando hablamos de ingeniería prácticas en el CMMI, esperamos que la recursividad (por ejemplo, los requisitos deben ser gestionados por el producto, componente de producto, subcomponentes, etc.) Aunque no se establece directamente en el modelo, la misma expectativa debe hacerse de las prácticas de gestión de proyectos. A pesar de la reputación de CMMI-DEV como modelo de desarrollo de productos, hay un foco de proyectos distintos a CMMI-DEV. Hay áreas de proceso que utilizan la palabra "proyecto" de forma explícita en su título (la planificación de proyectos, seguimiento y control de proyectos, gestión de proyectos integrados). Así que, ¿cabe esperar la definición de cada uno de un proyecto para ser el mismo? Digamos que usted era un gran contratista de defensa, la construcción de una aeronave integrada. ¿Cómo definiría el alcance de este proyecto? En un proyecto de esta magnitud, nos encontramos con que en realidad hay un montón de pequeños proyectos en ejecución, con un proyecto integrador al más alto nivel. Así que, ¿cómo definir las prácticas de gestión de proyectos instancias al más alto nivel, y cómo lo aplicamos en los niveles inferiores? ¿Debemos esperar encontrar instancias completo de planificación de proyectos, seguimiento y control de proyectos, gestión de proyectos integrados en un nivel del equipo de proyecto integrado o en una 8

[SC09]; RECURSIVIDAD Y LA ITERACION DE CMMI PRACTICAS DE PROYECTO; http://www.sei.cmu.edu/library/assets/20090209webinar.pdf

organización funcional? Al evaluar esta organización, ¿debemos esperar a ganar afirmaciones del equipo de proyecto integrado de cables o software? 9

El nivel 2 de CMMI, consta de 7 áreas de proceso:

• Gestión de requisitos (REQM): Gestión de los requisitos del proyecto y los productos esperados. Identificación de inconsistencias entre los Requisitos y el plan de proyecto. • Planificación de proyectos (PP): Establecimiento y mantenimiento de planes que definen las actividades a ejecutar durante el proyecto. • Seguimiento y control de proyectos (PMC): Control del progreso, identificación de desviaciones y toma de decisiones correctivas. • Gestión de la subcontratación (SAM): Gestión de la adquisición de productos y servicios a través de la existencia de un acuerdo formal con el proveedor. • Aseguramiento de la calidad (PPQA): Garantía de la calidad de los procesos aplicados y de los productos obtenidos. • Gestión de la configuración (CM): Establecimiento y mantenimiento de la integridad de los productos generados en el proyecto. • Métricas y análisis (MA): Desarrollo, mantenimiento y uso de capacidades de medida que soporten las necesidades de información de la organización. 10

El CMMI busca servir como base para cualquier organización que requiera o

implemente esta modalidad de software con el objetivo de en su dinámica mejorar la organización y el componente o los componentes del software.

También para servir de guía en la implantación mantenimiento etc. Un proyecto producto o servicio el cual requiera estos elementos en los procesos. Utilizando cada nivel de madurez en su implementación, con caada detalle fortificar el servicio producto proyecto para el buen funcionamiento de este a futuro, no solo de pende de su estado actual, eso es lo bueno de este sistema,

[PEGR09]; IMPACTO DE LA APLICACIÓN MODELO CMMI NIVEL 2 EN EL CICLO DE VIDA DE UN PROYECTO; FACULTAD DE INFORMATICA UNIVERSIDAD POLITECNICA DE MADRID. ESPAÑA 10 [FEARGORO08]; CMMI; UNIVERSIDAD NACIONAL DE ASUNCION INGENIERIA DEL SOFTWARE III

permite evaluar las diferentes circunstancias en una de estas etapas las cuales a futuro puedan afectarnos y las enfrenta para en caso de que se de, tener una soluci贸n a dicho inconveniente.

5. MARCO CONCEPTUAL

BIBLIOGRAFIA CARNEGIE-MELLON UNIVERSITY CMM for Software, 1.1, 1993 CARNEGIE-MELLON UNIVERSITY CMMI for Software Engineering, 1.1, 2002 [Raffo 2008] Raffo, M. David y Wakeland, Wayne. ascender en la capacidad y niveles de madurez CMMI Us-ci贸n de simulaci贸n (CMU/SEI-2008-TR-002). Instituto de Ingenier铆a de Software, Uni-versidad de Carnegie Mellon 2008. http://www.sei.cmu.edu/pub/documents/08.reports/08tr002.pdf. [SEI 2008] SEI Partner Carta de la Red 5, 2 (mayo de 2008). http://www.sei.cmu.edu/partners/newsletter/news17.html # 4. WHITE PAPERS 09 FEBRERO 2009 http://www.sei.cmu.edu/library/assets/20090209webinar.pdf INFORME DE INVESTIGACION ENERO 2010 http://www.sei.cmu.edu/reports/09tr021.pdf ARTICULO 30 DE JULIO 2010 www.sei.cmu.edu/newsitems/CMMI_focus_073010.cfm www.sei.cmu.edu/cmmi/ CARNEGIE-MELLON UNIVERSITY CMM for Software, 1.1, 1993 CARNEGIE-MELLON UNIVERSITY CMMI for Software Engineering, 1.1, 2002 DENNIS M. AHERN, AARON CLOUSE y RICHARD TURNER, CMMI Distilled: A Practical Introduction to Integrated Process Improvement, Addison Wesley, 2003 MARY BETH CHRISSIS, MIKE KONRAD y SANDY SHRUMI, CMMI Guidelines for Process Integration and Product, Addison Wesley, 2003 GARY FORD y NORMAN GIBBS, Mature Profession of Software Engineering, SEI, 1996

Ali, M., 2006 Metrics for Requirements Engineering, UMEA University. Baker,S., 2005 Formalizing Agility: An Agile Organization’s Journey toward CMMI Accreditation, Proceedings of the Agile Development Conference (ADC’05) IEEE. Chrissis,M.,Konrad,M.,Shrum,S.,2003 Introduction to CMMI, Addison – Wesley, Julio 2003. www.awprofessional.com/articles/ IEEE 1012-2004, 1012 IEEE Standard for Software Verification and Validation of Software, IEEE, Junio 2005. Gremba & Meyers,1997 The IDEAL Model: A Practical Guide for Improvement, Software Engineering Institute (SEI) publication, Bridge, issue three. http://www.sei.cmu.edu/ideal/ideal.bridge.html Jones & Soule, 2002 Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice. Kulpa & Johnson, 2003, Interpreting the CMMI: A Process Improvement Approach, Margaret K. Kulpa and Kent A. Johnson, Auerbach Publications.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI01] FUENTE: 001 ELABORO:FAMA TIPO: TITULO: AUTOR: UBICACIÓN:

LIBRO DIGITAL 1 DE ABRIL DE 2006 SINOPSIS DE LOS MODELOS SW-CMM Y CMMI JUAN PALACIO CODIGO DE OBRA 0710040050483 http://www.safecreative.org/work/0710040050483

DESCRIPCION: Síntesis de los modelos de procesos CMM y CMMI para desarrollo y mantenimiento de software. CMMI (y previamente CMM) puede emplearse con dos finalidades: 1.- Guía para mejorar los procesos que intervienen en el desarrollo y mantenimiento del software. 2.- Criterio para determinar el nivel de madurez de una organización que desarrolla o mantiene software en base a la capacidad de las áreas de procesos definidas en estos modelos.

TABLA DE CONTENIDO: 1. INTRODUCCION, 2. HISTORIA Y EVOLUCION 3.PRINCIPIOS Y CONCEPTOS, 4. ESTRUCTURA 5. EVOLUCION FUTURA, PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, Modelo de madurez, Requisitos

RESUMEN 001 SINOPSIS DE LOS MODELOS SW-CMM Y CMMI 1. Introducción

El modelo americano Capability Maturity Model Integration (CMMI), creado por el Software Engineering Institute ¡Error! No se encuentra el origen de la referencia., se ha convertido en los últimos años en un modelo estándar de facto para la mejora de procesos software y está empezando a ser exigido por los clientes a la hora de contratar servicios y desarrollos de sistemas intensivos en software.

2. HISTORIA Y EVOLUCION El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban más y más. ¿Quién no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software? Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa". 3. PRINCIPIOS Y CONCEPTOS CMMI se asienta en el mismo principio expuesto para CMM: La calidad de un producto o de un sistema es en su mayor parte consecuencia de la calidad de los procesos empleados en su desarrollo y mantenimiento.

Capacidad Atributo de los procesos. El nivel de capacidad de un proceso indica si sólo se ejecuta, o si también se planifica se encuentra organizativa y formalmente definido, se mide y se mejora de forma sistemática. Niveles de capacidad. Los 6 niveles definidos en CMMI para medir la capacidad de los procesos son: 0.- Incompleto El proceso no se realiza, o no se consiguen sus objetivos. 1.- Ejecutado El proceso se ejecuta y se logra su objetivo. 2.- Gestionado. Además de ejecutarse, el proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos. 3.- Definido Además de ser un proceso “gestionado” se ajusta a la política de procesos que existe en la organización, alineada con las directivas de la empresa. 4.- Cuantitativamente gestionado. Además de ser un proceso definido se controla utilizando técnicas cuantitativas. 5.- Optimizado Además de ser un proceso cuantitativamente gestionado, de forma sistemática se revisa y modifica para adaptarlo a los objetivos del negocio. Niveles de madurez. Son los mismos 5 que los descritos en el modelo SWCMM, si bien se les han revisado los nombres a los niveles 2 y 4. Nivel 1: Inicial Nivel 2: Gestionado Nivel 3: Definido Nivel 4: Gestionado cuantitativamente Nivel 5: Optimizado

4. ESTRUCTURA

5. EVOLUCION FUTURA CMMI versión 1.3 será lanzada en noviembre de 2010. Habrá un período de transición los años-una después de este durante el cual el SEI aceptará evaluaciones V1.2. Para obtener más información

Bibliografía CARNEGIE-MELLON UNIVERSITY CMM for Software, 1.1, 1993 CARNEGIE-MELLON UNIVERSITY CMMI for Software Engineering, 1.1, 2002 DENNIS M. AHERN, AARON CLOUSE y RICHARD TURNER, CMMI Distilled: A Practical Introduction to Integrated Process Improvement, Addison Wesley, 2003 MARY BETH CHRISSIS, MIKE KONRAD y SANDY SHRUMI, CMMI Guidelines for Process Integration and Product, Addison Wesley, 2003 GARY FORD y NORMAN GIBBS, Mature Profession of Software Engineering, SEI, 1996

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI02] FUENTE: 002 ELABORO:FAMA TIPO:

INFORME DE INVESTIGACION NOVIEMBRE DE 2008 MADUREZ CMMI DE MEDICIÓN DE ALTA Y EL INFORME TALLER TITULO: DE ANÁLISIS: MARZO 2008 ROBERT W. II STODDARD, DENNIS R. GOLDENSON, ZUBROW AUTOR: DAVE, Y ERIN HARPER INSTITUTO DE INGENIERÍA DE SOFTWARE CARNEGIE MELLON UNIVERSITY PITTSBURGH, PA 15213 NOTA TÉCNICA CMU/SEI-2008-TN-027 http://www.sei.cmu.edu/library/abstracts/reports/08tn027.cfm?wt.dcse UBICACIÓN: xt.abstractsource=relatedlinks DESCRIPCION: Las organizaciones son cada vez más en busca de orientación sobre lo que se necesita para aplicar Capacidad Maturity Modelo Integración (CMMI) Las prácticas de alta madurez y la manera de mantener el dinamismo de su para la mejora. Medida que las organizaciones de alta madurez trabajar para mejorar su uso de la medición y análisis, que parecen a menudo a ejemplos de implementaciones exitosas de orientación. En respuesta a la necesidad de clarificación y orientación sobre la aplicación de la medición y análisis en el contexto de los procesos de madurez alto, los miembros de software de medición de la SEI de Ingeniería y el Análisis (SEMA) iniciativa organizó un taller en la conferencia SEPG 2008 América del Norte para llevar líderes en el campo juntos en un foro sobre el tema. Otros talleres se llevarán a cabo como parte de una serie en curso para que las organizaciones de alta madurez para compartir las mejores prácticas y estudios de caso.

TABLA DE CONTENIDO: 1. INTRODUCCION, 2. MADUREZ ALTO KICKOFF, 3. FUTURO

PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, Modelo de madurez,

RESUMEN 002 MADUREZ CMMI DE MEDICIÓN DE ALTA Y EL INFORME TALLER DE ANÁLISIS: MARZO 2008 Cada vez más organizaciones están luchando y alcanzando el estado de madurez alto, pero aún queda una comprensión compartida insuficiente de la que la medición y análisis de las prácticas relacionadas son aprocuados para las organizaciones de madurez alto. Aunque Capability Maturity Model® Integración (CMMI®) Ofrece orientación de alto nivel, algunas organizaciones luchan para encontrar una vía eficaz para De madurez alto, y los que han llegado se debe persistir en la evolución de sus esfuerzos en el espíritu de la mejora continua. Como resultado, las organizaciones buscan cada vez más orientación sobre lo que se necesita para alcanzar la condición de madurez CMMI alta y la forma de seguir mejorando una vez que lleguen allí. Aprobación de los modelos de actuación proceso debe ser acelerado SEMA investigadores se dio cuenta de la adopción de modelos de la comunidad rendimiento de los procesos necesarios para ser acelerado para satisfacer las necesidades inmediatas de negocio y el retorno de la inversión para mostrar negocio CMMI mejora. Así, en lugar de esperar a la proyectada cinco a siete años para la base estadística modelos de procesos de rendimiento a ser más ampliamente adoptado, SEMA tiene como objetivo ayudar a la comunidad lograr la adopción significativa en los próximos dos o tres años. Una pauta acelerada también estará en de conformidad con previsto cambios en el modelo CMMI y la implantación de nuevas constelaciones de CMMI. Como nota especial, la simulación de eventos discretos, es crear un modelo eficaz, ya ha sido ampliamente adoptado por la comunidad de servicios para predecir cosas como el tiempo de ciclo, los cuellos de botella de flujo de trabajo, tiempos de espera, y la cola largos.

2 Madurez de la serie Kickoff El objetivo del primer taller fue construir y usar modelos CMMI desempeño del proceso. Participación se limitaba a un pequeño grupo de organizaciones que estaban primeros en adoptar el proceso por modelos de desempeño y líneas de base y fue sólo por invitación. Los representantes de Aire Logis-Hill Centro de tics, Lockheed-Martin, Northrop Grumman, Raytheon y asistido. Los objetivos principales del taller fueron: • CMMI permite a las organizaciones de alta madurez para compartir las mejores prácticas y estudios de casos • identificar maneras para desarrollar la medición de alta madurez CMMI y las prácticas de análisis y acérate su adopción • permiten la creación de redes entre los profesionales Desde la aclaración de las actividades de madurez alto afectadas muchas prácticas en las cuatro áreas de procesos asociados, es evidente que el uso actual de los objetivos genéricos de 4 y 5 relacionados con la representación continua eran insuficientes para proporcionar la orientación correspondiente aclaración. En cambio, el nivel 4 implicaría la aplicación de dos zonas de proceso para el esfuerzo.Para utilizar la representación continua de centrar la atención de madurez alto a las áreas de interés, tales como la verificación y validación integrada, el proceso será la siguiente: en primer lugar, acercar a las dos áreas de proceso (VER y VAL) hasta la capacidad de nivel 3. A continuación, seleccionar y llevar el proceso de organización de rendimiento (OPP) y Cuantitativos Administración de Proyectos (QPM) áreas de proceso hasta el nivel de capacidad 3 para alcanzar el nivel cuantitativamente administrado. Estas actividades se asegurarán de que la mejora de la capacidad para el área de interés tiene la misma atención a las prácticas que ML 4 da en la representación en escena. A continuación, lleva el análisis causal y Resolución (CAR) y de las Organizaciones de Gestión del Rendimiento (OPM), áreas de proceso hasta el nivel de capacidad 3 para alcanzar el nivel de optimización.

3. FUTURO Estos cambios siguen a la simplificación de los elementos del modelo CMMI y métodos, mientras que ampliar el apoyo de la mejora de procesos para una comunidad en constante expansión de su interés. Con el lanzamiento de CMMI V1.3, la distinción entre las evaluaciones continuas y por etapas se reduce si no se elimina. Todas las áreas de proceso que se aprecian se evalúan de la misma manera, para asegurar CL 1, 2, o 3. Las colecciones de las áreas de procesos a continuación, definir el nivel de madurez (por ejemplo, CMMI-ACQ ML3) para los grupos que perseguían madurez de la organización. La decisión de mejorar la cobertura de la madurez de alta era fundamental para la versión 1.3 de actualización. La decisión de eliminar la estructura de alta capacidad de meta aporta un valor añadido para la mejora de los procesos más que simplemente mantener el enfoque legado. Algunos encontrarán estos cambios difíciles, sin embargo, la mayoría verá que las ventajas de un entorno multi-constelación superan a los riesgos que acompañan a cualquier cambio.

Bibliografía [Raffo 2008] Raffo, M. David y Wakeland, Wayne. ascender en la capacidad y niveles de madurez CMMI Us-

ci贸n de simulaci贸n (CMU/SEI-2008-TR-002). Instituto de Ingenier铆a de Software, Carnegie Mellon Universidad de 2008. http://www.sei.cmu.edu/pub/documents/08.reports/08tr002.pdf. [SEI 2008] SEI Partner Carta de la Red 5, 2 (mayo de 2008). http://www.sei.cmu.edu/partners/newsletter/news17.html # 4. 3 Many examples of the use of discrete event simulation in the services community can be found at http://www.processmodel.com/resources/samplemodels.html http://www.allbusiness.com/34709451.html?query=%22discrete+event+simulation%22+services&x=0&y=0, and http://search-www.isixsigma.com/cgibin/ ss_query?related=0&keys=case+%2B%22discrete+event+simulation%22+%2B service&sitenbr=130985463. For further information, see Moving Up the CMMI Capability and Maturity Levels Using Simulation [Raffo 2008]. 4 A brief description of this program is available in an SEI Partner Network newsletter [SEI 2008].

FICHA DE REGISTRO DOCUMENTAL CODIGO: [SC09] FUENTE: 003 ELABORO:SARV

TIPO: TITULO:

WHITE PAPERS 09 FEBRERO 2009 RECURSIVIDAD Y LA ITERACION DE CMMI PRACTICAS DE PROYECTO

AUTOR:

FRED SCHENKER

UBICACION

http://www.sei.cmu.edu/library/assets/20090209webinar.pdf

DESCRIPCION:

Para crear conciencia en la comunidad con respecto a CMMI recursivo y / o La aplicación iterativa de CMMI. Gestión de Proyectos prácticas Para los tasadores Para los consultores proceso

TABLA DE CONTENIDO: SG 1 Producto de Soluciones de selección de componentes, Recursividad en el CMMI Gestión de Proyectos

PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, CMMI-DEV

RESUMEN 003 RECURSIVIDAD Y LA ITERACION DE CMMI PRACTICAS DE PROYECTO -SG 1 Producto de Soluciones de selección de componentes, Recursividad en el CMMI Gestión de Proyectos

La recursividad se produce cuando un proceso se aplica a los sucesivos niveles dentro de una estructura. Cuando hablamos de ingeniería prácticas en el CMMI, esperamos que la recursividad (por ejemplo, los requisitos deben ser gestionados por el producto, componente de producto, subcomponentes, etc.) Aunque no se establece directamente en el modelo, la misma expectativa debe hacerse de las prácticas de gestión de proyectos. A pesar de la reputación de CMMI-DEV como modelo de desarrollo de productos, hay un foco de proyectos distintos a CMMI-DEV. Hay áreas de proceso que utilizan la palabra "proyecto" de forma explícita en su título (la planificación de proyectos, seguimiento y control de proyectos, gestión de proyectos integrados). Así que, ¿cabe esperar la definición de cada uno de un proyecto para ser el mismo? Digamos que usted era un gran contratista de defensa, la construcción de una aeronave integrada. ¿Cómo definiría el alcance de este proyecto? En un proyecto de esta magnitud, nos encontramos con que en realidad hay un montón de pequeños proyectos en ejecución, con un proyecto integrador al más alto nivel. Así que, ¿cómo definir las prácticas de gestión de proyectos instancias al más alto nivel, y cómo lo aplicamos en los niveles inferiores? ¿Debemos esperar encontrar instancias completo de planificación de proyectos, seguimiento y control de proyectos, gestión de proyectos integrados en un nivel del equipo de proyecto integrado o en una organización funcional? Al evaluar esta organización, ¿debemos esperar a ganar afirmaciones del equipo de proyecto integrado de cables o software? Del mismo modo, las prácticas de gestión de proyectos se espera que ser reiterativos. Por ejemplo, la planificación de proyectos se lleva a cabo durante toda la vida del proyecto, no sólo al principio. Esta presentación examinará las prácticas de gestión de proyectos desde la perspectiva tanto de la recursividad y la iteración. Vamos a identificar aquellas prácticas donde se prevé que la recursividad y la iteración, y discutir las tácticas de aplicación y las opciones. Por último, las implicaciones para evaluar estas prácticas y para la preparación de pruebas de evaluación.

Como sabemos CMMI es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales de procesos efectivos que en última instancia, mejorar su rendimiento. CMMI puede ser usada para guiar la mejora de procesos a través de un proyecto, una división o una organización entera. Ayuda a integrar funciones tradicionalmente separadas de organización, establecer objetivos de mejora de procesos y prioridades, proporcionar una guía para los procesos de calidad, y proporcionar un punto de referencia para evaluar los procesos actuales. Se debe Utilizar el CMMI como una guía para asegurarse de que se están haciendo las cosas correctas, es una metodología que va ligada a la gestión de los procesos de un proyecto de varios tipos, aunque es fomentada mas que todo en los proyectos de software. Su regularidad involucra mucho para el desarrollo de un proyecto o incluso el de una empresa, pero es una guía para mejorar e implementar, no su metodología debe ser vigilada y aunque nos permite un desarrollo optimo y eficaz CMMI sólo define "qué" hacer, no el "cómo" hacerlo, CMMI es un modelo de proceso, no un proceso de descripción.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [STGO10] FUENTE: 004 ELABORO:SARV

TIPO:

INFORME DE INVESTIGACION ENERO 2010 APROXIMACIONES A LA EJECUCION DEL PROCESO DE MODELADO: UN RESUMEN, DE LA SERIE DE TALLERES SOBRE SEI CMMI ALTA MADUREZ MEDICION Y ANALISIS Robert W. Stoddard II Dennis R. Goldenson http://www.sei.cmu.edu/reports/09tr021.pdf

TITULO: AUTOR: UBICACION

DESCRIPCION: Ayuda

Para

mejora

procesos guiados

diferentes

organizaciones basadas en conceptos q ayudan a su fortalecimiento como empresa en cada proyecto propuesto

Además de la intervención del CMMI como pilar de dichas organizaciones la cual presta su mejor servicio, y complementa las demás organizaciones.

TABLA DE CONTENIDO: 1. INTRODUCCION 1.3 mejores componentes de Modelos de Procesos de rendimiento, 2. PRESENTACION DE MODELO 3.OTRO TIPO DE TALLERES 3.2 Sesión de Control: Modelos de Proceso de ejecución: Problemas y obstáculos PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, QPM, OPP, SEI

RESUMEN 004 APROXIMACIONES A LA EJECUCION DEL PROCESO DE MODELADO: UN RESUMEN, DE LA SERIE DE TALLERES SOBRE SEI CMMI ALTA MADUREZ MEDICION Y ANALISIS

1. Introducción 1.3 los mejores componentes de Modelos de Procesos de rendimiento La Madurez CMMI con alta madurez. Los componentes sanos se formularon por primera vez dinámicamente durante la realización de cursos de medición de SEI en 2006 y 2007 como un medio de comunicación lo que los modelos de procesos de desempeño fueron en términos concretos y prácticos. Los componentes se derivan de una comprensión holística de la intención de los modelos CMMI. La naturaleza precisa de varios de los componentes también proviene de la formación, experiencia y práctica de otros programas. Los componentes saludables de un modelo de rendimiento del proceso se resumen a continuación. • El modelo es estadística, probabilidad, o simulación. Estos componentes particular, hace la coherencia lógica de dos áreas de proceso CMMI: cuantitativos Gestión de Proyectos (QPM) y el rendimiento del proceso de organización (OPP). QPM hace en la necesidad de comprender la variación estadística de los factores de rendimiento del proceso. Además, refuerza QPM la necesidad de separar la variación asignable, causa especial de variación inherente causa común para ayudar a entender qué acciones tomar con respecto a cada tipo de variación. Este componente mejora en la necesidad de modelos de rendimiento de los procesos a modelar la incertidumbre de los factores predictivos y su consecuente impacto sobre la incertidumbre del comportamiento de los resultados. Por esta razón, los modelos deterministas que simplemente realizan cálculos matemáticos en las estimaciones puntuales están destituidos de la información superior alcanzable a partir de modelos estadísticos que son, probabilística, o simulación de la naturaleza

Por ejemplo, los proyectos tradicionales modelos de previsión que en el modelo son incontrolables varios factores hacen que las predicciones ofrezcan poca ayuda o comprensión en las acciones que deben adoptarse para conducir un resultado previsto más deseable. Además, este ingrediente pone de relieve la necesidad de que los factores controlables sean lo suficientemente detallados para demostrar un vínculo claro con un subproceso específico o la actividad laboral. la organización CMMI de rendimiento del proceso (OPP), Gestión de Proyectos cuantitativos (QPM), la organización Innovación y Despliegue (OID), y Análisis Causal y Resolución (CAR) proceso de áreas relacionadas con el uso de modelos para apoyar el rendimiento del proceso "what-if" y la sensibilidad de análisis. La idea es que quienes toman las decisiones serán capaces de utilizar modelos de procesos de rendimiento para analizar cursos alternativos de acción y las ideas alternativas de mejora. Una vez más, ello pone de relieve una capacidad destinados a ser ejercido dentro de un determinado proyecto o ejecución del programa. En su enfoque se pretende manejar conjunto sistemas de organización los cuales brindan apoyo y son similares a el CMMI algunos derivan de el pues es de una gran utilidad este tipo de organización para el desarrollo de una empresa q busque un sistema el cual le lleve al éxito. El modelo permite a los proyectos lograr las correcciones a mitad de camino para asegurar el éxito del proyecto. Este ingrediente destaca un aspecto muy significativo que se puede leer en el uso del proceso de desempeño modelos de CMMI. En concreto, dentro del área de proceso de QPM, el rendimiento del proceso modelos pueden utilizarse para anticipar resultados no deseados con el tiempo suficiente plomo para proactivamente influir en la situación hacia un resultado exitoso.

1.2 Presentación del modelo Los resultados del modelo indican que un modelo de negocio bien puede disponer de las organizaciones pequeñas considerándolas seriamente en las iniciativas de procesos CMMI basado en la mejora de medianas organizaciones, parecen tener buenas razones para aspirar una condición de madurez alto. Sin embargo, el tiempo necesario para alcanzar rentabilidad para la inversión en mejora de procesos a menudo es mayor que lo que normalmente se ha considerado. Por lo tanto se está examinando cómo los instrumentos de cobertura es disponible con el apoyo del gobierno ya través de iniciativas de colaboración puede ayudar a esas organizaciones a compartir los costos de infraestructura. Esto es especialmente importante para las organizaciones que operan en la volátil y los mercados inciertos donde los beneficios del proceso de mejora es necesario elaborar lo más pronto como sea posible

La presentación destacó la importancia de las métricas que en un programa de medición completa para dirección de las tres "P" s: proyecto, producto y proceso. "Proyecto" se asocia comúnmente con CMMI nivel de madurez 2, donde métricas de programación, tales como el costo y el horario son recogidas. "Producto" se asocia comúnmente a nivel de madurez CMMI 3, donde las métricas de calidad, como defectos se recogen. "Proceso" es comúnmente asociado con niveles de madurez CMMI 4-5, donde métricas de mejora se recogen, como indicadores para comprender los efectos de los cambios en el proceso. 3. OTRO TIPO DE TALLERES 3.2 Sesión de Control: Modelos de Proceso de ejecución: Problemas y obstáculos Por último, el tema de lo que es, o debería ser, quiere decir un modelo de proceso basado en el rendimiento CMMI fue criado por otros participantes en el taller durante las sesiones. El papel de CMMI es proveer una guía útil que es valiosa para sus usuarios. Conforme no es un fin en sí mismo. Esto puede ser un problema de modelo, no simplemente una de apreciación. De todos modos, los modeladores deben estar mejor informados de lo que se espera de los PMP basado en CMMI. Y darse cuenta de su importancia pues involucra a muchas mas organizaciones de las que pensamos.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [PH10] FUENTE: 005 ELABORO:SARV TIPO: TITULO:

AUTOR: UBICACIÓN:

ARTICULO 30 DE JULIO 2010 CMMI REPRESENTACIONES PASADO Y FUTURO SOFTWARE ENGINEERING INSTITUTE UNIVERSIDAD CARNEGIE MELLON MIKE PHILLIPS www.sei.cmu.edu/newsitems/CMMI_focus_073010.cfm www.sei.cmu.edu/cmmi/

DESCRIPCION: CMMI está siendo adoptada en todo el mundo, incluyendo Norteamérica, Europa, Asia, Australia, América del Sur y África. Este tipo de respuesta ha justificado el compromiso de la SEI a CMMI. Usted puede utilizar CMMI en tres diferentes áreas de interés: Desarrollo de productos y servicios ( CMMI para el modelo de desarrollo ) Servicio de establecimiento, manejo y entrega ( para el modelo CMMI Servicios ) De productos y la adquisición de servicios ( CMMI para el modelo de Adquisición También se describe un enfoque para la mejora del proceso basado en modelos y ofrece algunas recomendaciones sobre cómo iniciar y mantener una iniciativa de mejora de procesos dentro de una organización basada en el modelo ideal de SEI. Estos modelos y enfoques de la gestión de aplicaciones pragmáticas probada y conceptos de calidad de mejora para el desarrollo de productos, adquisición y mantenimiento. Son normas de facto desarrollado y propiedad de la comunidad de desarrollo de productos y son modelos de mejora institucional.

TABLA DE CONTENIDO: 1. REPRESENTACIONES PASADO Y FUTURO PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, CMMI continuo, CMMI por etapas

RESUMEN 005 REPRESENTACIONES PASADO Y FUTURO En noviembre de 2010. Será lanzada esta última versión de los modelos CMMI 1.3 incluye cambios en el material de alta madurez y otras mejoras que satisfarán mejor las necesidades de las organizaciones que utilizan modelos de CMMI.

Sabemos que dos áreas de mejora en el CMMI se desarrollo en productos, este organización ha tratado de ofrecer con esta actualización mejorar la armonización y de aclarar el concepto de madurez alto. Un cambio importante que se incluirán en la versión 1.3 los modelos contribuirán a ambos objetivos: la eliminación del nivel 4 y 5 como objetivos genéricos. A medida que se desarrollo la obra en la versión 1.3, una gran prioridad era aclarar la alta madurez. Llevaron a cabo una alta madurez del programa con representación mayoritaria de los participantes de dicha industria para asegurar que las mejoras representadas sean las mejores prácticas actuales en la comunidad.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI06] FUENTE: 006 ELABORO:FAMA TIPO: TITULO:

AUTOR:

UBICACIÓN:

White Papers de la industria tecnológica DESDE ISO 9001 HACIA CMMI, PASOS PARA LA MEJORA DE LOS PROCESOS Y MÉTRICAS Rolando Armas Andrade, Arturo Chamorro Gómez, Maite Montes Beobide, José Antonio Gutierrez de Mesa1 Departamento de Ciencias de la Computación. Escuela Superior de Informática.Universidad Alcalá Edif. Politécnico. Campus Universitario. Carretera Madrid-Barcelona, Km. 33,600. C.P. 28871. Alcalá de Henares, Madrid RPM-AEMES, VOL. 4, Nº 1 Enero 2007 ISSN: 1698-2029

DESCRIPCION: En este artículo se muestra una experiencia particular sobre la implementación de los procesos de calidad gestionados por ISO 9001 y de la mejora continua de los mismos a través del modelo CMMI. En base a las referencias de estándares, mejores prácticas, experiencia de la organización y las especificaciones del modelo CMMI, se está llevando a cabo la mejora continua de los procesos a través de las versiones generadas y sus respectivas métricas, específicamente se muestra la propuesta sobre el proceso de gestión de requerimientos. TABLA DE CONTENIDO: 1. INTRODUCCIÓN, 2. , 3. ENFOQUE EN LOS PROCESOS. ,4. ESTRATEGIAS PARA LA IMPLEMENTACIÓN. PALABRAS CLAVE: ISO9001:2000, CMMI, relación, procesos, métricas, mejora.

RESUMEN 006 DESDE ISO 9001 HACIA CMMI, PASOS PARA LA MEJORA DE LOS PROCESOS Y MÉTRICAS 1. INTRODUCCION El modelo CMMI (Capability Madurity Model Integration) se presenta como un modelo de mejora de procesos en desarrollo de software que puede complementarse a la norma ISO9001. Sin embargo uno de los grandes desafíos es llegar a encontrar una estrategia que permita realizar este tipo de integración de forma “natural” en la empresa. En este artículo se muestran parte de los primeros pasos que Gesfor está siguiendo en su proyecto de implementación de CMMI. Debido al alcance del artículo se ha hecho referencia únicamente al proceso de gestión de requerimientos.

Este artículo tiene la siguiente estructura: en la primera parte se muestra las experiencias relacionadas, dando una visión y un estado del arte respecto a ISO9001 y CMMI, se aborda además el tema de la vinculación entre ISO9001 y CMMI. En las posteriores secciones de este articulo, se profundiza en los primeros pasos de implementación, tocando el tema de la mejora de los procesos, una exposición de la temática y un ejemplo especifico aplicado a la gestión de requerimientos, finalmente se presentan las conclusiones del trabajo realizado. La problemática inherente con un modelo CMMI es su complejidad, y aunque el modelo muestra el “qué hacer”, no muestra el “cómo hacerlo”, es por eso que es necesaria una estrategia que permita llegar a la adopción completa del modelo.

Sin embargo ninguno de estos trabajos anteriores muestra de forma clara o explicita una estrategia sobre cómo llegar a una implementación de CMMI a través del estándar ISO9001:2000. Este trabajo es un primera propuesta que permita llegar al objetivo de cumplir con la mejora continua de los procesos a través de CMMI.

2. ASPECTOS A CONSIDERAR EN LA IMPLEMENTACION DE CMMI Como se mostró en la sección anterior, los esfuerzos teóricos de vinculación o relación entre ISO9001:2000 y CMMI, empiezan por un mapeo de aquellas actividades que pueden ser equivalentes entre las normas, y se ha descrito también que un tipo de mapeo N-N es poco práctico a la hora de reflejar los cambios en los procesos en el manual de calidad de ISO. La complejidad inherente a la aplicabilidad del modelo requieren esfuerzos importantes en tiempo y recursos humanos para alcanzar los cambios culturales y organizacionales necesarios para lograr una mejora continua que el modelo propone, inclusive con los nuevos métodos ágiles de desarrollo de software [Baker, 2005]. Pero dado que ISO9001:2000 es un estándar para gestión de la calidad que busca una mejora continua de los procesos, CMMI se convierte en un candidato fuerte especialmente en los procesos de la ingeniería de software, permitiéndole acoplarse

modelo

ISO9001

como

“motor”

cambio

Adicionalmente para la implementación del modelo CMMI, es necesario analizar algunos factores para su implementación [Chrissis et al., 2003]. Gesfor ha tomado en consideración: factores de negocio, culturales y del conocimiento - experiencia de la organización para definir las versiones de los procesos definidos bajo la norma de ISO9001, y a CMMI, como se ha indicado anteriormente, como modelo de mejora.

3. ENFOQUE EN LOS PROCESOS. ISO9001 hace mucho énfasis en la definición, control y mejora de los procesos que permitan garantizar la calidad de los productos y servicios producidos y que se encuentran entre los requerimientos y la satisfacción del cliente. Los procesos se han agrupado en tres grandes categorías, los relativos al soporte de la gestión, los procesos clave que hacen operativa la gestión y los estratégicos que permiten llegar a los objetivos planteados. En la trayectoria de implementación de un modelo CMMI, los primeros pasos están centrados en la definición de los procesos,

4. ESTRATEGIAS PARA LA IMPLEMENTACIÓN Abordar una implementación de un modelo CMMI requiere de un proyecto, planificación y compromisos institucionales, esfuerzos conjuntos en los que Gesfor se encuentra comprometido desde la certificación ISO9001 conseguida años atrás. El proyecto de implementación de CMMI se lo ha dividido en tres etapas: 1) Verificación del estado actual 2) Definición del objetivo y el ambiente futuro a alcanzar 3) Un plan de transición para transformar el ambiente actual al ambiente futuro.

Una vez definidas las tres etapas y dando un enfoque, como se indico anteriormente, a los procesos clave a través de su definición, documentación, control, verificación, indicadores y métricas, todo esto bajo la coordinación de la norma ISO9001:2000, se está llevando a cabo la implementación y puesta en práctica de dichos procesos, especialmente en aquellos que se vinculan directamente con el cliente. Dado que la organización requiere dar un enfoque de mejora alineado con los productos y servicios, y que este requiere una mejora de los procesos a lo largo de la línea de producto, se ha tomado como referencia el modelo CMMI por niveles. [Chrissis et al., 2003]. Básicamente se realizará la verificación del proceso y de los productos de trabajo a través de los métodos recomendados en CMMI: Appraisals y Peer Reviews. La verificación y el control de los procesos en CMMI se realizan a través de los denominados “appraisal” término en inglés que significa “apreciación”. CMMI propone que se desarrollen métodos que permitan obtener una apreciación de la situación que la que se encuentra el proceso de implementación de CMMI. Este tipo de apreciación tiene que ser objetiva, es decir a través de métricas. Los Peer Reviews son una importante parte de la verificación y son un mecanismo probado para la eliminación efectiva del defecto. Los Peer Reviews involucran una exanimación metodológica de los productos de trabajo hecha a pares para identificar defectos y otros cambios que son necesarios. Ejemplos de Peer Reviews incluyen las inspecciones y los walkthroughs.

REFERENCIAS Ali, M., 2006 Metrics for Requirements Engineering, UMEA University. Baker,S., 2005 Formalizing Agility: An Agile Organization’s Journey toward CMMI Accreditation, Proceedings of the Agile Development Conference (ADC’05) IEEE. Chrissis,M.,Konrad,M.,Shrum,S.,2003 Introduction to CMMI, Addison – Wesley, Julio 2003. www.awprofessional.com/articles/ IEEE 1012-2004, 1012 IEEE Standard for Software Verification and Validation of Software, IEEE, Junio 2005. Gremba & Meyers,1997 The IDEAL Model: A Practical Guide for Improvement, Software Engineering Institute (SEI) publication, Bridge, issue three. http://www.sei.cmu.edu/ideal/ideal.bridge.html Jones & Soule, 2002 Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice. Kulpa & Johnson, 2003, Interpreting the CMMI: A Process Improvement Approach, Margaret K. Kulpa and Kent A. Johnson, Auerbach Publications.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI07] FUENTE: 007 ELABORO:FAMA

TIPO:

TITULO: AUTOR:

UBICACIÓN: DESCRIPCION: En

REICIS REVISTA ESPAÑOLA DE INNOVACIÓN, CALIDAD E INGENIERÍA DEL SOFTWARE, VOL. 6, NÚM. 1, ABRI, 2010, PP. 6-15 EXPERIENCIA EN LA IMPLANTACIÓN DE CMMIDEV V1.2 EN UNA MICRO PYME CON METODOLOGÍAS ÁGILES Y SOFTWARE LIBRE NAVARRO, JOSÉ MANUEL; GARZÁS, JAVIER Red de Revistas Científicas de América Latina, el Caribe, España y Portugal REICIS Revista Española de Innovación, Calidad e Ingeniería del Software reicis@ati.es Asociación de Técnicos de Informática España ISSN: 1885-4486

actualidad,

industria

del

software

está

formada

principalmente por pymes (pequeñas y medianas empresas) y micro pymes (Pymes de aproximadamente 20 empleados). En este tipo de empresas la calidad del software es esencial, siendo la mejora de procesos software una actividad que desean implementar con el objetivo de incrementar la calidad y capacidad de sus procesos y, en consecuencia, la calidad de sus productos y servicios. Sin embargo, la aplicación de los modelos de mejora de procesos referentes en la actualidad (CMMI e ISO 15504) en pymes es muy difícil ya que supone para estas una gran inversión en dinero, tiempo y recursos. Este tipo de empresas necesita prácticas de ingeniería del software adaptadas a su tamaño y tipo de negocio. En este contexto, el objetivo de este artículo es plantear dicha problemática y presentar una experiencia sobre como metodologías ágiles, software libre y TABLA DE CONTENIDO: CMMI 1. Introducción, pueden integrarse. 2. Motivación para la certificación de UNKASOFT en el nivel 2 de CMMI, 3. Fases y recursos dedicados, 4. Metodologías y herramientas

RESUMEN 001 EXPERIENCIA EN LA IMPLANTACIÓN DE CMMI-DEV V1.2 EN UNA MICRO PYME CON METODOLOGÍAS ÁGILES Y SOFTWARE LIBRE 1. INTRODUCCION La industria del software en España está formada principalmente por pymes y micropymes, empresas que suponen cerca del 80% del sector, donde incluso el 85% tienen menos de diez empleados1, porcentaje que está aumentando cada vez más, en parte debido a la actual tendencia hacia la externalización y el “nearshoring” [1]. La mejora de procesos software es una actividad que las pymes desean implementar con el objetivo de incrementar la calidad y capacidad de sus procesos [2] y, en consecuencia, la calidad de sus productos y servicios. Y para mejorar sus procesos las empresas están utilizando modelos como CMMI-DEV [3] e ISO 15504 [4], ambos modelos de referencia en España [5], contando, en el caso de CMMI, con 105 evaluaciones realizadas en España2. Sin embargo, numerosos estudios [6-8] muestran que la aplicación de estos modelos en las pymes es muy difícil ya que supone para estas una gran inversión en dinero, tiempo y recursos. Este tipo de empresas necesita prácticas de ingeniería del software adaptadas a su tamaño y tipo de negocio [9] [10] [11]. Y en este sentido, para apoyar a las pequeñas empresas en la mejora de procesos, se están desarrollando varias iniciativas, como la ISO/IEC 29110 para micropymes y pequeños grupos [12], que no estará lista hasta 2010; u otras como ITmark, Competisoft, etc., que por la mayor difusión de CMMI [5] son menos demandadas. Y por otro lado, uno de los paradigmas que más se ha adaptado y ha sido adoptado por pymes y micropymes es el Ágil. Y, sin embargo, metodologías ágiles y CMMI siempre han sido difíciles de unir3 [13].

2. Motivación para la certificación de UNKASOFT en el nivel 2 de CMMI UNKASOFT es una empresa dedicada al desarrollo de tecnología y servicios dentro del mundo del marketing móvil, especialmente en aplicaciones y juegos patrocinados mediante publicidad (advergaming), de ámbito internacional y para grandes anunciantes (Pepsi, Nokia, Renault, Philips, etc.). Cuenta con un equipo técnico y creativo de 15 personas y ha invertido desde el año 2004 más de 2 millones de euros en desarrollar su tecnología y procesos. Unkasoft trabaja en un sector claramente indefinido e inmaduro como es el denominado mobile marketing, donde a día de hoy no existen estándares establecidos y algunas compañías alrededor del mundo intentan posicionarse antes de que el mercado madure. Debido a esto, la ejecución de los proyectos es altamente inestable, con cambios de rumbo continuos y sin un patrón claro a seguir. A finales de 2007 se creó el grupo de mejora de procesos, con el objetivo de alcanzar, en el periodo de un año, el nivel de madurez 2 de CMMI, siendo este objetivo respaldado por la dirección de la empresa y ofreciendo los recursos necesarios para su consecución. Las principales motivaciones de la dirección fueron: • Sello de calidad reconocido internacionalmente (especialmente en EEUU, importante, debido a una inminente entrada de la empresa en el mercado norte americano) • Homogeneización de procesos en distintos departamentos. • Fijación del conocimiento en la empresa. • Establecer canales organizacionales de mejora y crecimiento.

El programa COMPETIC II4 supuso un claro empuje para afrontar las necesidades de implantación de un proceso ambicioso basado en CMMI-DEV v1.2 [14], y adecuarlas a los recursos limitados de una micropyme como Unkasoft.

3. Fases y recursos dedicados El equipo de mejora de procesos se formó inicialmente por una persona a tiempo completo, la cual tenía amplia experiencia en prácticas avanzadas de ingeniería del software, procesos y metodologías ágiles, así como en implantación y adaptación de herramientas “open source” orientadas a la gestión de proyectos. Dentro del marco del programa COMPETIC II, se siguió el plan de formación establecido e impartido por el “European Software Institute”, que pretendía dotar a los responsables de mejora de los conocimientos teóricos necesarios para la interpretación y adaptación del modelo CMMI a sus empresas. Este plan de formación se evaluó como muy recomendable, especialmente para las personas involucradas en la implantación que no tenían experiencia con modelos de calidad del software como CMMI o ISO 15504.

La fase de definición se desarrolló desde febrero hasta mayo de 2008, siendo necesario añadir un recurso al 50% a mitad de esta fase, para cumplir con los hitos acordados. También se contó con un consultor regional especializado en implantaciones de metodologías ágiles y CMMI, aportado por la empresa Códice Software. Durante esta fase de definió toda la arquitectura de la solución, planes de formación, roles y responsabilidades, canales de comunicación, procedimientos, políticas a distintos niveles, objetivos de negocio, preparación de las herramientas (incluida modificación, adaptación y ampliación de algunas de ellas), etc.

Desde Junio a Agosto de 2008 se continuó con la fase de pilotaje, donde se empezó a realizar la formación de los jefes de proyectos y auditores de calidad,

recayendo

posteriormente

sobre

ellos

buena

parte

responsabilidad de implantación en sus respectivos proyectos. En esta fase se empleó aproximadamente un recurso a tiempo completo, además de un 25% de la jornada de los jefes de proyecto. Durante esta fase se realizaron cambios continuos en los procesos para adecuarlos a las necesidades de los proyectos pilotados.

Desde Septiembre hasta Noviembre de 2008 se extendió el uso de los procesos al resto de la compañía, siendo necesarios nuevos ajustes. Durante esta fase se contó con una persona al 50% y apoyo de la consultora Kybele Consulting, más especializada en áreas organizacionales como medición y análisis. A partir de Diciembre de 2008 se entró en fase de SCAMPI A5, siendo ésta planificada en una revisión previa con el líder de la evaluación, una fase de readiness review (preparación de la auditoría) y una fase on site, estas dos últimas con el equipo de evaluación al completo. Tanto la readiness review como la fase on site tuvieron una duración de 1,5 semanas en las que participaron un evaluador líder, una persona de Unkasoft y dos evaluadores externos. Finalmente, en Enero de 2009, se completó la evaluación SCAMPI A, alcanzándose el nivel de madurez 2 y entrando en fase de mantenimiento, donde se está dedicando una persona a tiempo parcial para el mantenimiento y evolución de los procesos.

4. Metodologías y herramientas

Desde el inicio de la definición, se tenía claro que era necesario adaptar un proceso clásico, a uno dentro de la corriente ágil, basando la carga del proceso en herramientas y metodologías ágiles. Este espíritu ágil no surge de la dirección hacia la estructura, sino de forma de inversa y espontáneamente años atrás: los propios programadores y técnicos propusieron dichas mejoras en sus procesos, siendo estas escuchadas y valoradas por la dirección. La implantación de CMMI ha significado una oportunidad clara para poner en marcha todas estas mejoras propuestas a lo largo del tiempo y darles una forma más institucional.

Referencias [1] Piattini M, Garzás J. (eds). Fábricas de software: Experiencias, tecnologías y organización. Ra-ma, 2007.

[2] Hurtado J, Pino, F. y Vidal, J.. Software Process Improvement Integral Model: Agile SPI. Technical Report SIMEP-SW-O&A-RT-6-V1.0. 2005. Universidad del Cauca Colciencias, 2006. [3] SEI, Process Maturity Profile. CMMI v1.1, SCAMPI v1.1, Class A Appraisal Results. 2006 Mid-Year Update. Software Engineering Institute. 2006. [4] ISO, ISO/IEC 15504-2:2003/Cor.1:2004(E). Information technology Process assessment - Part 2: Performing an assessment. International Organization for Standardization, 2004. [5] INTECO, Estudio sobre la certificación de la calidad como medio para impulsar la industria de desarrollo del software en España, INTECO, 2008 (http://www.inteco.es/Calidad_del_Software/estudios_e_indicadores/publicacion es/calidad _sw_estudios_e_informes/Calidad_software_32, consultado por última vez en Abril de 2009). [6] Staples M., Niazi M., Jeffery R., Abrahams A., Byatt P. y Murphy R. "An exploratory study of why organizations do not adopt CMMI", Journal of Systems and Software, vol.80, nº 6, pp.883-895, 2007. [7] Hareton L. y Terence Y., "A Process Framework for Small Projects", Software Process Improvement and Practice, vol. 6, nº 2, pp. 67-82, 2001. [8] Saiedian H, Carr N., "Characterizing a software process maturity model for small organizations", ACM SIGICE Bulletin, vol. 23, nº1, p.2-11, 1997. [9] Fayad M.E., Laitinen M. y Ward R.P., "Software Engineering in the Small", Communications of the ACM, vol. 43, nº3, pp. 115-118, 2000. [10] Zahran, S., Software Process Improvement: Practical Guidelines for Business

FICHA DE REGISTRO DOCUMENTAL CODIGO: [SEI07] TIPO:

FUENTE:008

ELABORO:SARV

ARTICULO NOVIEMBRE DE 2007

TITULO:

MEJORA DE LOS PROCESOS PARA LA MEJORA DE PROCESOS Y SERVICIOS

AUTOR:

SOFTWARE ENGINEERING INSTITUTE SOFTWARE ENGINEERING INSTITUTE UNIVERSIDAD DE CARNEGIE MELLON CMU/SEI-2007-TR-017 ESC-TR-2007-017

UBICACIÓN:

http://www.sei.cmu.edu/reports/07tr017.pdf

DESCRIPCION: CMMI ® para la adquisición (CMMI-ACQ) ofrece una oportunidad para evitar o eliminar las barreras en el proceso de adquisición a través de prácticas y terminología que trascienden los intereses de los

distintos

departamentos

grupos. Este documento proporciona una guía para ayudar a que el adquirente

aplicar

las

mejores

prácticas

CMMI.

TABLA DE CONTENIDO: 1. INTRODUCCION, 2. ATAR TODO JUNTO,

PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, Modelo de madurez, Requisitos

RESUMEN 008 MEJORA DE LOS PROCESOS PARA LA MEJORA DE PROCESOS Y SERVICIOS 1. INTRODUCCION CMMI-ACQ contiene 22 áreas de proceso. De ellos, 16 son del modelo CMMI Fundación (CMF) que cubren las áreas de procesos de gestión de procesos gestión de proyectos y áreas de apoyo del proceso. Más información sobre el CMF se discute en el Capítulo 3. Seis áreas de proceso se centran en las prácticas específicas para hacer frente a la adquisición gestión de acuerdo, la adquisición de los requisitos de desarrollo adquisición de técnicas de gestión, la validación de la adquisición, la adquisición verificación, y la solicitud de acuerdo con el proveedor y el desarrollo. Todas las prácticas del modelo CMMI-ACQ se centran en las actividades de la adquirente. Estas actividades incluyen proveedores de abastecimiento, el desarrollo y la adjudicación contratos con proveedores y la gestión de la adquisición de capacidades, incluida la adquisición de productos y servicios. Proveedor actividades no se abordan en este documento. Proveedores y compradores que también el desarrollo de productos y servicios deben considerar el uso de la CMMIDEV modelo. CMMI-ACQ no especifica que una organización o proyecto debe seguir un adquisición en particular el flujo de proceso o de que un cierto número de entregas por día u objetivos específicos de rendimiento se logrará sólo que tienen procedimientos a fin de abordar adecuadamente prácticas relacionados con la adquisición. Para determinar si esto es así, un proyecto o mapas de la organización sus procesos para las áreas de proceso que figura en el este documento. El mapeo de los procesos de las áreas de proceso permite a los compradores para realizar un seguimiento sus progresos en el modelo CMMI-ACQ, ya que aplicar procesos. No es la intención de que cada área de proceso del modelo CMMI-ACQ asignará uno a uno con los procesos de una organización determinada, o proyecto.

Los niveles se utilizan en CMMI para describir una trayectoria evolutiva recomendado para una organización que quiere mejorar el proceso de se utiliza para adquirir capacidades, incluidos los productos y servicios. Niveles También puede ser el resultado de la actividad de calificaciones en 6 Valoraciones una. También las series sucesivas del proceso se pueden aplicar a las empresas toda o grupos más pequeños, tales como un pequeño grupo de proyectos o una división de una empresa.CMMI es compatible con dos caminos de mejora utilizando los niveles. Un camino permite organizaciones para mejorar gradualmente los procesos correspondientes área de proceso individual (o proceso de las áreas) seleccionada por la organización El otro camino permite a las organizaciones para mejorar una serie de reales procesos por los incrementos de direccionamiento del proceso como. Producción en físico no solo en software, menos costo por supuesto y menos tiempo en la creación de un producto.

Independientemente de la representación que usted elija, el concepto de nivel es siempre visible y el mismo. Caracterizar los niveles de mejora de un estado mal definidos a un Estado que utiliza datos cuantitativos para determinar un número de mejoras que se necesitan para satisfacer negocio de una organización como lo son sus objetivos.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [PEGR09] FUENTE: 009 ELABORO: SARV TIPO: TITULO: AUTOR: TUTOR:

TESIS DE PREGRADO MAYO DE 2009 IMPACTO DE LA APLICACIÓN DEL MODELO CMMI NIVEL 2 EN EL CICLO DE VIDA DE UN PROYECTO MARIA PEÑA GRACIA JOSÉ CARRILLO VERDÚN FACULTAD DE INFORMATICA UNIVERSIDAD POLITECNICA DE MADRID. ESPAÑA

UBICACIÓN: http://oa.upm.es/1645/1/PFC_MARIA_PENA_GARCIA.pdf

DESCRIPCION: En este proyecto se muestra una experiencia particular sobre la implementación de procesos para el desarrollo de software, siguiendo el modelo CMMI nivel 2. La Organización partía de un nivel básico o nivel 1. El proyecto esta dirigido a todos aquellos profesionales del desarrollo de software, interesados en conocer a través de un caso practico, una guía de buenas practicas para la mejora de los procesos de desarrollo, que suponen una sólida apuesta por las mejores practicas de gestión de la tecnología a nivel mundial

TABLA DE CONTENIDO: 1. INTRODUCCION, 2 EL MODELO CMMI SW/SE, 3. CONCLUSIONES

PALABRAS CLAVE: CMMI, Software Engineering Institute, Documento de Especificación de Requisitos del Sistema, Requisitos de usuario

RESUMEN 009 IMPACTO DE LA APLICACIÓN DEL MODELO CMMI NIVEL 2 EN EL CICLO DE VIDA DE UN PROYECTO 1. INTRODUCCION El modelo internacional CMMI SW/SE (Capability Model Integrated Software and Systems Engineering), comienza a desarrollarse en el ano 2002, mejorando el CMM como consecuencia de una evolución lógica en el ámbito de la tecnología, ya que analiza el software unido a la gestión de proyectos tecnológicos. Dicho modelo, permite a las organizaciones medir e incorporar mayores niveles de eficacia y madurez en sus procesos de desarrollo y mantenimiento de software, y esta considerados como uno de los mayores referentes mundiales en cuanto a producción de software. Antes de utilizar CMMI, los proyectos solían desviarse en plazos, se incrementaban los costes y la satisfacción del cliente no era la esperada. Como consecuencia de la aplicación del modelo, las aplicaciones se desarrollan de una manera distinta, se utilizan procedimientos nuevos, que requieren habilidades nuevas y todo ello impacta en el desarrollo de los proyectos, dentro de cada etapa del ciclo de vida.

2. EL MODELO CMMI SW/SE

Según la definición que hace SEI, CMMI es un modelo para la mejora de procesos, que proporciona a las organizaciones, los elementos esenciales para procesos eficaces. CMMI ayuda a integrar funciones organizativas, tradicionalmente separadas, establece objetivos y prioridades en la mejora de procesos, proporciona una orientación para la calidad de procesos, y un punto de referencia para la evaluación de los procesos actuales. Se puede decir que CMMI es como un “mapa”: Nos dice donde estamos, cuales son los posibles destinos, y nos indica los posibles caminos para llegar. CMMI no es un proceso, ni es una metodología, ni un estándar de calidad.

Dentro de cada área de proceso, existen objetivos específicos y genéricos. El objetivo especifico, son las características únicas que se deben satisfacer para cubrir un área de proceso determinada. El objetivo genérico, son las características que se deben satisfacer para institucionalizar un área de proceso determinada, entendiendo por institucionalizar, incorporar determinados aspectos dentro de la rutina de una organización como parte de su cultura corporativa. Las practicas, describen que hay que hacer, pero no el como. Constituyen las políticas, procedimientos y actividades fundamentales para las Áreas de Proceso. El nivel 2 de CMMI, consta de 7 áreas de proceso : • Gestión de requisitos (REQM): Gestión de los requisitos del proyecto y los productos esperados. Identificación de inconsistencias entre los Requisitos y el plan de proyecto. • Planificación de proyectos (PP): Establecimiento y mantenimiento de planes que definen las actividades a ejecutar durante el proyecto. • Seguimiento y control de proyectos (PMC): Control del progreso, identificación de desviaciones y toma de decisiones correctivas. • Gestión de la subcontratación (SAM): Gestión de la adquisición de productos y servicios a través de la existencia de un acuerdo formal con el proveedor. • Aseguramiento de la calidad (PPQA): Garantía de la calidad de los procesos aplicados y de los productos obtenidos. • Gestión de la configuración (CM): Establecimiento y mantenimiento de la integridad de los productos generados en el proyecto. • Métricas y análisis (MA): Desarrollo, mantenimiento y uso de capacidades de medida que soporten las necesidades de información de la organización.

En el nivel 1 los proyectos se realizan y gestionan de manera informal, basándose en el éxito en el conocimiento individual de las personas.

En el nivel 2 los proyectos se realizan de acuerdo a políticas, haciendo intervenir a gestores relevantes, y personas con el perfil adecuado para producir resultados controlados. Los proyectos son revisados, controlados y monitorizados, y se evalúa su ajuste a la descripción del proceso. La implantación en las empresas de este modelo en sus dos primeros niveles, se traduce en importantes beneficios, entre los que cabe destacar los siguientes: • Mayor efectividad en la detección de errores a lo largo del ciclo de vida, Reduciendo drásticamente el numero de errores que afecta directamente a los clientes y usuarios. • Reducción de las desviaciones en plazo de los proyectos. • Mayor tolerancia al cambio e incremento de la capacidad de adopción y Adaptación de nuevas tecnologías • Mejora en la rapidez y efectividad de respuesta ante exigencias del Negocio (Reducción del Time to Market) • Mejora en la colaboración y comunicación efectiva con implicados Internos y externos. • Resultados predecibles en los proyectos: • Sabemos en cuanto tiempo se realizan • Estimamos con mayor precisión • Implementar técnicas proactivas de gestión, mitigando los riesgos que Afectan los proyectos.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [SEI07] TIPO:

FUENTE:011

ELABORO: SARVFAMA

ARTICULO 12 DE MAYO DE 2006

TITULO:

TECNICAS DE MEJORA DE LA CALIDAD Y LA PRODUCTIVIDAD DEL SOFTWARE EN EL AMBITO DE LA INGENIERIA DE REQUISITOS Y LA V&V DE MODELOS

AUTOR:

MIGUEL ANGEL MARTINEZ AGUILAR FERNANDO MOLINA MOLINA AMBROSIO TOVAL ALVAREZ UNIVERSIDAD DE MURCIA DPTO INFORMATICA Y SISTEMAS

UBICACIÓN:

alarcos.infcr.uclm.es/calipso/data/presentacionesCR2006/NodoUM.pdf

DESCRIPCION: A Continuación se muestra la manera de implementar el CMMI en conjunto con otros tipos de procedimientos que también son de gran ayuda para la elaboración de un software pleno y optimo, además de explicar el CMMI aplicado en una empresa que busca mejoras en sus procesos en el proyecto

TABLA DE CONTENIDO: 1. INGENIERIA DEL SOFTWARE DE CALIDAD MEDIANTE IR 2.CALIDAD EN V&V DE MODELOS 3.RESUMEN

PALABRAS CLAVE: IR, V&V, Service Web, SIREN.

RESUMEN 011 TECNICAS DE MEJORA DE LA CALIDAD Y LA PRODUCTIVIDAD DEL SOFTWARE EN EL AMBITO DE LA INGENIERIA DE REQUISITOS Y LA V&V DE MODELOS 1. INGENIERIA DEL SOFTWARE DE CALIDAD MEDIANTE IR En esta pequeña introducción se explica la utilización del CMMI implementada en una empresa y proponen los recursos mas importantes según sus objetivos y destacan dos aspectos los cuales son los mas involucrados a la hora de realizar el software en la implementación de su modelo son: Madurez: se requiere en la organización Capacidad: cuando se implementa mas de un proceso y mas si son de diferentes fuentes, o mas bien no se han intentado complementar uno con el otro. Sin embargo en su implementación su enfoque es dirigido a los niveles de madurez 2 y 3, en su comprensión es admitido puesto que sin desmeritar los otros niveles estos son las bases para un buen desarrollo en la creación de un software. Se enfocan en una parte del segundo nivel no completamente pero su mirada esta fija en algo muy importante que es el detalle de dicho proceso lo llaman Gestión De Requisitos; básicamente no es un inconveniente manejar este tipo de proceso, requiere mucho análisis de carácter subjetivo, pues se busca y se consideran los requisitos que sean productivos, que no necesiten muchas modificaciones que satisfagan tanto al usuario como al objetivo de la empresa. El segundo es llamado Desarrollo de requisitos en este su implementación se basa en las decisiones, posibilidades y probabilidades de cada uno de estos detalles con respecto al usuario el producto y los objetivos de este mismo, su enfoque es observar a largo plazo estas posibilidades, que riesgos hay y como enfrentarlos inmediatamente para no tener inconvenientes en un futuro y encontrar solución a sus problemas.

Como anteriormente mencionรกbamos los autores no solo aplican un mismo proceso si no que completan uno con otro en este caso plantean la completacion del CMMI con el servicio SIREN su medio es el IR una de sus funciones al compactar estos dos servicios es buscar un mayor nivel de madurez del propio CMMI y por supuesto que los detalles estรฉn bien definidos en cada proceso.

2. CALIDA V&V EN MODELOS

Con referencia a lo anterior plantean los diversos tipos de verificaciรณn y Validaciรณn esto significan las dos V&V, estos procesos estรกn en el nivel 3 de madurez del CMMI y dan apoyo a muchos de los requisitos que se encuentran en ellos los autores lo plantean de la siguiente manera.

Verificaciรณn: en este se confirma que los procesos que se estรกn llevando acabo cumplen con todos los detalles y requisitos.

Validaciรณn: se observa que dichos procesos creados son los indicados para la soluciรณn del problema planteado, para el logro de los diferentes objetivos.

3. RESUMEN

El CMMI es utilizado en sus niveles de madurez muy minuciosamente, el objetivo de este articulo es comunicar como su funcionalidad puede brindarnos ayuda, ademรกs de lรณgicamente imponer su estilo y adaptarlo con mas posibilidades, pero sin perder el objetivo de que se debe emplear para que los procesos sean con carรกcter de variabilidad, reutilizaciรณn y trazabilidad

FICHA DE REGISTRO DOCUMENTAL CODIGO: [GRCA09] FUENTE: 012 ELABORO:SARVFAMA TIPO:

TESIS DE GRADO JULIO 2009 DISEÑO E IMPLEMENTACION DE UN MODELO DE SIMULACION PARA EL GOBIERNO DE LAS TIBASADO EN ITIL v3, MOF Y CMMI TITULO: FOR SERVICES Ismael Granizo Castillo AUTOR: Tutor: Antonio Folgueras Marcos Universidad Carlos III de Madrid España UBICACION earchivo.uc3m.es/bitstream/10016/6232/1/PFC_Ismael_Granizo_Castill o.pdf

DESCRIPCION: Este es un proyecto que como su nombre lo indica es enfocado hacia el gobierno para la solución de ideas y la generación de empleo, el CMMI no solo es lo que su nombre lo indica, si no como anteriormente se informo se divide en sus componentes y uno de los mas característicos es el CMMI para servicios que a continuación se describe con mas detalle.

TABLA DE CONTENIDO: 1. CMMI for services

PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, CMMI-SVC.

RESUMEN 012 DISEÑO E IMPLEMENTACION DE UN MODELO DE SIMULACION PARA EL GOBIERNO DE LAS TIBASADO EN ITIL v3, MOF Y CMMI FOR SERVICES 1. CMMI for service

CMMI for Services es una colección de las mejores prácticas que han sido generadas desde CMMI Architecture and Framework. Esta colección incluye servicios de las mejores prácticas del gobierno y la industria. CMMI-SVC está basada en el “CMMI Model Foundation” o “CMF” e incorpora el trabajo de varias organizaciones de servicios necesarios para adaptar CMMI al uso del servicio de la industria

El modelo CMMI-SVC provee de una guía para la aplicación de las mejores prácticas de CMMI por la organización proveedora del servicio. Las mejores prácticas en el modelo están orientadas hacia actividades para dar la mejor calidad posible a los servicios orientados a los clientes y a los usuarios finales. Mediante la integración de este tipo de conocimiento, CMMI-SVC provee un conjunto comprensivo de las mejores prácticas para proporcionar servicios. CMMI-SVC contiene 24 áreas de procesos. De todos estos, 16 provienen de las áreas de proceso del CMMI Model Foundation (CMF), 7 son procesos específicos de servicios y uno es una adición.

Todos los modelos de prácticas de CMMI_SVC eran orientadas en las actividades dedicadas a proveer servicios. Siete de las áreas de procesos orientan en practicas especificas de servicios, añadiendo capacidad, disponibilidad y gestión, continuidad del servicio, entrega del servicio, resolución y prevención de incidencias, transición del servicio, desarrollo del sistema de servicios, y procesos de gestión estratégica de servicios.

CMMI-SVC extrae los conceptos y las buenas prácticas de CMMI y de otra serie de estándares de servicios orientados y modelos como los que se enuncian a continuación:

ITIL (Information Technology Infraestructure Library).

Iso/IEC 20000: Information Technology-Service Management.

CobiT (Control Objects for Information an related Technology).

ITSCMM (Information Technology Services Capability Mautiry Model).

No es necesario familiarizarse con estos u otros estándares y modelos de servicios para poder comprender CMI-SVC, y esta colección no se encuentra estructurada de manera que intente parecerse o seguir lo pasos de cada uno. A pesar de esto, conocer esta serie de estándares y modelos puede facilitar en gran medida el entendimiento del contenido y los modelos de CMMI-SVC. Esta serie de servicios presentados en CMMI-SVC se encargan de cubrir las diversas actividades requeridas para el establecimiento, entrega y gestión de servicios. Como se encuentra definido e el contexto de CMMI, un servicio es un intangible, un producto no reservado. El modelo CMMSVC ha sido desarrollado para ser compatible con esta definición. Las metas y las prácticas de CMMI-SVC son potencialmente relevantes para cualquier organización preocupada con la entrega de servicios, incluyendo empresas de sectores de defensa, tecnologías de la información (IT), cuidado de la salud, finanzas y transporte. El conjunto de servicios contiene prácticas que da cobertura a la gestión de proyectos, a la gestión de procesos, al establecimiento de servicios, a la entrega y soporte de servicios, y al mantenimiento de procesos.

FICHA DE REGISTRO DOCUMENTAL CODIGO:[MAMI08] TIPO:

FUENTE:013

ELABORO: SARVFAMA

TESIS DE MAGISTER JULIO 2008

TITULO:

HERRAMIENTA PARA SOPORTE AL PROYECTO DE MEJORA DE CALIDAD DE PROCESOS CON MODELOS CMMI E IDEAL

AUTOR:

JESICA A MADRID MIELES UNIVERSIDAD DE CHILE

UBICACIÓN:

www.slideshare.net/JesicaMadrid/sistema-paraimplementacion-de-cmmi-simple-presentation

DESCRIPCION: En las diversas industrias y específicamente en la industria del software, existen varios determinantes de la calidad de los productos y los servicios , el que mas se tiene en cuenta en esta tesis son los procesos pues tiene gran incidencia en el producto y en la calidad de los procesos de las empresas.

TABLA DE CONTENIDO: 1. SOLUCION PROPUESTA 2. VALIDACION DE LA HERRAMIENTA PALABRAS CLAVE: CMMI, PROYECTO, PROCESO, PRODUCTO, SERVICIO

RESUMEN 013 HERRAMIENTA PARA SOPORTE AL PROYECTO DE MEJORA DE CALIDAD DE PROCESOS CON MODELOS CMMI E IDEAL 1. SOLUCION PROPUESTA Los modelos de este tipo como el CMMI proporcionan:

Un marco referencial. Promueven usos de métodos. Facilitan comunicación pues tiene un lenguaje en común.

Cada proceso cuando se nombra ha este se hace referencia a los diferentes tipos de madurez del propio sistema, y cada uno de estos posee su propia descripción del problema el cual detalla el objetivo de la empresa esto quiere decir q posee un conjunto de practicas agrupadas que trabajan entre si.

Como todas las empresas que emplean este modelo lo hacen con el riesgo a tomar de tiempo y costo pero al saber que en su pasar del tiempo después de estar en sus proyectos creado el buen modelo planteado, dará frutos y será productivo el tiempo implicado en el que se realizaron los diferentes procesos para dicha compañía.

En este campo e introduce un nuevo tipo de sistema se llama IDEAL el cual acrecienta mas el CMMI y lo complementa, es básicamente lo anteriormente mencionado en fichas anteriores se utiliza los estados de madurez con sus diferentes detalles a definir y se implenta ideal para evaluar los procesos del CMMI.

2. VALIDACION DE LA HERRAMIENTA

En este proceso nos damos cuenta que no todo depende unicamente de los procesos del CMMI requiere en realidad de las personas involucradas para el desarrollo optimo de los diferentes objetivos fuera de los detalles y demas cosas el CMMI es optimo si se enfoca como debe ser en las personas.

FICHA DE REGISTRO DOCUMENTAL CODIGO:FEARGORO08 TIPO:

FUENTE:014

ELABORO: SARVFAMA

ARTICULO 2008

TITULO:

CMMI

AUTOR:

JUAN MARCELO FERREIRA ARANDA SILVANO CHRISTIAN GOMEZ MARCELO RODAS UNIVERSIDAD NACIONAL DE ASUNCION INGENIERIA DEL SOFTWARE III

UBICACIÓN:

www.slideshare.net/albinogoncalves/introduccin-a-cmmi

DESCRIPCION: En las organizaciones se hacen planes para la creación de los objetivos para la creación del software peo no se cumplen, los requerimientos son muy cambiantes, y los problemas casi siempre son encontrados por los clientes los cuales utilizan el sistema.

TABLA DE CONTENIDO: 1. conceptos generales 2. importancia del proceso 3. conclusiones

PALABRAS CLAVE: Cmmi, enfoques, costo tiempo, detalles

RESUMEN 014 CMMI 1. CONCEPTOS GENERALES Define modelos para la mejora de evaluación de los procesos de desarrollo y mantenimiento, y mantenimiento de sistemas en los productos de un software, es claro q este puede trabajar con un sistema el cual ya ha sido montado, o empezar a utilizarse en uno el cual se encuentre en pleno desarrollo.

Lo que se debe tener en cuenta es que se depende de una serie de procesos ya anteriormente mencionados los cuales, hacen mas eficientes los requisitos, y hacen un campo mas detallado de dicho sistema en desarrollo.

De esta manera se cataloga si una empresa es madura o inmadura en su software si no cumple con una serie de requisitos o si su nivel en el ciclo del CMMI es significativamente bajo.

El CMMI no es un proceso No es una metodología para el desarrollo y gestión de proyectos No asume el modelo iterativo.

2. IMPORTANCIA DEL PROCESO

El CMMI busca servir como base para cualquier organización que requiera o implemente esta modalidad de software con el objetivo de en su dinámica mejorar la organización y el componente o los componentes del software.

También para servir de guía en la implantación mantenimiento etc. Un proyecto producto o servicio el cual requiera estos elementos en los procesos.

Utilizando cada nivel de madurez en su implementaciรณn, con caada detalle fortificar el servicio producto proyecto para el buen funcionamiento de este a futuro, no solo de pende de su estado actual, eso es lo bueno de este sistema, permite evaluar las diferentes circunstancias en una de estas etapas las cuales a futuro puedan afectarnos y las enfrenta para en caso de que se de, tener una soluciรณn a dicho inconveniente.

3. CONCLUSIONES La mayorรญa de las empresas buscan como base los niveles 2 y 3 es una buena recomendaciรณn y experiencia pues estas son las bases para la creaciรณn de un software lo bastante maduro para ser completo. A continuaciรณn mostramos q para metros se utilizan en estos estados fundamentales.

Nivel 2 Gestiรณn de Requisitos Planificaciรณn del proyecto Seguimiento y control del mismo Gestiรณn de Acuerdos con proveedores Medidas y anรกlisis Medidas de calidad en el proceso y el producto Gestiรณn de configuraciรณn Nivel 3 Gestiรณn de requisitos Soluciรณn Tรฉcnica Integraciรณn Del producto Verificaciรณn Validaciรณn Enfoque organizacional del proceso Definiciรณn del proceso de la organizaciรณn Formaciรณn en la organizaciรณn Gestiรณn de riesgos Anรกlisis de decisiones y resoluciรณn

FICHA DE REGISTRO DOCUMENTAL CODIGO:[CAVE09]

FUENTE:015

ELABORO: SARVFAMA

. TIPO:

TITULO: AUTOR:

LIBRO DIGITAL 2009 PROPUESTA DE METODOLÓGICA PARA LA REALIZACIÓN DE PRUEBAS DE SOFTWARE EN AMBIENTES PRODUCTIVOS CRHISTIAN DE JESUS CARDONA VELASQUEZ UNIVERISDAD NACIONAL DE COLOMBIA, Medellín Facultad de minas Escuela de sistemas e informática

UBICACIÓN:

www.bdigital.unal.edu.co/930/1/8357252_2009.pdf

DESCRIPCION: Las pruebas de software como parte de los planes de aseguramiento de la calidad ofrecen a los productos de software la posibilidad de identificar y remover los defectos que surgen dentro del proceso productivo. La estandarización por parte de diferentes organismos ofrece diferentes formas de implementar los procesos de pruebas, todos ellos con la característica común de ser genéricos y basados en ciclos de madurez que permiten la medición y optimización del mismo.

TABLA DE CONTENIDO: 1 ANÁLISIS DE TRABAJOS EXISTENTES 1.1 CMMI

PALABRAS CLAVE: CMMI, QA o Aseguramiento de la Calidad, Outsourcing, Myers.

RESUMEN 015 HERRAMIENTA PARA SOPORTE AL PROYECTO DE MEJORA DE CALIDAD DE PROCESOS CON MODELOS CMMI E IDEAL 1. ANALISIS DE TRABAJOS EXISTENTES 1.1 CMMI En CMMI , existen tres áreas de proceso (PA, por sus siglas en inglés) que están dirigidas explícitamente a asegurar la calidad del software; éstas son: 1. QA o Aseguramiento de la Calidad: hace parte del segundo nivel de madurez de CMMI (nivel gestionado) y su objetivo principal es que los procesos y los elementos de trabajo cumplan los procesos; de ésta forma la norma sugiere la realización de ciertas tareas para cumplir con dicha área de proceso las cuales incluyen: a) Evaluar objetivamente la ejecución de los procesos, los elementos de trabajo y servicios contra las descripciones de procesos, estándares y procedimientos. b) Identificar y documentar los elementos no conformes. c) Proporcionar información a las personas que están usando los procesos y a los gestores de los resultados de las actividades del aseguramiento de la calidad. d) Asegurar que los elementos no conformes son corregidos. Generalmente en la industria del software, al momento de implantar ésta área de proceso se tiende a subcontratar las pruebas de software bajo el modelo de “Outsourcing”. En otros casos la subcontratación no se da; en su lugar se establece un área de pruebas al interior de la empresa ligada al proceso productivo. En general los autores aseguran que la clave de éxito o fracaso de los pruebas de software están asociadas a la subcontratación o no de las mismas. Algunos como Myers [3] aseveran que la subcontratación es vital para que la calidad del software sea conforme debido a que no se sesgan los resultados de las pruebas. Contrariamente, otros autores dicen que los procesos de aseguramiento de la calidad, específicamente los relacionados con las pruebas de software, deben ir inmersos totalmente en el proceso productivo de la organización, dado que la retroalimentación y su interrelación agregan madurez a todo el proceso.

La verificación y la validación, pretenden en cualquier estándar (y particularmente en CMMI) convertirse en una herramienta para la colaboración y el incremento del rendimiento del los equipos de trabajo, permitiendo así la conformidad del producto final basada en altos estándares de calidad. 2. Verificación: hace parte del tercer nivel de madurez en CMMI [1] (nivel definido). Su propósito principal es el de asegurar que los productos de trabajo seleccionados responden a los requisitos especificados. Sus objetivos o metas específicas son: preparar la verificación, realizar revisiones por terceros y verificar los productos de trabajo seleccionados. 3. Validación: Hace parte del tercer nivel de madurez en CMMI [1] (nivel definido). Su propósito es el de demostrar que un producto o componente satisface su uso, en el ambiente operativo planeado. Sus objetivos o metas específicas son: preparar la validación y realizar la validación de los productos o componentes de trabajo. Aunque ambas áreas de proceso no son consideradas como pruebas de software directamente, si tiene un valor relevante a la hora de hacer que los productos de software posean características de alta calidad. Las prácticas que se derivan permiten realizar pruebas de software sobre productos más maduros y confiables. Es importante tener presente, que los procesos de pruebas no componen totalmente área de proceso de aseguramiento de calidad; es así como las pruebas proveen los elementos y prácticas de mejora con el fin de retroalimentar los procesos.

BIBLIOGRAFIA Carnegie Mellon University. 2006. Capability Maturity Model® Integration (CMMI) Versión 1.1. Veenendaal V., Swinkels, R. 2002. Guidelines for Testing Maturity. Published in: Professional Tester, Volume Three, Issue No. 1 Myers, G.J., 2004. The art of software Testing. pp 6.

McGregor J.D., Sykes D.A., 2001. A Practical guide To testing Object-oriented software. pp. 14. Tian J. 2005. Software Quality Engineering. IEEE Computer Society Executive Staff.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI16] FUENTE: 016 ELABORO:FAMA TIPO:

TITULO:

AUTOR:

INFORME TECNOLOGICO Modelo de Registro y Acreditación de Instituciones de Educación Superior basado en el Modelo CMMI María Mercedes Larrondo Petrie Víctor Hugo Medina García Germán Méndez Giraldo Seventh LACCEI Latin American and Caribbean Conference for Engineering and Technology (LACCEI’2009) “Energy and Technology for the Americas: Education, Innovation, Technology and Practice” June 2-5, 2009, San Cristóbal, Venezuela

UBICACIÓN: DESCRIPCION: El artículo pretende mostrar la propuesta de un modelo para registrar y acreditar las instituciones de educación superior con base en los nuevos avances que se han realizado en el modelo CMMI (Capability Maturity Model Integration). El modelo propuesto busca desde luego mejorar la capacidad de los procesos en las instituciones de ingeniería, las facultades de ingeniería y los estudiantes de ingeniería. Lo que se persigue con esta retroalimentación es refinar los multiniveles en los programas de ingeniería como instrumento que aseguren movilizar los programas a regiones donde aún faltan estos sistemas de acreditación.

TABLA DE CONTENIDO:

1 Introducción 2 Conceptualización de modelos de mejora de organizaciones 3 MODELO DE ACREDITACIÓN PROPUESTO PALABRAS CLAVE: Acreditación, Ingeniería, CMMI, Madurez, Capacidad

RESUMEN 016 Modelo de Registro y Acreditación de Instituciones de Educación Superior basado en el Modelo CMMI 1. INTRODUCCIÓN Hoy en día se les reconoce a las instituciones de formación superior el esfuerzo por producir un ingeniero global, esto en parte se debe a la necesidad de la creación de un Registro Internacional para los Ingenieros, necesidad que se incrementa vertiginosamente con los procesos socio-económicos y culturales de la época, esta importancia de un reconocimiento internacional de los títulos de ingeniería se puede y debe dar gracias a los procesos de acreditación. En muchos países y en todas las regiones del mundo, se hacen esfuerzos por adoptar un sistema de acreditación de los programas de ingeniería, pero estos esfuerzos se han encontrado con un gasto excesivo y a la vez prohibitivo para adoptarlos como en el caso de los sistemas ABET o CEAB que son en esencia equivalentes. En la pasada Conferencia Internacional del LACCEI (del inglés Latin American and Caribbean Consortium of Engineering Institutions), Consorcio de Instituciones de Ingeniería para Latinoamérica y el Caribe) de la cual son socios fundadores entre otras universidades, la FAU (Florida Atlantic University) y la Universidad Distrital Francisco José de Caldas de Bogotá, Colombia, se propuso la elaboración de un modelo de acreditación institucional basado en una evaluación por niveles y dependiendo de las capacidades de las instituciones y que en un futuro se convierta en una metodología que facilite y permita obtener la acreditación, en primer lugar de todas las instituciones socias del LACCEI y en segundo término, faciliten los procesos de acreditación de otras instituciones de educación superior, especialmente de América Latina y del Caribe.

2. CONCEPTUALIZACION DE MODELOS DE MEJORA DE ORGANIZACIONES El objetivo del sistema es garantizar a la sociedad que las Instituciones de Educación Superior, que hacen parte del Sistema, cumplen con los más altos requisitos de calidad y realizan sus propósitos y objetivos.

El Modelo de Acreditación del CNA consta de los siguientes elementos: • Criterios: Pautas de conducta que definen el Marco Ético. • Factores: Son grandes áreas de desarrollo institucional que expresan los elementos con que cuenta la institución y sus programas para su quehacer académico. • Características: Son dimensiones de la Calidad de un Programa o Institución con relación a cada Factor. Describen el nivel de logro deseable. • Indicadores: Referentes empíricos cuantitativos, cualitativos y de verificación, que permiten dimensionar o apreciar cada aspecto o característica. En el modelo CNA los factores de Alta Calidad que se analizan a nivel del pregrado o carreras profesionales son: • Misión, visión y proyecto institucional. • Estudiantes. • Profesores. • Procesos académicos y estructura curricular. • Bienestar y ambiente institucional. • Organización, administración y gestión. • Egresados e impacto sobre el medio. • Recursos físicos y financieros.

3. MODELO DE ACREDITACIÓN PROPUESTO Basados en las experiencias y el éxito del modelo CMMI aplicado al desarrollo de software, se propone el siguiente modelo de apoyo al proceso de acreditación, en especial a aquellos programas e instituciones del campo de la ingeniería: El nivel 1 - Inicial, arranca con las condiciones mínimas que debe cumplir un programa académico (Institución) para brindar el servicio de formación. Este nivel determina la capacidad para cumplir con los mínimos del que hacer del programa y que no es otro que la transmisión de conocimiento, cumpliendo con el proceso básico de formación. En este nivel pueden estar inmersos los ciclos 1 y 2 de formación, es decir técnicos y tecnólogos y aquellos programas incipientes de nivel 3 o formación profesional. El nivel 2 - Gestionado, este involucra a un programa académico (Institución) que cumpliendo con las condiciones mínimas de calidad esta empeñado en la búsqueda de estándares más alto de calidad, deseo y voluntad que se hace visible en la administración del mismo. Para ello encuentra necesario escuchar y entablar diálogos con los usuarios/beneficiarios para dar una respuesta a lo que la sociedad reclama. En este nivel además de cubrir el espectro de formación, el programa absorbe el ámbito de la extensión, es decir el de cubrir otros actores y servicios en la universidad. Nivel 3 - Definido, aquí el programa (Institución) que se ubique en este nivel no solo cumple con los proceso de formación y extensión, sino que su nivel de madurez y calidad le permite hacer generación y apropiación de nuevos conocimientos gracias a los procesos de investigación. En el caso de los programas y/o instituciones de ingeniería, este nuevo conocimiento tendrá que ser aplicado aportando un valor a la sociedad. Nivel 4 - Gestionado cuantitativamente, en este nivel, el programa (Institución) ya ha cumplido en general con su misión y ahora se ocupa que su proceso de gestión se eleve a estándares significativos de calidad. Y para conseguirlo debe evolucionar en unos procesos Sistemáticos que partiendo de la gestión de datos, alcance su desarrollo hasta lograr la gestión del conocimiento, permitiendo una mejor interacción con múltiples actores de la sociedad. Nivel 5 - En optimización, para alcanzar este nivel el programa (Institución) ha completado a cabalidad la misión para el cual fue creado y ahora su marco de acción se basa en lograr un objetivo teleológico denominado visión que no es otro que la mejora continua. Hacer cada vez mejor su proceso de formación, de servicio a la comunidad, de investigación, de propia gestión y que lo conduzca a ser un lider de su campo disciplinar, con voz y voto en la sociedad. REFERENCIAS Carnegie Mellon University, Software Enginering Institute 1995). (Principal Contributors and Editors: M. C. Paulk, B. Curtis, M.B. Chrissis), The Capability Maturity Model: Guidelines for Improving the Software Process, Reading, MA: Addison-Wesley.

Chaparro Fernando, Niño Virgilio y Diana Lago. (2007). “Acreditación de Alta Calidad de Maestrías y Doctorados”. CNA. Reunión de ASCUN. Manizales. 2007. Deming, W. E. (1982). “Out of Crisis”. Cambridge, MA: MIT Center for Advancement Engineering. Crosby, P. B. (1979). “Quality is Free”. New York: McGraw-Hill. Juran, J. M. (1988). “Juran on Planning for Quality”. New York: MacMillan. Larrondo Petrie, Maria M. (2004). “A Model for Assessment and Incremental Improvement of Engineering and Technology Education in the Americas,” in Proceedings of the 2nd LACCEI International Latin American and Caribbean Conference on Engineering and Technology, Miami Florida. Medina Víctor (2008). “Gestión de Calidad”. Documento de la asignatura de Ingeniería de Software II. Universidad Distrital. Bogotá. Navegapolis. (2008). http://www.navegapolis.net/index.php?option=com_content&task=view&id=330 & Itemid=84 [fecha de consulta: 15 de enero de 2009]. Wikipedia (2008). Colaboradores de Wikipedia. CMMI [en línea]. Wikipedia, La enciclopedia libre, [fecha de consulta: 11 de enero del 2009]. Disponible en <http://es.wikipedia.org/w/index.php?title=CMMI&oldid=22261922>.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI17] FUENTE: 017 ELABORO:FAMA TIPO: TITULO: AUTOR:

UBICACIÓN:

Informe Técnicos Integración CMMI/TSP/SixSigma Pablo Cruz Navea CODIGO DE OBRA 0710040050678 Calidad y Productividad de Software Departamento de Informática Universidad Técnica Federico Santa María 22 de junio de 2009

DESCRIPCION: Entregas fuera de plazo, costos sin control, demasiado tiempo gastado en rework, y miembros del equipo frustrados son típicos síntomas de que los procesos dentro de la organización están funcionando incorrectamente. El problema es que la calidad del producto o servicio esta intensamente relacionada con la calidad del proceso. Si el proceso es uno fallido, se hace muy difícil predecir la TABLA DE CONTENIDO: calidad del producto o servicio final. Los procesos en la organización 1. INTRODUCCION, 2. FUNDAMENTOS DE LA INTEGRACIÓN se encargan 3. de SIXSIGMA conjugar a los miembros (personas)CON de laCMMI/TSP, misma CMMI/TSP, Y LA INTEGRACIÓN 4. INTEGRACIÓN DE SIXSIGMA CON CMMI/TSP junto con la tecnología PALABRAS CLAVE: Capability Maturity Model Integration CMMI®, Modelo de madurez, Requisitos

RESUMEN 017 Integración CMMI/TSP/SixSigma 1. Introducción En general, el desarrollo de proyectos de software es realizado por equipos. El desarrollo es, entonces, un esfuerzo colectivo que necesita conocimientos y orientación. Team Software Process es un framework y proceso industrial para equipos que desarrollan o mejoran proyectos de software de gran escala. Una alternativa es TSPi, una versión de escala reducida de TSP [4]. El proceso intenta satisfacer, al menos, las siguientes necesidades:  Creación rápida de equipos auto dirigida.  Creación de equipos que puedan desarrollar proyectos de software dentro de la planificación y el presupuesto establecidos.  Asegurar comunicación continua en los miembros del equipo. TSP fue desarrollado como una expansión de PSP (Personal Software Process). Mientras PSP se encarga de abordar las competencias de los miembros de los equipos, TSP se encarga de la construcción y gestión de los equipos de desarrollo. TSP parte de la base de que los miembros del equipo han sido entrenados correctamente utilizando PSP. 2. Fundamentos de la integración CMMI/TSP La integración entre CMMI y TSP es posible. CMMI y su framework provee ideas que guían a las organizaciones en lo que deben hacer para mejorar procesos. TSP provee principios orientados a la creación y gestión de equipos que permiten la implementación de varias de las prácticas esperadas en CMMI. Es decir, varios procesos de TSP pueden ser mapeados a aéreas de procesos de CMMI. Además, TSP permite alcanzar con mayor rapidez niveles de madurez elevados en CMMI. En la práctica, se puede citar el ejemplo de dos organizaciones NAVAIR (U.S. Naval Air Systems Command) que integraron el uso de la metodología propuesta por TSP con CMMI y lograron pasar del nivel 1 de madurez al nivel 4 en treinta meses [5], menos de la mitad del tiempo promedio que otras organizaciones han tomado para progresar en los mismos niveles. Además, la Hill Air Force Base es la primera organización gubernamental de Estados Unidos en obtener el rating de CMMI Nivel 5. El primer proyecto utilizando TSP mostro un 123% de aumento de la productividad del equipo y el tiempo de pruebas se redujo de 22% a 2.7% en promedio en toda la organización [4].

3. SixSigma y la integración con CMMI/TSP Definir SixSigma no es simple. SixSigma es una idea y una metodología. SixSigma es una idea porque transforma la organización: exige que la organización escuche al cliente. Es un elemento central de SixSigma la voz del cliente. Independiente de los mecanismos y herramientas especificas utilizadas para la implementación de SixSigma en una organización, el elemento central es el cliente2. También es una metodología: propone una metodología específica para el análisis, mejora y control de los procesos de la organización. El nombre SixSigma tiene su origen en el concepto de varianza en estadística se conoce como desviación estándar y corresponde a una medida de dispersión o variabilidad entre los valores que resultan de un proceso y el valor esperado del mismo proceso. Es imposible que un proceso tenga resultados iguales cada vez que se desarrolle. Existe una infinidad de factores que afectan el resultado de un proceso. El interés en SixSigma no es reducir a cero la variabilidad, sino más bien disminuir la variabilidad del proceso encontrando las causas que la provocan. Cuando un proceso opera en 6 estar a produciendo solo 3.4 defectos por millón de oportunidades. En una distribución de probabilidad Normal el valor de 6_ corresponde a 3 veces hacia la derecha de la media y 3 veces hacia la izquierda de la media. La media (denotada por) es la medida de tendencia central que corresponde al valor esperado del proceso. Por ejemplo, una organización podría esperar = 10 defectos con una dispersión de = 2 defectos en los proyectos de software que desarrolla. Si los defectos se distribuyen normalmente, la cantidad de defectos de proyectos futuros debería encontrarse en el rango [4; 16]. Si la organización define como proyecto exitoso a aquel que opere en ese rango de defectos, entonces la organización se encontrara operando en 6_. Por el contrario, si la organización define como proyecto exitoso a aquel que opere en el rango de defectos [6; 14] entonces la organización estaría operando en 4. En 4, la organización estaría generando 6200 proyectos no exitosos por millón de oportunidades. Esto porque la probabilidad de producir proyectos con numero de defectos (distribuidos normalmente con u= 10 y o= 2) en el rango [6; 14] es de 0.9938 (se obtiene de: 1000000 _ (1 0; 9938) = 6200). >Cual es la solución? SixSigma provee una gran cantidad de herramientas y metodologías orientadas a reducir el valor de _ de manera que la organización opere en 6o.

4. Integración de SixSigma con CMMI/TSP La integración de SixSigma con CMMI/TSP puede traer beneficios mutuos. La implementación de SixSigma en una organización se verá beneficiada por el contexto de mejoramiento de procesos que aparece con la implementación de CMMI. Específicamente, las siguientes aéreas de procesos serán particularmente útiles para el despliegue de SixSigma:  Medicion y analisis.  Planificación de proyectos.  Gestión de riesgos.  Gestión de requerimientos. Las aéreas de procesos mencionadas son recomendadas para SixSigma, pero no se limitan a estas. El proceso TSP permitirá la creación de equipos de trabajo (en la etapa de definición del modelo de resolución de problemas de SixSigma) que tengan las siguientes características:  Alta comunicación.  Un proceso de trabajo común.  Capacidad de planificación de proyectos.  Alta coordinación. Por otra parte, CMMI se verá beneficiado de SixSigma ya que sus herramientas de análisis asociadas permiten realizar análisis causa-efecto, gestión cuantitativa de procesos, y mejoramiento y optimización continua. En este sentido, las aéreas de procesos de CMMI que más se verán beneficiadas son:  Análisis causal y resolución.  Monitoreo y control de proyectos.  Aseguramiento de calidad del proceso y producto.  Gestión cuantitativa de proyectos. El lector debe tener claro que no es un requerimiento para SixSigma la existencia de una implementación de CMMI ni de TSP en una organización. Solo se resalta los beneficios mutuos y algunas ideas generales de una posible integración entre SixSigma y CMMI/TSP.

ferencias [1] SEI, \Carnegie Mellon Software Engineering Institute Celebrates 100,000th Student Trained in Introduction to CMMI", http://www.sei.cmu.edu/about/press/releases/ cmmimilestone.html, fecha de revisión: 17 de junio de 2009.

[2] D. Galin, \Software Quality Assurance: From theory to implementation", Pearson Education, _rst published in 2004. [3] CMMI Product Team, \CMMI for Development, Version 1.2", Carnegie Mellon University, 2006. [4] W. S. Humphrey, \The Team Software Process (TSP)", SEI Technical report, Carnegie Mellon University, 2000. [5] D.Wall, J. McHale, M. Pomeroy-Hu_, \Case Study: Accelerating Process Improvement by Integrating the TSP and CMMI", SEI Technical report, Carnegie Mellon University, 2005. [6] D. H. Stamatis, \Six Sigma Fundamentals - A Complete Guide to the System, Methods and Tools", Productivity Press, 2004. [7] P. Pande, L. Holpp, \What is Six Sigma?", McGraw-Hill, 2002. 10

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI18] FUENTE: 018 ELABORO:FAMA TIPO: TITULO: AUTOR:

Informe Técnicos Gestión de riesgos con CMMI, RUP e ISO en Ingeniería de Software Minero Alfonso Romero B.1, Daniel Lovera D.1, Simeón Yaringaño Y.1, Silvana Flores Ch.2 Revista del Instituto de Investigaciones FIGMMG Vol. 10, Nº 19, 55-61 (2007) UNMSM ISSN: 15610888 (impreso) / 1628-8097 (electrónico)

UBICACIÓN: DESCRIPCION:Los periodos de cambio y evolución continua de las tecnologías de información y comunicación, cada vez más se ven reducidos en tiempo, así tenemos; hoy que en materia de software o programas informáticos de aplicación en minería; estos entran en estado de obsolescencia a en un promedio de doce meses desde su puesta en funcionamiento. En los últimos dos años el diseño de nuevas aplicaciones informáticas han sufrido cambios importantísimos en el enfoque inicial para su diseño, análisis y codificación, así pues; desde que Bohem en 1982 advirtió algunas técnicas relacionadas con la ingeniería de software hoy observamos que estas técnicas y metodologías de análisis y diseño de aplicaciones informáticas han variado significativamente en relación al enfoque inicial. La continúa aplicación de las normas y técnicas como CMMI, RUP e ISO han hecho que estos sean perfeccionados año a año, apareciendo de esta manera las versiones beta y/o versiones en general. En este articulo mostramos que el punto crítico de la elaboración y creación de aplicaciones informáticas radica en la gestión de riesgos del proyecto de ingeniería de software, así pues; cada técnica o metodología como el CMMI, RUP o ISO tienen siempre enfocado en su contenido la gestión de riesgos en proyectos de ingeniería de los programas de aplicación en minería.

TABLA DE CONTENIDO: 1. RIESGOS EN PROYECTOS DE SOFTWARE, 2. GESTIÓN DE RIESGOS EN INGENIERÍA DE SOFTWARE, 3. IDENTIFICACIÓN DE RIESGOS DE PROYECTOS DE SOFTWARE, 4. GESTIÓN RIESGOS DEL SEI EN UN PROYECTO UNIVERSITARIO DE DESARROLLO DE SOFTWARE-SEI-CMR

RESUMEN 018 Gestión de riesgos con CMMI, RUP e ISO en Ingeniería de Software Minero PALABRAS CLAVE: 1. RIESGOS EN PROYECTOS DE SOFTWARE Software de software minero, son riesgos en software Los proyectos de minero, softwareProyectos para aplicaciones en minería claramente difíciles minero de administrar y una gran cantidad de ellos terminan en fracaso. En un proyecto de software minero, éste se puede traducir en una mala calidad del producto, incumplimiento de planes u objetivos y hasta el fracaso del proyecto. La gestión de riesgos en proyectos de software pretende identificar, estudiar y eliminar las fuentes de riesgo antes de que comiencen a amenazar el éxito o la finalización exitosa de un proyecto de desarrollo de software. Se define el riesgo como la posibilidad que un evento adverso, desgracia o contratiempo pueda manifestarse produciendo una pérdida (Pressman, R., 2001). El riesgo es una posibilidad futura, por lo tanto una gestión adecuada puede determinar la ocurrencia o no ocurrencia de éstos. Estudios previos han identificado siete categorías de riesgo en proyectos de software, incluyendo: (1) Gestión, (2) Clientes y usuarios, (3) Requerimientos, (4) Estimación y programación de actividades, (5) Jefe de proyecto, (6) Proceso de desarrollo de software y (7) Personal de desarrollo 2. GESTIÓN DE RIESGOS EN INGENIERÍA DE SOFTWARE Peter Drucker dijo una vez: “Mientras que es inútil intentar eliminar el riesgo y cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos adecuados”. Antes de poder identificar los “riesgos adecuados” que se pueden tomar en un proyecto de software, es importante poder identificar todos los riesgos que sean obvios a jefes de proyectos y profesionales del software. 3. IDENTIFICACIÓN DE RIESGOS DE PROYECTOS DE SOFTWARE La Identificación de Riesgos en proyectos de software consiste en la determinación de elementos de riesgos potenciales mediante la utilización de algún método consistente y estructurado; este es, probablemente, el paso más importante entre todos aquellos que componen las actividades de Administración de Riesgos, ya que sin la correcta determinación de los mismos, no es posible desarrollar e implementar anticipadamente respuestas apropiadas a los problemas que puedan surgir en el proyecto [Futrell, A. 2002]. El resultado de la identificación de riesgos es una lista conteniendo los riesgos que se han identificados y su categoría correspondiente.

Existen varios modelos de Administración de Riesgos pero el más aceptado consta de cinco pasos (Identificación, Análisis, Planificación, Seguimiento y Control) los que comparten como actividades comunes las de documentación y comunicación. 1. Resumen seguido de su correspondiente traducción al inglés Introducción 2. Texto 3. Conclusiones 4. Agradecimientos 5. Referencias 6. Apéndices (si es aplicable)

Se recomienda usar el Sistema Internacional de Unidades (SI). El estilo aconsejado contempla primero las unidades métricas seguidas de las unidades inglesas en paréntesis. GESTIÓN DE RIESGOS EN CMMI El CMMI (Capability Maturity Model Integrated) [CMMI, 2002] se ha convertido en el nuevo estándar a nivel mundial para la medición de la calidad de los procesos de desarrollo de software y presenta como una de sus PA (Process Área) fundamentales de Nivel 3 la Administración de Riesgos. Dentro del antes mencionado contexto de riesgos y la Identificación juegan un papel fundamental entre los objetivos planteados para el área de proceso asociada al manejo de riegos debido a que las tareas antes indicadas son consideradas como Actividades en el referido área de Procesos (PA).

4. GESTIÓN RIESGOS DEL SEI EN UN PROYECTO UNIVERSITARIO DE DESARROLLO DE SOFTWARE-SEI-CMR Aunque los diversos enfoques de gestión del riesgo aparecieron hace más de una década, sigue siendo evidente la poca utilización de sus técnicas en los proyectos de desarrollo de software actuales. Uno de los métodos más conocido es el método del SEI, conocido como Continuous Risk Management (SEICRM). En este artículo mostraremos la aplicación de este método en un proyecto universitario de desarrollo de software de grandes dimensiones. Además, nuestro trabajo muestra que conviene completar el SEI-CRM con un conjunto apropiado de riesgos organizacionales. Con nuestra investigación aplicada, esperamos contribuir al conocimiento de la gestión de los riesgos en proyectos de desarrollo del software, mediante la ampliación del método SEI-CRM con aquellos factores organizacionales de riesgo que han resultado relevantes en nuestro proyecto y en nuestra investigación previa. El método Continuous Risk Management (SEICRM), desarrollado por el Software Engineering Institute (SEI), es un método en el ámbito de la ingeniería del software cuyos conceptos, procesos y herramientas permiten gestionar de manera continua los riesgos de un proyecto, proporcionando un entorno disciplinado para la toma proactiva de decisiones a lo largo de todas las fases del proyecto: análisis de los problemas en potencia (riesgos), determinación de los riesgos importantes para elaborar estrategias y planes para gestionarlos. Estos riesgos son controlados hasta que se resuelven o se convierten en problemas menores, y son tratados como tales del riesgo que tiene el SEICRM pero además este método también incluye el concepto de gestionar estas actividades como un ciclo básico, es decir, identificar, analizar, planificar, seguir, controlar y comunicar los riesgos a lo largo de todo el ciclo de vida del proyecto.

Referencias 1. Information Systems Audit and control Foundation (2001). “COBIT. Governance, control and audit for information and related technology”. 3a ed. 2. Jacobson, I., Booch, G., Rumbaugh, J. (2000). El proceso unificado de desarrollo de software. Addison-Wesley, Madrid. 3. Pressman, R. (2001). Ingeniería del software. Un enfoque práctico”, 5a ed. McGraw-Hill. 4. R. M. Bernal Montañes; O. Coltell Simón (1996). Auditoría de los sistemas de información. Publicacions de la Universitat Politècnica de València. 5. R. Weber (1999). “Information Systems Control and Audit”. Prentice Hall, Upper Saddle River, NJ. 6. Sommerville, I (2002). Ingeniería de software. 6.a ed. Prentice Hall-Pearson Educación, México. 7. Australian Department of Defence. +SAFE – A Safety Extension to CMMI v1.0 (CA38809364) (2001). Defence Materiel Organisation, Canberra, December 19. 8. International Electrotechnical Commission. Safety of machinery-Functional Safety of SafetyRelated Electrical, Electronic and Programmable Electronic Control Systems (CEI IEC 62061) (2005). Geneva, Switzerland: International Electrotechnical Commission. 9. CMMI (2002) Product Development Team. SCAMPI v1.1, Standard CMMI Appraisal Method for Process Improvement, Version 1.1: Method Definition Document (CMU/SEI-2001HB-001). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, December, 2001. http://www.sei.cmu.edu/publications/documents /

06.reports/06hb002.html.

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI19] FUENTE: 019 ELABORO:FAMA TIPO:

Informe tecnico Una revisión sistemática de la adaptación del proceso software

TITULO:

AUTOR:

Oscar Pedreira1, Mario Piattini2, Miguel R. Luaces1, Nieves R. Brisaboa1 Laboratorio de Bases de Datos, Facultad de Informática, Universidade da Coruña PGIDIT05SIN10502PR and 2006/4

UBICACIÓN: DESCRIPCION: Aunque continuamente aparecen nuevos trabajos y propuestas en el área de proceso software, es difícil que encajen en su forma original en una empresa dada. De ahí la necesidad de adaptar los procesos estándar a las características particulares de la empresa. El objetivo de la adaptación del proceso software (software process tailoring) es adecuar un proceso software estándar a las características de una organización o proyecto específico. Aunque la adaptación del proceso software es señalada como una actividad obligatoria por la mayoría de las metodologías, en general se lleva a cabo siguiendo a cabo un enfoque ad-hoc, y la cantidad de investigación realizada en este tema puede considerarse pequeña. Este artículo presenta una revisión sistemática de la adaptación del proceso software, analizando las aproximaciones actuales para esta actividad, discutiendo las cuestiones más importantes relacionadas con este problema, y proporcionando un marco de trabajo actualizado en el que posicionar nuevas investigaciones.

TABLA DE CONTENIDO: 1. Introducción, 2. Revisión sistemática en ingeniería del software, 3. Una revisión sistemática de la adaptación del proceso software, 4. Cuestiones relativas a la adaptación del proceso software. PALABRAS CLAVE: Adaptación del proceso software, revisión sistemática 88

RESUMEN 019 Una revisión sistemática de la adaptación del proceso software 1. Introducción El proceso software es una de las áreas de investigación más importantes para la comunidad de ingeniería del software. Continuamente aparecen nuevos trabajos y propuestas que definen distintas aproximaciones para el proceso de desarrollo de software. Sin embargo, es difícil que satisfagan todas las necesidades de una organización o proyecto específico. Teniendo en cuenta que dos organizaciones son diferentes entre si y que, incluso dentro de una misma organización, dos proyectos pueden ser también muy diferentes, el proceso aplicado con éxito en uno de ellos puede ser un completo fracaso en el otro. Por eso, el proceso software debe ser adaptado al contexto y características específicas de cada caso. La adaptación del proceso software (en inglés, software process tailoring) consiste en adaptar y particularizar la descripción general del proceso para obtener un nuevo proceso adaptado, aplicable en un entorno alternativo y probablemente menos general [1]. Es decir, adaptar un proceso software a las necesidades concretas de una organización o un proyecto dado. La adaptación del proceso software puede tener lugar en dos niveles diferentes: a nivel organizacional o a nivel de proyecto. Las consecuencias de una mala adaptación del proceso software pueden ser muy importantes para la organización. En primer lugar, factores como el presupuesto, tiempo de desarrollo y calidad del producto dependen directamente de la adecuación del proceso software a los proyectos. Un proceso software mal adaptado a la empresa/proyecto puede incluir actividades innecesarias que suponen una pérdida de tiempo y dinero, o la omisión de algunas necesarias, que puede afectar a la calidad del producto. Además, una mala adaptación del proceso software puede dar lugar a problemas con respecto a la conformidad con estándares como ISO 9000 [2] o CMMI [3]. Por último, y no por eso menos importante, la adaptación del proceso software también influye en la satisfacción del personal, pues perder tiempo en actividades innecesarias no suele ser muy motivador. En este trabajo se ha llevado a cabo una revisión sistemática de la investigación en adaptación del proceso software. Para esto, se obtuvieron y analizaron los trabajos de investigación más importantes en el tema para identificar las aproximaciones, métodos y herramientas de soporte para la adaptación del proceso software. El resto del artículo está organizado como sigue. La siguiente sección describe brevemente el concepto de revisión sistemática en ingeniería del software. La sección 3 describe las decisiones tomadas en cada paso de la revisión sistemática presentada en este artículo, y los resultados a que han dado lugar. La sección 4 presenta las cuestiones más importantes relacionadas con la adaptación del proceso software identificado en la literatura. Finalmente, la sección 5 presenta las conclusiones y trabajo futuro.

2. Revisión sistemática en ingeniería del software La revisión sistemática es un método de investigación desarrollado para obtener, analizar, y evaluar toda la investigación relevante para una pregunta de investigación o un área de interés particular [4]. En contraste con una revisión literaria tradicional, una revisión sistemática sigue una secuencia estricta y bien definida de pasos metodológicos, que garantizan el alto valor científico de los resultados obtenidos. La principal razón para llevar a cabo una revisión sistemática es incrementar la probabilidad de detectar más resultados reales en el área de interés que los obtenidos con una revisión menos formal. Una revisión sistemática requiere un esfuerzo considerablemente mayor en comparación con una revisión tradicional, pero este es el precio a pagar por una revisión profunda y completa de un área de interés determinada. El concepto de revisión sistemática apareció en el área de la medicina, y su adaptación a la ingeniería del software se presenta en [5]. El método propuesto consta de tres actividades principales: planificación, revisión y publicación. Durante la actividad de planificación se identifican las necesidades de la revisión y se desarrolla el protocolo de revisión. En la actividad de revisión se seleccionan y evalúan los estudios primarios más importantes para esa área de investigación. El último paso consiste en la publicación de los resultados obtenidos en la revisión. Para que la revisión sistemática sea más sencilla, en [4] se propone una plantilla para el protocolo de revisión, que es la que se ha seguido en este trabajo. 3. Una revisión sistemática de la adaptación del proceso software Esta sección presenta el desarrollo de cada fase de la revisión sistemática (formulación de la pregunta, selección de las fuentes, selección de estudios primarios y extracción de información), y los resultados obtenidos en cada una de ellas. 4. Cuestiones relativas a la adaptación del proceso software. Como ya hemos mencionado, el objetivo de la adaptación del proceso software es partir de un proceso software estándar y adaptarlo a las necesidades de una organización o proyecto determinados. Hay muchos factores que influyen en esta adaptación, como el tamaño de la organización, sus objetivos, los recursos disponibles, tipo de proyecto, entorno del cliente, tipo de negocio, tecnologías utilizadas, requisitos del cliente sobre el propio proceso de desarrollo, etc. Esta sección presenta las respuestas a las preguntas formuladas en la revisión sistemática. Durante la evaluación y análisis de los estudios Primarios se identificaron como relevantes las siguientes cuestiones relacionadas con la adaptación del proceso software:

La adaptación del proceso software puede tener lugar a dos niveles distintos en una empresa: adaptación a nivel de organización o a nivel de proyecto. • La adaptación del proceso software puede llevarse a cabo siguiendo un enfoque formal o informal. • Casos de estudio sobre experiencias en organizaciones reales. • Adaptación del proceso software en PYMEs frente a grandes empresas. • Consideración de los problemas relacionados con la conformidad con estándares. • Descripción de herramientas de soporte para la actividad de adaptación del proceso. Cada estudio primario puede tratar una o más de estas cuestiones. Por ejemplo, algunos artículos describen una aproximación formal para la adaptación del proceso software y una experiencia real aplicando su propuesta en una empresa, pero trabajando sólo a nivel de proyecto. La Figura 1 muestra el porcentaje de artículos que se centran en una aproximación formal o informal, al nivel de proyecto u organización, y en pequeñas o grandes empresas. La figura da una idea del esfuerzo dedicado a cada problema. Por ejemplo, la mayoría de los artículos revisados describen un caso de estudio en grandes empresas de desarrollo de software más que en pequeñas y medianas empresas. La tabla 2 resume los estudios primarios que tratan cada uno de estos aspectos en la adaptación del proceso software, aunque a lo largo de esta sección se explicarán con más detalle.

Referencias [1] Ginsberg, M., Quinn, L., Process tailoring and the software Capability Maturity Model. Technical report, Software Engineering Institute (SEI), USA, 1995 [2] ISO 9001:2000. Quality management systems. Requirements. International Organization for Standardization, 2000 [3] CMMI for Systems Engineering/Software engineering. Version 1.1. Technical report, Software Engineering Institute (SEI), 2002 [4] Biolchini, J., Mian, P.G., Natali, A.C.C., Travassos, G.H., Systematic review in software engineering. Technical report, Systems Engineering and Computer Science Department, UFRJ, Brasil, 2005 [5] Kitchenham, B., Procedures for performing systematic reviews. Technical report Software Engineering Group, Department of Computer Science, Keele University, 2004

FICHA DE REGISTRO DOCUMENTAL CODIGO: [MARTI20] FUENTE: 020 ELABORO:FAMA TIPO: TITULO:

AUTOR:

INFORME TECNOLOGICO Un análisis del desarrollo de software en empresas venezolanas Milagro Rivero Jonás Montilva Judith Barrios Mario Murúa Gladys Granados Seventh LACCEI Latin American and Caribbean Conference for Engineering and Technology (LACCEI’2009) “Energy and Technology for the Americas: Education, Innovation, Technology and Practice” June 2-5, 2009, San Cristóbal, Venezuela

UBICACIÓN: DESCRIPCION: La Industria Venezolana del Software (IVS) es un sector de la economía nacional en pleno proceso de crecimiento. Este sector está conformado, en su mayoría, por pequeñas y medianas empresas (PYMES); muchas de las cuales, están tratando de mejorar sus procesos, para aumentar su competitividad y ganar mercados fuera del ámbito nacional. El objetivo de este artículo es analizar la capacidad y la madurez que estas empresas tienen, actualmente, para producir software de alta calidad. Para evaluar estos dos aspectos es necesario conocer los procesos, los métodos TABLA DE CONTENIDO: y las tecnologías que estas empresas utilizan para desarrollar software. Los resultados presentados están basados un estudio 1. INTRODUCCIÓN, 2. HERRAMIENTAS DE CONSTRUCCION DE estadístico que permitió apreciar el estado actual de esta industria. SOFTWARE, 3. PROCESOS INTERNOS, MODELOS DE CALIDAD, 4. MODELOS DE MEJORA DE PROCESOS PALABRAS CLAVE: Desarrollo de software, Industria Venezolana del Software, Práctica de la Ingeniería de Software

RESUMEN 020 Un análisis del desarrollo de software en empresas venezolanas 1. INTRODUCCIÓN Un sector creciente de la economía venezolana está constituido por empresas dedicadas al desarrollo, mantenimiento y comercialización de productos de software. Dos estudios estadísticos realizados, en Venezuela durante los últimos tres años, han permitido conocer el estado actual de esta industria. El primero de ellos fue realizado durante los años 2006-2007 (Rivero et al, 2007). El segundo fue elaborado, durante el año 2008, bajo el marco del Proyecto titulado ¨Métodos y Modelos de Desarrollo de Software para Empresas Venezolanas¨ (Métodos, 2009). Ambos estudios permitieron establecer y evaluar, entre otros, los siguientes aspectos de esta industria: (1) las características generales de sus empresas; (2) los recursos humanos que ellas emplean; (3) los tipos de productos que ellas desarrollan y comercializan; (4) sus procesos de gestión de proyectos y calidad del software; (5) sus procesos de desarrollo y mantenimiento de software y (6) las tecnologías que ellas aplican para elaborar sus productos. En ambos estudios se tomaron en consideración solamente aquellas empresas públicas o privadas cuyo objeto de negocio es exclusivamente la producción y comercialización de productos de software. A este sector se le denomina Industria Venezolana del Software (IVS). Existe un número importante de empresas, que no fueron consideradas, debido a que ellas desarrollan software, exclusivamente, para su uso interno; tal es el caso de las empresas del estado, los bancos y las empresas aseguradoras, por nombrar sólo algunas de ellas. El objetivo de este artículo es analizar los resultados obtenidos en el segundo de estos estudios y que están relacionados, directamente, con los procesos de desarrollo de software y las tecnologías que dicha industria emplea para elaborar sus productos. A través de este análisis, se podrá apreciar la capacidad y madurez que estas empresas tienen para producir software de alta calidad. La calidad del software es considerada un requisito fundamental para competir en el mercado nacional e internacional. Este trabajo contribuirá a establecer las debilidades que la IVS tiene que solventar, para alcanzar niveles de madurez que le permita competir internacionalmente. La capacidad y la madurez se miden en función de los procesos y tecnologías que las empresas utilizan para desarrollar software. Para determinar qué aspectos de una empresa deben evaluarse, se empleó el modelo CMMI - Capability Maturity Model Integration – (Software Engineering Institute, 2002). Este modelo es el estándar de facto empleado, a nivel mundial, para evaluar y certificar empresas. El modelo CMMI establece que la calidad de un producto va asociada a la calidad del proceso que se sigue para producirlo. Una parte importante de este trabajo de investigación estuvo, por consiguiente, dirigido a identificar qué métodos, modelos de procesos y modelos de madurez emplea la IVS, actualmente, para desarrollar productos de software. En la sección dos, se resume la metodología empleada en el estudio estadístico, para la recolección y análisis de los datos de la investigación. La sección tres muestra los resultados obtenidos. En la sección cuatro, se discuten estos resultados. Finalmente, la sección cinco presenta las conclusiones y recomendaciones de este estudio. 94

2. HERRAMIENTAS DE CONSTRUCCION DE SOFTWARE En Venezuela, se está trabajando en varias modalidades de licenciamiento, estos son: libre o privativos. Ellos se corresponden con el cliente a quien está destinado el producto. Las licencias libres son, generalmente, requeridas por clientes gubernamentales; mientras que las privativas son más requeridas por empresas privadas o no gubernamentales. Entre las herramientas que deben ser consideradas dentro de estas modalidades están: Los lenguajes de programación, los sistemas operativos y los sistemas manejadores de base de datos, ellas son fundamentales para el desarrollo de aplicaciones de software. En relación a este aspecto, se obtuvo que Windows es el sistema operativo más utilizado, seguido de Linux. Sin embargo, tal como lo muestra la figura 3a, la diferencia entre ambos sistemas no es muy grande. Entre los sistema manejadores de base de Datos se tiene que primero esta SQL Server como el más utilizado, seguidos por MySQL y PostgreSQL, con respecto a los lenguajes de programación usados para el desarrollo de aplicaciones, se tienen que PHP, Java y Visual Basic son los lenguajes de desarrollo utilizados, ver figuras 3b. Se podría concluir que las plataformas LAMP son unas de las más utilizadas, por lo que el desarrollo de software libre es una tendencia fuerte en este mercado. Un indicador fundamental de calidad de los productos de software es el uso de modelos de procesos y/o métodos maduros para el desarrollo de software. Para ello, es importante conocer, primero, el tamaño de los desarrollos que hace la IVS. El tamaño se define en términos de la duración del ciclo de vida del proyecto: menos de 6 meses para proyectos cortos, entre 6 y 15 meses para proyectos medianos y más de 15 meses para proyectos grandes. Esta información permite determinar, posteriormente si, en base al tamaño de los proyectos, se están utilizando modelos de procesos correctos. La Figura 4 muestra el número de proyectos que la IVS desarrolla para el momento de realización la encuesta y de acuerdo al tamaño del ciclo de vida de ellos.

3. PROCESOS INTERNOS, MODELOS DE CALIDAD La capacidad de una empresa para desarrollar software de alta calidad se mide en base a los modelos de procesos o métodos de desarrollo de software utilizados. De acuerdo a los datos obtenidos en la tabla 3, se tiene que los métodos propios son los más utilizados. Ellos se utilizan en aproximadamente un 70% del total de los modelos utilizados. El método RUP y la Programación Extrema (XP) son utilizados cerca de un 30%. El resto de los métodos son muy poco conocidos. 4. MODELOS DE MEJORA DE PROCESOS La madurez y capacidad de una empresa de software para desarrollar productos de alta calidad se mide a través de modelos de mejoras, tales como los modelos CMMI (Capability Maturity Model Integration), SPICE e ISO 9000. El uso de modelos de gestión, tales como ITIL y PMP, refleja, también, un grado alto de madurez. El modelo CMMI-SW del Instituto de Ingeniería de Software es el modelo empleado por la industria mundial del software, como un estándar de facto, en la evaluación de la capacidad y madurez que tienen estas empresas para desarrollar software de alta calidad. De acuerdo a los resultados presentados en la tabla 4a y 4b, se concluye que sólo el 45% del total de las empresas consultadas usan el modelo ISO frecuentemente u ocasionalmente, mientras que el 36% usa el modelo CMMI. Los otros modelos ITIL Y PMP son poco conocidos o utilizados. De acuerdo a los resultados presentados en la tabla 4a y 4b, se concluye que sólo el 45% del 100% de las empresas consultadas usan el modelo ISO frecuentemente u ocasionalmente, mientras que el 36% usa el modelo CMMI. Los otros modelos ITIL Y PMP no menos muy conocidos o utilizados. El uso de herramientas en todas las actividades que se realizan en los procesos de desarrollo es fundamental, su uso incide en la calidad de los procesos y, por ende, de los productos. La tabla 5 muestra que tipo de herramientas utiliza la IVS para soportar sus procesos de desarrollo. Se puede concluir cuales herramientas para analizar, diseñar, depurar código, y controlar las versiones, son las más frecuentemente utilizadas. Las herramientas para pruebas de software y manejo de la configuración son menos utilizadas.

REFERENCIAS IEEE/ACM (2004). The Joint Task Force on Computing Curricula IEEE/ACM. Software Engineering 2004. Curriculum Guidelines for Undergraduates Degree Programs in Software Engineering. http://sites.computer.org/ccse/, 02/10/09 (date accessed). IEEE (2004). Guide to the Software Engineering Body of Knowledge SWEBOK, 2004 Version. IEEE Computer Society, Professional Practices Committee. http://www.swebok.org, 02/10/09 (date accessed). Methodius (2009). Estado de la Industria Venezolana de Software - Informe Técnico Abril 2008, Portal del Proyecto “Métodos y Modelos de Desarrollo de Software para Empresas Venezolanas – METHODIUS”, http://www.methodius.org.ve. 01/10/09 (fecha de acceso). Montilva, J, Barrios J., Rivero D.M., Besembel, I., Martinez, A y Sandia, B. (2007) “DINSOFT: Un Programa de Actualización Profesional en Ingeniería de Software”. Actas de las VI Jornadas Científico Técnicas de la Facultad de Ingeniería, Universidad de Los Andes, Mérida, pp.1027-1035. Rivero, M., Montilva, J. Granados, G., Barrios, J., Besembel, I y Sandia, B. (2007) “La Industria del Software en Venezuela: Una Caracterización de su Recurso Humano”. Memorias del X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software y Primer Encuentro Venezolano sobre Tecnologías de Software e Información – EVETIS’2007/IDEAS’2007. Margarita, Venezuela. PMI. (2004). Guía de los Fundamentos de la Dirección de Proyectos. Tercera Edición. Project Management Institute. Pennsylvania. USA. Schmauch, Ch. (1995). ISO 9000 for Software Developers. ASQC Quality Press, Wisconsin. Software Engineering Institute (2002). Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Software Engineering. Technical Report # CMU/SEI-2001-TR-029. Carnegie Melon University, Software Engineering Institute.